[dns-operations] CNAME into a delegated zone goes wrong.... any ideas?
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
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