DNS domain delegation problem (BIND 9.2.3)

[support_5]

Hi,

After some work and research at this I am still stumped and was wondering if you wouldn't mind shedding some light on the matter.

This site has a DNS server which is auth. for the workcover.qld.gov.au. domain. this server is called "noumea" and is a HP-UX server. We are wanting to setup a sub-domain so that the windows admins can play with Active Directory. So we have set up another server called "cayman" to be authoratative for the dv.workcover.qld.gov.au. domain. We haven't yet made any changes to the zone files on noumea indicating that cayman is a name server for this sub-domain (I don't know if this will stuff things up or not, but I think it shouldn't). However, I wanted to check how domain authority delegation worked, so I created another sub domain called testdom.dv.workcover.qld.gov.au which runs on a server called "tahiti". I put in the NS resource records on cayman as you can see from the zone files below.

Now, these servers all work fine independently, for example, if I run:
nslookup test1.dv.workcover.qld.gov.au cayman (so that it talks to the nameserver cayman to resolve the name test1). What I find is that this returns the correct entry that I have put into the zone file for this domain on cayman.

all is good so far.

However, If I run
nslookup test3.testdom.dv.workcover.qld.gov.au cayman (so that it talks to the nameserver cayman to resolve the name test1.testdom...) it fails. It won't resolve the name, but the following command will work:
nslookup test3.testdom.dv.workcover.qld.gov.au tahiti

I would have thought that either the resolver or cayman would realise that it is not authorative for the testdom domain and try and find who is authorative for it. I would have also thought that cayman would know immediately who is authorative for that domain because it has the resource field indicating what server is authorative for that subdomain...I also thought that either cayman or the resolver on the client would then query tahiti on the server named "test3" in the domain that it is authorative for and return the authorative answer. However, this obviously isn't happening since the nslookup fails.

What am I doing wrong???

Below are the appropriate extracts of the named.conf files and the db resource files. See if you can spot what is wrong because I sure can't. I will also append the syslog output if that helps.

Once again, thanks in advance for any help you may offer on this.

- Andrew Gray




############# C A Y M A N : /etc/named.data/named.conf ##############
options {
directory "/etc/named.data"; // running directory for named
pid-file "/var/run/named.pid";
allow-query { any; };
forwarders {
172.22.16.207;
};
// forward only;
// recursion no;
query-source address * port 53;
};

// type domain source file

zone "dv.workcoverqld.com.au" {
type master;
file "db.dv.workcoverqld";
};

zone "dv.workcover.qld.gov.au" {
type master;
file "db.dv.workcover";
};

zone "." {
type hint;
file "db.cache";
};

zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "db.127.0.0";
};

zone "172.IN-ADDR.ARPA" {
type slave;
file "db.172";
masters { 172.22.16.207; };
};



############# C A Y M A N : /etc/named.data/db.dv.workcover ##############
@ 3600 IN SOA cayman.workcover.qld.gov.au. root.cayman.workcover.qld.gov.au. (
2004081305 ; Serial
600 ; Refresh every 10 min
3600 ; Retry every hour
604800 ; Expire after a week
3600 ) ; Minimum ttl of 1 hour
IN NS cayman.workcover.qld.gov.au.

localhost IN A 127.0.0.1

test1 IN A 172.22.1.1
test2 IN A 172.22.1.2
cayman IN A 172.22.241.77

testdom.dv.workcover.qld.gov.au. IN NS tahiti.workcover.qld.gov.au.
;testdom.dv.workcover.qld.gov.au. IN NS tahiti.workcover.qld.gov.au.

tahiti IN A 172.22.242.9

; don't need the following since it's in a different domain and bind ignores it.
;tahiti.workcover.qld.gov.au. IN A 172.22.242.9



############# T A H I T I : /etc/named.data/named.conf ##############
options {
directory "/etc/named.data"; // running directory for named
pid-file "/var/run/named.pid";
allow-query { any; };
forwarders {
172.22.241.77;
};
// query-source port 53;
};

// type domain source file

zone "testdom.dv.workcoverqld.com.au" IN {
type master;
file "db.testdom.dv.workcover";
};

zone "testdom.dv.workcover.qld.gov.au" IN {
type master;
file "db.testdom.dv.workcoverqld";
};



############# T A H I T I : /etc/named.data/db.testdom.dv.workcover ##############
@ 3600 IN SOA tahiti.workcover.qld.gov.au. root.tahiti.workcover.qld.gov.au. (
2004081302 ; Serial
600 ; Refresh every 10 min
3600 ; Retry every hour
604800 ; Expire after a week
3600 ) ; Minimum ttl of 1 hour
IN NS tahiti.workcover.qld.gov.au.

