strange response to the DS request
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
> > > 22.214.171.124 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.
126.96.36.199 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 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