strange response to the DS request

Mark Andrews marka at isc.org
Fri Mar 4 21:51:31 UTC 2016


In message <CAJE_bqeS996kOTuMv95wTz60De9fT1Q8yhM9q-2ZpsLa1YO3PA at mail.gmail.com>
, =?UTF-8?B?56We5piO6YGU5ZOJ?= writes:
> At Sat, 05 Mar 2016 07:23:46 +1100,
> Mark Andrews <marka at isc.org> wrote:
> 
> > There is nothing strange here beyond a missing delegation.
> 
> I'm not opposed to this conclusion itself, but:
> 
> > > If so, I agree it looks odd, and we might say it's against Section
> > > 2.2.1.2 of RFC3658 (if we superficially applied this section the answer
> > > would be NOERROR-NODATA with the SOA of www.example.com).
> >
> > No.  The algorithm stops at step 1.  Example.com "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
> >       answer.
> 
> But in this case the zone that would otherwise be the parent (
> example.com) does not delegate <QNAME> because there's no NS, so I
> thought step 1 didn't apply.

2.2.1.2 is written assuming delegations were correctly inserted in
parent zones by following RFC 1034.  Once you stop following RFC
1034 all bets are off.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


More information about the bind-users mailing list