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
