[dns-operations] CNAME into a delegated zone goes wrong.... any ideas?

[Steven Carr]

On 13 June 2011 02:33, Brett Frankenberger <rbf+dns-operations at panix.com> wrote:
> Is that clear from any RFC?  If ns.paphosting.net is queried for CNAME
> records at nto.us.sixxs.net, it properly returns the CNAME record, and
> includes only the sixxs.net records in the authority section.
>
> If the query is for AAAA records, it appears to add the CNAME record to
> the answer section, add the sixxs.net records to the authority section,
> then restart the query looking for the target of the CNAME record
> (us.ntp.sixxs.net).  Since it's not authoritative for the ntp.sixxs.net
> zone and isn't doing a recursive query, it can't answer that, but it is
> authoritative for the parent of that zone, so it adds ntp.sixxs.net to
> the authority section, reflecting the delegation of ntp.sixxs.net.
>
> Is there any RFC that makes it clear what should be done in this case?
> There seems to be three choices -- what is shown above (include both
> RRsets), include only sixxs.net NS RRSet to reflect the authority for
> the CNAME record that was returned (causing the resolver to then query
> for the target of the CNAME record to get the delegation), or include
> only the ntp.sixxs.net RRset for the delgation.

The only mention I could find is in rfc1034... "the name server
includes the CNAME
record in the response and restarts the query at the domain name
specified in the data field of the CNAME record." - which is what the
BIND resolver appears to do, but when it encounters the next set of
results it doesn't know what to do with them and drops the response.

This issue has been raised before on the NSD mailing list - so given
that Jeroen was also using NSD (and the zones which are being reported
previously are the same) then there is either a bug in NSD or
misconfiguration in the sixxs.net zone files.

http://permalink.gmane.org/gmane.network.dns.nsd.general/851
http://permalink.gmane.org/gmane.network.dns.nsd.general/863

It was suggested that the error be reported to bind9-bugs at isc.org
incase it could be an issue with the BIND resolver itself, not sure if
anyone did this (would be nice if ISC opened up their bug tracking -
hint, nudge) but it might be worth firing them an email to ask.

Steve

-- 
Indigo Solutions Europe Limited
www.indigo-solutions.eu