hi- i'm curious for some feedback on something i've noticed here and there, and came across again the other day. my experience with dns, and the method which i've always practiced, is that when a zone is delegated, there should be agreement between the parent and the child - that is to say that whatever nameservers the parent lists for the zone, all children should also list.
i've noticed though, from time to time [it seems to be most common in in-addr.arpa. zones], i see a case where a parent has delegated a zone, but the child does not corroborate this delegation. an example is 33.50.in-addr.arpa. according to the parent, there are two nameservers responsible for this zone: >dig @dill.arin.net 33.50.in-addr.arpa ns +norec ; <<>> DiG 9.7.1-P2 <<>> @dill.arin.net 33.50.in-addr.arpa ns +norec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49118 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;33.50.in-addr.arpa. IN NS ;; AUTHORITY SECTION: 33.50.in-addr.arpa. 86400 IN NS AUTH01.ROC.NY.FRONTIERNET.NET. 33.50.in-addr.arpa. 86400 IN NS AUTH.LKV.MN.FRONTIERNET.NET. ;; Query time: 89 msec ;; SERVER: 192.35.51.32#53(192.35.51.32) ;; WHEN: Tue Mar 29 23:29:10 2011 ;; MSG SIZE rcvd: 105 when asking these two servers the same question, i expected them to provide the same answer [but in the answer section, of course] - but: >dig @auth01.roc.ny.frontiernet.net 33.50.in-addr.arpa ns +norec ; <<>> DiG 9.7.1-P2 <<>> @auth01.roc.ny.frontiernet.net 33.50.in-addr.arpa ns +norec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59545 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;33.50.in-addr.arpa. IN NS ;; Query time: 58 msec ;; SERVER: 66.133.170.3#53(66.133.170.3) ;; WHEN: Tue Mar 29 23:30:02 2011 ;; MSG SIZE rcvd: 36 >dig @auth.lkv.mn.frontiernet.net 33.50.in-addr.arpa ns +norec ; <<>> DiG 9.7.1-P2 <<>> @auth.lkv.mn.frontiernet.net 33.50.in-addr.arpa ns +norec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5181 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;33.50.in-addr.arpa. IN NS ;; Query time: 41 msec ;; SERVER: 66.133.150.11#53(66.133.150.11) ;; WHEN: Tue Mar 29 23:31:14 2011 ;; MSG SIZE rcvd: 36 both fail to do so. so - it would seem to me that at least somehow, in some sense, the delegation is broken. however, if queried further for a /24 within that /16, both servers now work "properly", and further delegate to other servers [and themselves]: >dig @auth.lkv.mn.frontiernet.net 151.33.50.in-addr.arpa ns +norec ; <<>> DiG 9.7.1-P2 <<>> @auth.lkv.mn.frontiernet.net 151.33.50.in-addr.arpa ns +norec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62298 ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3 ;; QUESTION SECTION: ;151.33.50.in-addr.arpa. IN NS ;; ANSWER SECTION: 151.33.50.in-addr.arpa. 86400 IN NS auth.dlls.pa.frontiernet.net. 151.33.50.in-addr.arpa. 86400 IN NS auth.lkvl.mn.frontiernet.net. 151.33.50.in-addr.arpa. 86400 IN NS auth.roch.ny.frontiernet.net. ;; ADDITIONAL SECTION: auth.dlls.pa.frontiernet.net. 86400 IN A 199.224.64.201 auth.lkvl.mn.frontiernet.net. 86400 IN A 66.133.150.11 auth.roch.ny.frontiernet.net. 86400 IN A 66.133.170.3 ;; Query time: 42 msec ;; SERVER: 66.133.150.11#53(66.133.150.11) ;; WHEN: Tue Mar 29 23:32:32 2011 ;; MSG SIZE rcvd: 184 those servers all properly answer queries for that /24: >dig @auth.dlls.pa.frontiernet.net 1.151.33.50.in-addr.arpa ptr +norec ; <<>> DiG 9.7.1-P2 <<>> @auth.dlls.pa.frontiernet.net 1.151.33.50.in-addr.arpa ptr +norec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53648 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.151.33.50.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.151.33.50.in-addr.arpa. 86400 IN PTR static-50-33-151-1.mskg.mi.frontiernet.net. ;; Query time: 76 msec ;; SERVER: 199.224.64.201#53(199.224.64.201) ;; WHEN: Tue Mar 29 23:33:42 2011 ;; MSG SIZE rcvd: 98 but, interestingly, also, so do their parents [auth01.roc.ny.frontiernet.net and auth.lkv.mn.frontiernet.net]: >dig @auth01.roc.ny.frontiernet.net 1.151.33.50.in-addr.arpa ptr +norec ; <<>> DiG 9.7.1-P2 <<>> @auth01.roc.ny.frontiernet.net 1.151.33.50.in-addr.arpa ptr +norec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21100 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.151.33.50.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.151.33.50.in-addr.arpa. 86400 IN PTR static-50-33-151-1.mskg.mi.frontiernet.net. ;; Query time: 59 msec ;; SERVER: 66.133.170.3#53(66.133.170.3) ;; WHEN: Tue Mar 29 23:35:30 2011 ;; MSG SIZE rcvd: 98 i see that two of these servers actually appear to be the same server, referenced by different hostnames: >dig auth01.roc.ny.frontiernet.net +short 66.133.170.3 >dig auth.roch.ny.frontiernet.net +short 66.133.170.3 >dig auth.lkv.mn.frontiernet.net +short 66.133.150.11 >dig auth.lkvl.mn.frontiernet.net +short 66.133.150.11 ultimately, when making a recursive query and asking bind to do an iterative lookup, it appears to work: >dig -x 50.33.151.1 ; <<>> DiG 9.7.1-P2 <<>> -x 50.33.151.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42628 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.151.33.50.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.151.33.50.in-addr.arpa. 86400 IN PTR static-50-33-151-1.mskg.mi.frontiernet.net. ;; Query time: 553 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Mar 29 23:41:54 2011 ;; MSG SIZE rcvd: 98 which leaves me sort of scratching my head. on the one hand, pretty much everything i've learned about dns says that it shouldn't work, but yet it seems to. added to that, the way delegation has been done seems just a bit odd to me in general. i'm hoping someone can offer some insight on the topic. thanks- -ben _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
