Jeroen Massar
2011-Jun-12 22:50 UTC
[nsd-users] Fwd:CNAME into a delegated zone goes wrong.... any ideas?
As just briefly discussed on dns-operations:> Because there is an error in the zone configuration, the logs on my > BIND server show: > > 12-Jun-2011 23:23:07.419 DNS format error from 62.220.146.194#53 > resolving ntp.us.sixxs.net/A for client 172.16.0.20#62548: multiple NS > RRsets in authority section > 12-Jun-2011 23:23:07.502 DNS format error from 94.142.245.3#53 > resolving ntp.us.sixxs.net/A for client 172.16.0.20#62548: multiple NS > RRsets in authority section > > The authority records that come back from a "dig @ns.paphosting.net > ntp.us.sixxs.net" show... > ;; AUTHORITY SECTION: > ntp.sixxs.net. 3600 IN NS ns1.sixxs.net. > ntp.sixxs.net. 3600 IN NS ns2.sixxs.net. > ntp.sixxs.net. 3600 IN NS ns3.sixxs.net. > sixxs.net. 3600 IN NS ns.paphosting.net. > sixxs.net. 3600 IN NS ns.paphosting.nl. > sixxs.net. 3600 IN NS ns.paphosting.eu. > > ...therefore BIND doesn't know who to query and drops it - the > sixxs.net. servers should not be being returned in the Authority, > there is no real need to return them at all, but if it does then they > should be in the Additional section.Why is nsd putting the ntp.sixxs.net NS entries in auth and not in additional? (ns.paphosting.* and ns*.sixxs.net are all nsd btw) Anything we configured wrong, or just weird enough that it causes this behavior? What to do to resolve this? Greets, Jeroen
W.C.A. Wijngaards
2011-Jun-14 10:21 UTC
[nsd-users] Fwd:CNAME into a delegated zone goes wrong.... any ideas?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jeroen, On 06/13/2011 12:50 AM, Jeroen Massar wrote:> As just briefly discussed on dns-operations: > >> Because there is an error in the zone configuration, the logs on my >> BIND server show: >> >> 12-Jun-2011 23:23:07.419 DNS format error from 62.220.146.194#53 >> resolving ntp.us.sixxs.net/A for client 172.16.0.20#62548: multiple NS >> RRsets in authority section >> 12-Jun-2011 23:23:07.502 DNS format error from 94.142.245.3#53 >> resolving ntp.us.sixxs.net/A for client 172.16.0.20#62548: multiple NS >> RRsets in authority sectionYes it is certainly strange to get a packet like that.>> The authority records that come back from a "dig @ns.paphosting.net >> ntp.us.sixxs.net" show... >> ;; AUTHORITY SECTION: >> ntp.sixxs.net. 3600 IN NS ns1.sixxs.net. >> ntp.sixxs.net. 3600 IN NS ns2.sixxs.net. >> ntp.sixxs.net. 3600 IN NS ns3.sixxs.net. >> sixxs.net. 3600 IN NS ns.paphosting.net. >> sixxs.net. 3600 IN NS ns.paphosting.nl. >> sixxs.net. 3600 IN NS ns.paphosting.eu. >> >> ...therefore BIND doesn't know who to query and drops it - the >> sixxs.net. servers should not be being returned in the Authority, >> there is no real need to return them at all, but if it does then they >> should be in the Additional section.No, not in the additional section. But you are right they should not be returned. This is not obvious, the algorithm in 3.4.2 of RFC 1034 seems to be a bit hazy on it, but example 6.2.7 shows that CNAMEs do not get the authority-NS-set for the zone appended. Thus, the fix is to make NSD not append the NS-authority-set for CNAMEs. - --- query.c (revision 3379) +++ query.c (working copy) @@ -923,6 +923,9 @@ domain_dname(closest_match)); q->zone = origzone; } + /* example 6.2.7 shows no NS-set in auth (RFC1034) */ + q->domain = domain; + return; } else { answer_nodata(q, answer, original); return;> Why is nsd putting the ntp.sixxs.net NS entries in auth and not in > additional? (ns.paphosting.* and ns*.sixxs.net are all nsd btw)It was following the algorithm in RFC 1034 and the CNAME got NS-authority-from-originating-zone processing.> Anything we configured wrong, or just weird enough that it causes this > behavior? What to do to resolve this?I think this bugfix should solve the issue, the patch you can apply to get the fix right away. You would think the problem could potentially occur with DNAMEs too, but NSD already does the right thing with DNAMEs (and their synthesized CNAMEs). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN9zYoAAoJEJ9vHC1+BF+Nv0IP/3Fhv7Pn5A1/p4Zlu1+091TW BEQCG8p2yZRGkpIdNWeqA4Nmd2PP3+i8SzAeDaQN0O90iZU960MNboJChEVvn9M5 pKwxBlQL3pWlaZ2ziyKvzJRVqmo6+WM+oBg8JkA5UXtEiIsPgi7QyVy+Hg226UQl esNbYs9Mnn2PFs+pzaiaohbr7MK/Y+fPnnAHrI/o+YIcO1r65SYguxwMplQczf1j 4Lm//51CiJGkYTsI0GHWFDXANttczZxxVa8lKFlcBEIKGJeTokC5j4x7zLNeyXxp 4fBIyBR/0hwD1RARpa5/D2EZcZCYm56OaAXqrFY8PK7eDPkY3hj5yQliNunuwrg7 9B37j+0agjJ8UeWsU6i+9rB8F/VR3niDnBJxpjpo+Lt99DFEqB0hZ7tR7GySBl6J pcp0fdt/j+VbI4in2oZsf/3U5nCUaCK9+rd7l6Mpf1CWUiEMtobbisBTHNnwV6+u KL7b1A1H51NbLOStDjunPXOvai80lBJXfy+n1/3mnk/leeyjoTKUMLa3eSK5IenC SASxk5HDq/2fJaj03u8ktnahYe2T3w3Q05nYLRTPxfUx5C5ycyzgPDj1UnKeHSNq LhXhZ7YcZN+/lUi3tBZ7/fIbzuvcdOVG66/58iPhzH3oNwUwmvSBwPWWUbiIlAgC x3SbxjNI5cT0TMokABLc =0NQ4 -----END PGP SIGNATURE-----