Windows 2000 & UNIX DNS Integration
Kevin Amorin (kev@amorin.org)
In association with Ben Minsk (bminsk@msn.com)
This article will discuss the integration of Windows DNS requirements in an existing UNIX environment. We will review some of the most used designed infrastructures and discuss the benefits and drawbacks to each approach. We are assuming in the article that the current DNS infrastructure is made up of primarily of UNIX/non-windows 2000 servers.
Microsoft, in its release of windows 2000 has made changes to its name resolution method, resulting in the shift from WINS to DNS for resolution. As a result all windows 2000 clients and server will look now to DNS for accessing network resources.
The integration of DHCP and DNS plays a significant role in windows 2000 deployment.
On start up Windows 2000 clients are programmed to perform DDNS, registering their name and IP address with the DNS server after it is assigned. Windows 2000 servers also register with DNS, adding SRV records advertising the services running on the system. This allows windows 2000 clients to perform a DNS lookup via SRV records for the domain controller and domain services (winlogin, global catalog).
While windows conforms to the RFC standard 2052 (SRV records), and RFC standard 2136 (DDNS) this still may pose a problem to environments which are not running the latest version of DNS software (ISC 8.2.2>). While BIND has supported SRV records for a long time, DDNS update functionality has just been added in the more recent versions of ISC BIND. While discussing options listed below you must also research UNIX changes that may be necessary including upgrading ISC BIND.
Most prevalent integration options:
Unix Master, Windows Subdomain, Windows Local
Unix Master (ISC Bind >8.2.2) Dynamic DNS
In this scenario the UNIX server will be the master for the windows zone. All dynamic registration of the DNS SRV, A, and PTR records for the zone will be stored on the UNIX server.
Unix DNS
Server: foo.com
Figure
1: BIND DNS server hierarchy
ISC BIND named.conf Example:
# Master for zone foo.com, and allow for A and SRV
updates from the
# Windows 2000 clients on subnet 192.168.1.x
#
zone “windows2k.foo.com” {
type master;
file “windows2k.foo.com”;
allow-update {192.168.1/24;};
};
# Master for the reverse zone 192.168.1.x all for PTR updates from
# Windows 2000 clients
#
zone “1.168.192.in-addr.arpa” {
type master;
file “1.168.192.in-addr.arpa”;
allow-update { 192.168.1/24;};
};
Benefits
a. Centralized DNS
b. Current infrastructure can remain intact with little changes.
Drawbacks
a. Updating of UNIX software (ISC BIND) may be required
b. The allow-update configuration will allow any IP address in the range to update the DNS zone, this could lead to a spoofing attack from a machine on the subnet corrupting the windows zone.
c. SRV records ~20 records updating per hour
Windows Subdomain - Windows
2000 Master DNS
In this set up the windows DC will
be the DNS server for the zone. The unix server will redirect all
request to the windows domain controller with the standard
Unix DNS zone records:
Win2k IN NS dc.wind2k
dc.win2k IN A 192.168.1.1
Windows:
Master win2k.foo.com domain
Figure
2: BIND DNS server hierarchy
For redundancy you may want your UNIX DNS servers to be secondary to the win2k domain. This will be helpful especially for your win2k clients while your DC is not available.
ISC BIND named.conf Example:
# Slave the
windows2k zone and reverse
#
zone “win2k.foo.com” {
type slave;
file “win2k.foo.com”;
};
zone “1.168.192.in-addr.arpa” {
type slave;
file “1.168.192.in-addr.arpa”;
};
Benefits
a. Windows domain authoritative for it’s zone.
b. Remains in Unix hierarchy yet allows for separate administration.
c.
Drawbacks
a. Resolution dependent on Unix systems being intact. If they go down, resolution is compromised.
Windows Local Domain - Master for a
non external domain foo.local
In this scenario the windows DC will be the DNS server for a non resolvable zone. The main goal of this option is to separate the windows 2000 environment from the rest of your infrastructure.
Example:
Windows DNS
Server: Win2k.local
Figure 3: BIND DNS server hierarchy
Benefits
a. Separation of windows and UNIX administration
b. Security, external hosts would not be able to resolve client hostnames
c. No dependency on Unix DNS. Self sufficient.
Drawbacks
a. Require all clients to point to the windows DNS server for resolution
b. Doesn’t allow for future integration with the global DNS infrastructure. The Windows 2000 forest would have to be reconstructed to enter the global DNS hierarchy (local -> foo.com)