strange response to the DS request

Mark Andrews marka at
Fri Mar 4 20:23:46 UTC 2016

In message <CAJE_bqc-QFMa_Mi=j1+npauT1U3DeYMFd=_Be8Wf4QBwwQswUw at>
, =?UTF-8?B?56We5piO6YGU5ZOJ?= writes:
> At Fri, 4 Mar 2016 14:07:03 +0900,
> Manabu Sonoda <manabu-s at> wrote:
> > I find the the strange response to the DS request.
> > That response answer type is CNAME.
> >
> > This can happen if Child and Parent zone in same nameserver and
> > Parent zone does not have NS recode for Child zone and
> > Parent zone have CNAME recode with the same name as Child zone.
> Do you mean, for example, if you configure a BIND 9 named as follows:
> - master zone '' which has the following CNAME:
> - master zone ''
> and send a query for, then named returns the above
> If so, I agree it looks odd, and we might say it's against Section
> of RFC3658 (if we superficially applied this section the answer
> would be NOERROR-NODATA with the SOA of

No.  The algorithm stops at step 1. "holds" the DS
if it existed.

   1) If the nameserver is authoritative for the zone that holds the DS
      RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent"
      zone), the response contains the DS RR set as an authoritative

There is nothing strange here beyond a missing delegation.
> But I'd say it's not specific to CNAME.  if you include
> in the zone instead of CNAME, the
> response to will be NOERROR-NODATA but with the SOA
> for, not  It might look less odd, but
> would still be considered broken.
> Also, if you configure named as follows instead:
> - master zone '' which has the following CNAME:
> - master zone ''
> and send a query for, named will return the
> DNAME.  This is another example to show it's not CNAME specific.
> I'm not sure whether we should do something about it, though.  As you
> pointed out, the configuration is already so broken: there's even no
> delegation from the parent (or ancestor) to the child zone, so I'm not
> sure if we can define any valid behavior in such a case based on
> RFC3658 or any other standard document.
> So I'm wondering: is this something odd you just happen to find in a
> test environment or something, or is there any practical issue because
> of that?
> --
> JINMEI, Tatuya
> _______________________________________________
> Please visit to unsubscribe
>  from this list
> bind-users mailing list
> bind-users at
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at

More information about the bind-users mailing list