Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm in the process of migrating from a workgroup served by a BIND9 DNS server, to a AD Domain based on Windows Server 2008 R2, and I'd like to keep using the BIND server until the AD infrastructure is ready.

During the setup of AD, via dcpromo, I get a warning that I should make sure our current DNS server delegates the AD domain name to the AD server.

Suppose my AD domain is mydomain.lan, and my regular BIND domain is example.com. I'm setting my BIND server as authoritive for lan., but would like to delegate mydomain.lan. to the AD server's IP.

My named.conf.local contains:

zone "lan" {
        type master;
        file "zone.lan";
};

And zone.lan contains:

$ORIGIN lan.
$TTL 1H ; 1 hour
@                       IN SOA  dns.example.com. hostmaster.example.com. (
                                201008137  ; serial
                                28800      ; refresh (8 hours)
                                14400      ; retry (4 hours)
                                2419200    ; expire (4 weeks)
                                86400      ; minimum (1 day)
                                )
                        IN NS   dns.example.com.

$ORIGIN mydomain.lan.
@                       IN NS   dc1.mydomain.lan.
dc1                     IN A    10.10.0.200 ; 'glue' record

When I query dns.example.com for "lan", I can the expected answer, but when I query for "mydomain.lan" or "dc1.mydomain.lan" I get an NXDOMAIN response. All my tries so far have failed.

How do I properly create and delegate a subzone?

Update: some more info

$ dig mydomain.lan @dns.example.com NS +norecurse

; <<>> DiG 9.7.0-P1 <<>> @dns.example.com mydomain.lan NS +norecurse
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23380
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;mydomain.lan.          IN  NS

;; AUTHORITY SECTION:
mydomain.lan.       3600    IN  NS  dc1.mydomain.lan.

;; ADDITIONAL SECTION:
dc1.mydomain.lan.   3600    IN  A   10.10.0.200

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Sun Aug 15 00:41:05 2010
;; MSG SIZE  rcvd: 64

$ dig @dc1.mydomain.lan dc1.mydomain.lan
dig: couldn't get address for 'dc1.mydomain.lan': not found

$ dig @10.10.0.200 dc1.mydomain.lan

; <<>> DiG 9.7.0-P1 <<>> @10.10.0.200 dc1.mydomain.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21348
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dc1.mydomain.lan.      IN  A

;; ANSWER SECTION:
dc1.mydomain.lan.   1200    IN  A   10.10.0.200

;; Query time: 6 msec
;; SERVER: 10.10.0.200#53(10.10.0.200)
;; WHEN: Sun Aug 15 00:55:11 2010
;; MSG SIZE  rcvd: 50

$ dig @10.10.0.200 mydomain.lan

; <<>> DiG 9.7.0-P1 <<>> @10.10.0.200 mydomain.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24664
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mydomain.lan.          IN  A

;; ANSWER SECTION:
mydomain.lan.       600 IN  A   10.10.0.200

;; Query time: 0 msec
;; SERVER: 10.10.0.200#53(10.10.0.200)
;; WHEN: Sun Aug 15 01:04:39 2010
;; MSG SIZE  rcvd: 46
share|improve this question
    
What happens when you query 10.10.0.200 for "mydomain.lan"? –  wolfgangsz Aug 13 '10 at 16:30
    
I see no errors with your configuration. I think wolf is onto something. What happens when you run "dig @dns.example.com mydomain.lan NS +norecurse" –  Mark Wagner Aug 13 '10 at 17:25
    
Thanks. I've updated the question with the queries you suggested. –  Martijn Heemels Aug 14 '10 at 23:05
    
@wolfgangsz Yeah, when I query it by IP 10.10.0.200 is resolves fine. But when I query by name dc1.mydomain.lan it fails with "dig: couldn't get address for 'dc1.mydomain.lan': not found". To me, it seems the glue record on dns.example.com isn't working, but I don't see why. –  Martijn Heemels Aug 17 '10 at 11:33
    
Odd. The named-checkzone tool also appears to see a problem with the glue record: root@dns:~# named-checkzone lan /var/cache/bind/zone.lan zone lan/IN: mydomain.lan/NS 'dc1.mydomain.lan' (out of zone) has no addresses records (A or AAAA) zone lan/IN: loaded serial 201008137 OK –  Martijn Heemels Aug 17 '10 at 11:36
show 1 more comment

3 Answers 3

The problem is in your named.conf. I'm guessing you've got forwarders defined in your named.conf somewhere. For any zone for which your server is authoritative, you need to turn the forwarding off. Using the sample from above, you should change it to read like this:

zone "lan" {
    type master;
    file "zone.lan";
    forwarders { };
};

It should work once you do this.

share|improve this answer
add comment

There is a problem in the zone file.

$ORIGIN lan.
$TTL 1H ; 1 hour
@                       IN SOA  dns.example.com. hostmaster.example.com. (
                                201008137  ; serial
                                28800      ; refresh (8 hours)
                                14400      ; retry (4 hours)
                                2419200    ; expire (4 weeks)
                                86400      ; minimum (1 day)
                                )
                        IN NS   dns.example.com.

$ORIGIN mydomain.lan.
@                       IN NS   dc1.mydomain.lan.
dc1                     IN A    10.10.0.200 ; 'glue' record

The @ refers the zone name as defined in the named.conf

zone "lan" {
        type master;
        file "zone.lan";
};

which is just 'lan'. The record you created is

lan. IN NS dc1.nydomain.lan.

I tend not to use BIND shortcuts for important records because it's easy forget or misunderstand the behavior, leading to unexpected results.

(I realize it's probably too late to help this person, but if someone else looks at this, try removing the BIND shortcuts to see if it fixes your problems.)

share|improve this answer
    
Actually the $ORIGIN directive should overrule the zone name. "The @ symbol places the $ORIGIN directive (or the zone's name, if the $ORIGIN directive is not set) as the namespace being defined by this resource record." I'm not sure if perhaps the second $ORIGIN fails to override the first one, which would lead to the same problem you mention. Of course you're right to avoid shortcuts in case of doubt. I use them to keep zonefiles DRY, but reducing complexity should come first. –  Martijn Heemels Aug 7 '13 at 20:18
add comment

Looks like you're missing 'dc1' as a host in the AD-managed zone; the glue is only used to find the authoritative servers, not as actual content once those servers have been reached.

You might want to explore dig +trace to see the servers queried, when not using @server.name, to see the delegation chain being chased.

share|improve this answer
    
The .lan is a private TLD, so +trace can't resolve it since it starts at the public root servers. dc1 is found properly and authoritatively when using nslookup on the AD server, so it knows about itself. The problem appears to be that the glue doesn't work: When I query dns.example.com for dc1.mydomain.lan I get an NXDOMAIN. Similarly when I query dc1 from the LAN, except when I specify the server as an IP address! This works: 'dig dc1.mydomain.lan @10.10.0.200', while this doesn't: 'dig dc1.mydomain.lan @dc1.mydomain.lan'. –  Martijn Heemels Aug 17 '10 at 10:20
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.