children whose zones do not reflect the delegation from the parent

Wed Mar 30 03:45:57 UTC 2011

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