[nsd-users] Fwd:CNAME into a delegated zone goes wrong.... any ideas?

[W.C.A. Wijngaards]

-----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 section

Yes 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-----