Delegate from BIND to Windows 2003 DNS (AD Zone)

[Kevin Darcy]

FabriceR wrote:

>Hello,
>
>I have bind DNS (8.3.3-REL-NOESW) for my compagny and we'll install a 
>Windows 2003 AD with DNS. Our plan is :
>
>* Keep our clients on BIND DNS (compagny.fr)
>* Create the 2003 AD zone DNS (ad.compagny.fr)
>* Delegate ad to 2003 DNS (the DC machine) in BIND
>
>To do this, I create a stub zone in BIND DNS witch point to the 2 DC 
>2003. The creation is ok and I can query BIND DNS about NS record for 
>ad.compagny.fr (and A records associates).
>
>When I try a query (other than NS) for the ad.compagny.fr domaine on 
>BIND DNS, I have an error.
>
>I supposed the problem is that Windows 2003 AD DNS have multiple master. 
>Each DC is master on the zone and each DC give SOA with his own name (cf 
>at the end, the "host -C")
>
>Hope you have some links or hints.
>Best regards,
>FabriceR
>
>
>$ dig NS ad.compagny.fr
>
>; <<>> DiG 9.2.1 <<>> NS ad.compagny.fr
>;; global options:  printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14691
>;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
>
>;; QUESTION SECTION:
>;ad.compagny.fr.            IN      NS
>
>;; ANSWER SECTION:
>ad.compagny.fr.     3600    IN      NS      dc2.ad.compagny.fr.
>ad.compagny.fr.     3600    IN      NS      dc1.ad.compagny.fr.
>
>;; ADDITIONAL SECTION:
>dc2.ad.compagny.fr. 3600 IN    A       192.168.7.27
>dc1.ad.compagny.fr. 3600 IN    A       192.168.7.17
>
>;; Query time: 1 msec
>;; SERVER: 127.0.0.1#53(127.0.0.1)
>;; WHEN: Tue Apr 12 15:57:13 2005
>;; MSG SIZE  rcvd: 114
>
>$
>
>$ dig @dc1.ad.compagny.fr. SOA ad.compagny.fr
>
>; <<>> DiG 9.2.1 <<>> @dc1.ad.compagny.fr. SOA ad.compagny.fr
>;; global options:  printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14064
>;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
>;; QUESTION SECTION:
>;ad.compagny.fr.            IN      SOA
>
>;; ANSWER SECTION:
>ad.compagny.fr.     3600    IN      SOA     dc1.ad.compagny.fr. 
>hostmaster. 900 900 600 86400 3600
>
>;; ADDITIONAL SECTION:
>dc1.ad.compagny.fr. 3600 IN    A       192.168.7.17
>
>;; Query time: 0 msec
>;; SERVER: 192.168.7.17#53(dc1.ad.compagny.fr.)
>;; WHEN: Tue Apr 12 15:57:37 2005
>;; MSG SIZE  rcvd: 107
>$
>$ more /etc/bind/named.conf
>...
>// Zone ad
>zone "ad.compagny.fr" IN {
>         type stub;
>         file "/etc/bind/db.ad.compagny.fr";
>         masters { 192.168.7.27; 192.168.7.27; };
>};
>...
>$
>$ host -C ad.compagny.fr.
>ad.compagny.fr      NS      dc1.ad.compagny.fr
>dc1.ad.compagny.fr     hostmaster      (900 900 600 86400 3600)
>  !!! ad.compagny.fr SOA hostmaster hostmaster has illegal mailbox
>  !!! ad.compagny.fr SOA expire is less than 1 week (1 day)
>ad.compagny.fr      NS      dc2.ad.compagny.fr
>dc2.ad.compagny.fr     hostmaster      (900 900 600 86400 3600)
>  *** dc2.ad.compagny.fr and dc1.ad.compagny.fr have different primary 
>for ad.compagny.fr
>$
>
You haven't given an example of an "ordinary" query for a name in 
ad.compagny.fr failing. The "host -C" query doesn't really count, since 
it's just complaining about the *semantics* of the SOA records. The SOA 
records are actually *syntactically* correct, and the fact that they 
have objectionable content shouldn't really affect normal (e.g. A, SRV) 
queries for names in the zone.

By the way, you shouldn't need to delegate ad.compagny.fr *and* define a 
stub zone for it. In the vast majority of circumstances, that would be 
overkill. Delegation alone should be sufficient. Hopefully you 
understand that a stub zone is different from a delegation. The 
difference is not so clear with BIND 8, since it improperly mixes glue 
records, but when you move to BIND 9 (which you should already be 
planning), you'll need to understand the difference. Offhand, the only 
legitimate reasons I can think of to define an ad.compagny.fr stub zone, 
in addition to delegating it, would be if a) you wanted to place some 
sort of unique restriction on it, e.g. allow-query, allow-transfer, etc. 
or b) ad.compagny.fr is in a minority of compagny.fr subzones for which 
you wanted to cancel forwarding (via "forwarders { };"), assuming that 
forwarding is enabled at a higher level or globally.

                                                                         
                                                - Kevin