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

Edward Lewis Ed.Lewis at neustar.biz
Mon Jun 13 12:44:53 UTC 2011

At 8:54 +0100 6/13/11, Steven Carr wrote:

In other work, I wondered what was the source of putting the NS set 
in the authority section when the response was an authoritative 
answer.  More or less, it was determined to be a BIND-ism, based on 
some hazy specifications.  Not saying that BIND was wrong to do this, 
but many things we've come to take for granted slipped into the DNS 
in the older BINDs and never left.

My knee jerk reaction to  original post was that the response is a 
CNAME referral, with the thorn being that the answering server 
included the NS set backing the CNAME record itself.  BIND wouldn't 
do that when answering.

It's a fair question - is it a bug?  IMHO, including the NS to 
declare the authority of the answer section is kind of a bug, meaning 
the BIND-ism here.  But there's no specific reason you can't have 
both NS records.

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

That might be the right thing to do.  But it might not work.  Even if 
all BINDs from this day on are instructed to handle the response 
correctly there are all them old BINDs out there.  If the offending 
server here is not that widely deployed, then removing the NS set in 
question would be easier to do.

I would like to see both, really.  Make the BIND resolver that much 
more rugged.  And just get rid of that NS set.  Protocol-wise, it's 
not a significant transfer of data and probably the receiver will 
have it already or will get it in an answer sections somewhere. 
(Perhaps that is because of later progress than the particular 

P.S. - in the "Where have I seen this before" dept.:  The BIND-ism NS 
set is kind of like the DNSKEY (KEY) issue in early DNSSEC 
development when we sent the keys with every answer.  The keys were 
largely redundant reducing them to making the responses bigger for no 

Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

When talking about a long day keep this in mind (found on wikipedia.org):

Because the earliest and latest time zones are 26 hours apart, any given
calendar date exists at some point on the globe for 50 hours.

More information about the dns-operations mailing list