localhost IN A 127.0.0.1

testhost.testdom.dv.workcover.qld.gov.au. IN A 172.22.1.3
test3.testdom.dv.workcover.qld.gov.au. IN A 172.22.1.3
tahiti IN A 172.22.242.9




############# C A Y M A N : /var/adm/syslog/syslog.log ##############
Aug 20 14:48:14 cayman named[15423]: starting BIND 9.2.3 -c /etc/named.data/named.conf
Aug 20 14:48:14 cayman named[15423]: using 1 CPU
Aug 20 14:48:14 cayman named[15423]: loading configuration from '/etc/named.data/named.conf'
Aug 20 14:48:14 cayman named[15423]: no IPv6 interfaces found
Aug 20 14:48:14 cayman named[15423]: listening on IPv4 interface lan0, 172.22.241.77#53
Aug 20 14:48:14 cayman named[15423]: listening on IPv4 interface lo0, 127.0.0.1#53
Aug 20 14:48:14 cayman named[15423]: command channel listening on 0.0.0.0#953
Aug 20 14:48:14 cayman named[15423]: no source of entropy found
Aug 20 14:48:14 cayman named[15423]: dns_master_load: db.127.0.0:7: using RFC 1035 TTL semantics
Aug 20 14:48:14 cayman named[15423]: zone 0.0.127.IN-ADDR.ARPA/IN: loaded serial 1
Aug 20 14:48:14 cayman named[15423]: db.172:5: no TTL specified; using SOA MINTTL instead
Aug 20 14:48:14 cayman named[15423]: zone 172.IN-ADDR.ARPA/IN: loaded serial 2004081903
Aug 20 14:48:14 cayman named[15423]: dns_master_load: db.dv.workcoverqld:7: using RFC 1035 TTL semantics
Aug 20 14:48:14 cayman named[15423]: zone dv.workcoverqld.com.au/IN: loaded serial 2004081305
Aug 20 14:48:14 cayman named[15423]: dns_master_load: db.dv.workcover:7: using RFC 1035 TTL semantics
Aug 20 14:48:14 cayman named[15423]: zone dv.workcover.qld.gov.au/IN: loaded serial 2004081305
Aug 20 14:48:14 cayman named[15423]: running




############# T A H I T I : /var/adm/syslog/syslog.log ##############
Aug 20 14:47:16 tahiti named[23832]: starting BIND 9.2.3
Aug 20 14:47:16 tahiti named[23832]: using 2 CPUs
Aug 20 14:47:16 tahiti named[23832]: loading configuration from '/etc/named.conf'
Aug 20 14:47:16 tahiti named[23832]: no IPv6 interfaces found
Aug 20 14:47:16 tahiti named[23832]: listening on IPv4 interface lan0, 172.22.242.9#53
Aug 20 14:47:16 tahiti named[23832]: listening on IPv4 interface lo0, 127.0.0.1#53
Aug 20 14:47:16 tahiti named[23832]: command channel listening on 0.0.0.0#953
Aug 20 14:47:16 tahiti named[23832]: no source of entropy found
Aug 20 14:47:16 tahiti named[23832]: dns_master_load: db.testdom.dv.workcover:7: using RFC 1035 TTL semantics
Aug 20 14:47:16 tahiti named[23832]: zone testdom.dv.workcoverqld.com.au/IN: loaded serial 2004081302
Aug 20 14:47:16 tahiti named[23832]: dns_master_load: db.testdom.dv.workcoverqld:7: using RFC 1035 TTL semantics
Aug 20 14:47:16 tahiti named[23832]: zone testdom.dv.workcover.qld.gov.au/IN: loaded serial 2004081902
Aug 20 14:47:16 tahiti named[23832]: running

[support_5]

Hi Admins,

Well I've figured it out. It appears that my assumption was wrong when I said:

"We haven't yet made any changes to the zone files on noumea indicating that cayman is a name server for this sub-domain (I don't know if this will stuff things up or not, but I think it shouldn't)."

It appears that the chain of authority must exist for this to work. This is because if a ns is not authorative for the domain, then it will begin from the root name server (I'm assuming) and work its way down the chain of name servers till it reaches the ns that is authorative for the subdomain. However, if that is broken at any stage (as it was with me since I hadn't made any changes to the workcover.qld.gov.au domain servers files by adding the NS record for the dv sub domain), then it won't ever reach the bottom sub-domain name server.

so that resolves it. simple in the end wasn't it.

thanks anyway.

- Andy