There is NOTHING to accept here. The instructions are correct. e.root-servers.net is just broken and if all the root servers returned referrals like this the DS lookup from a STD13 server would result in all the root servers being queries and eventually SERVFAIL being return to the client.
Mark > On 11 Jan 2018, at 7:30 am, Warren Kumari <[email protected]> wrote: > > On Wed, Jan 3, 2018 at 1:31 PM, Peter van Dijk > <[email protected]> wrote: >> Output edited for brevity: >> >> $ dig ds root-servers.net @d.root-servers.net >> >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17643 >> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >> ;; WARNING: recursion requested but not available >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;root-servers.net. IN DS >> >> ;; AUTHORITY SECTION: >> root-servers.net. 3600000 IN SOA a.root-servers.net. >> nstld.verisign-grs.com. 2017111600 14400 7200 1209600 3600000 >> >> $ dig ds root-servers.net @e.root-servers.net >> >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26972 >> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27 >> ;; WARNING: recursion requested but not available >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;root-servers.net. IN DS >> >> ;; AUTHORITY SECTION: >> net. 172800 IN NS a.gtld-servers.net. >> net. 172800 IN NS b.gtld-servers.net. >> .. .. >> >> ;; ADDITIONAL SECTION: >> a.gtld-servers.net. 172800 IN A 192.5.6.30 >> b.gtld-servers.net. 172800 IN A 192.33.14.30 >> .. .. >> >> >> >> When running the query in the Subject, these are the two possible outputs I >> have observed from various root servers (with some variation from the same >> letter, presumably because of dual vendor strategies). >> >> From 4035 3.1.4.1, the NODATA response should be sent when: >> >> o The name server has received a query for the DS RRset at a zone >> cut. >> >> o The name server is authoritative for the child zone. >> >> o The name server is not authoritative for the parent zone. >> >> o The name server does not offer recursion. >> >> >> Points 1, 2 and 4 are clear. It is point 3 that hurts here. The root servers >> are authoritative for root-servers.net. and for . , but not for net - and >> they know this because they can see the delegation in the root zone. >> >> It is my suspicion that 3.1.4.1 was not written with this edge case in mind, >> and I think that while 3.1.4.1 favours the NODATA response, the referral is >> much more useful. As a data point, the PowerDNS validator currently gets in >> trouble with the NODATA response: >> https://github.com/PowerDNS/pdns/issues/6138 >> >> I think an erratum to 4035 is in order, clarifying the language such that >> servers would return the referral in this case. I have not figured out the >> exact wording yet (but I will). >> > > Errata are for fixing bugs ("Errata are meant to fix "bugs" in the > specification and should not be used to change what the community > meant when it approved the RFC." - > https://www.ietf.org/iesg/statement/errata-processing.html), not for > updating documents to add functionality / address cases which were not > originally considered (of course, that page does also say: "Common > sense and good judgment should be used by the IESG to decide what is > the right thing to do." :-)) > > So, if / when this is reported, please help me justify this as a bug > fix, and not adding functionality / changing the meaning of the > original doc. > > W > > >> What does dnsop think? >> >> Kind regards, >> -- >> Peter van Dijk >> PowerDNS.COM BV - https://www.powerdns.com/ >> >> _______________________________________________ >> DNSOP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
