Fwd:CNAME into a delegated zone goes wrong.... any ideas?

NSD
1

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

2

Hi Jeroen,

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

3

* W. C. A. Wijngaards:

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,

I think you mean section 4.3.2.

I looked at it, and I couldn't find a way how it could produce two NS
RRsets in the authority section. But I interpret "If a match would
take us out of the authoritative data, we have a referral." narrowly,
that is, this happens only if the server is not authoritative for the
QNAME under consideration. A zone cut is not sufficient in my book.