8.9 Handling Active Directory with a Name Server

8.9.1 Problem

You want to allow your Active Directory Domain Controllers to register their SRV records using dynamic update.

8.9.2 Solution

As with Section 8.8, there are a number of different solutions to this problem, but this is probably the most popular. If your Windows domain has the same name as an existing zone in DNS, create subzones with the names:

• _msdcs.name-of-Windows-2000-domain

• _sites.name-of-Windows-2000-domain

• _tcp.name-of-Windows-2000-domain

• _udp.name-of-Windows-2000-domain

For example, if both the name of your Windows domain and the domain name of your main forward-mapping zone were corp.example, you would create zones called _msdcs.corp.example, _sites.corp.example, _tcp.corp.example, and _udp.corp.example. You don't need separate name servers for these zones; they can be the same as the corp.example name servers:

_msdcs.corp.example.    IN    NS    ns1.corp.example.
_msdcs.corp.example.    IN    NS    ns2.corp.example.

_sites.corp.example.    IN    NS    ns1.corp.example.
_sites.corp.example.    IN    NS    ns2.corp.example.

_tcp.corp.example.      IN    NS    ns1.corp.example.
_tcp.corp.example.      IN    NS    ns2.corp.example.

_udp.corp.example.      IN    NS    ns1.corp.example.
_udp.corp.example.      IN    NS    ns2.corp.example.

Like the special subzone for Windows hosts to register in, these zones can start as minimal zones:

$TTL 1d
@    IN    SOA    ns1.corp.example.    hostmaster.corp.example.    (
     2002061900
     1h
     15m
     30d
     1h )
     IN    NS    ns1.corp.example.
     IN    NS    ns2.corp.example.

However, we only need to permit dynamic updates to these zones that come from our Domain Controllers:

acl domain-controllers { 192.168.0.100; 192.168.0.200; };

zone "_msdcs.corp.example" {
    type master;
    file "db._msdcs.corp.example";
    allow-update { domain-controllers; };
};

zone "_sites.corp.example" {
    type master;
    file "db._sites.corp.example";
    allow-update { domain-controllers; };
};

zone "_tcp.corp.example" {
    type master;
    file "db._tcp.corp.example";
    allow-update { domain-controllers; };
};

zone "_udp.corp.example" {
    type master;
    file "db._udp.corp.example";
    allow-update { domain-controllers; };
};

8.9.3 Discussion

The reason we can't allow dynamic updates to our main forward-mapping zone from our Domain Controllers is that it gives them too much control over the contents of the zone: someone could easily send -- or spoof -- dynamic updates from a Domain Controller and modify the zone. Instead, we create special subzones for the Domain Controllers to update. Since the domain names of the records they add usually end in _msdcs.corp.example, _sites.corp.example, _tcp.corp.example, or _udp.corp.example, the updates will modify the subzones, not their parent zone.

Domain Controllers do try to register two records that can cause problems, though: an A record attached to the domain name that matches the name of the Windows domain, and an A record in the _msdcs subdomain that has an underscore in the domain name. (All of the SRV records that Domain Controllers add have underscores in their domain names, but nearly all name servers allow that. BIND 8 name servers, by default, will complain about underscores in the owner of an A record, however.) To prevent the Domain Controller from trying to add these two records, change the value of the following Registry key to zero on the Domain Controllers:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RegisterDNSARecords

8.9.4 See Also

"DNS and Windows 2000" in Chapter 16 of DNS and BIND; and "The Ties That BIND" in the March 2001 issue of Linux Magazine, at http://www.linux-mag.com/2001-03/bind_01.html.