In message <caje_bqes996kotumv95wtz60de9ft1q8yhm9q-2zpsla1yo...@mail.gmail.com> , =?UTF-8?B?56We5piO6YGU5ZOJ?= writes: > At Sat, 05 Mar 2016 07:23:46 +1100, > Mark Andrews <ma...@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: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
