Subject: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

From: "Peter van Dijk" <[email-masked]>
Date: Wed, 03 Jan 2018 19:31:07 +0100

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).

What does dnsop think?

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Marek Vavruša <[email-masked]>
Date: Wed, 3 Jan 2018 11:09:32 -0800

That's a good point. Personally, I'd favour a referral response since
it saves resolver a round trip (at least for resolvers not doing QNAME
minimisation), it seems in conflict with 3.1.4.1 though as you pointed
here.

Marek

On Wed, Jan 3, 2018 at 10:31 AM, Peter van Dijk
<[email-masked]> wrote:
> 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).
>
> 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:
> 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).
>
> What does dnsop think?
>
> Kind regards,
> --
> Peter van Dijk
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: Wed, 03 Jan 2018 12:22:44 -0800

> minimisation), it seems in conflict with 3.1.4.1 though as you pointed

...

>> exact wording yet (but I will).

i think as you and marek do.

-- 
P Vixie

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 3 Jan 2018 21:52:56 +0100

> What does dnsop think? 

I also prefer referral in this case, as it seems to make more sense for
resolvers.  (For public reference, as we've discussed more directly.) 
And thank you for bringing this problem to attention.

How to best formulate a generic rule is a more difficult question.

--Vladimir

---

From: Mark Andrews <[email-masked]>
Date: Thu, 4 Jan 2018 08:12:26 +1100

The reply also has to work for STD13 clients which already know about the child zone. The NODATA response is the correct one despite it requiring more work for a DNSSEC client. 

-- 
Mark Andrews

> On 4 Jan 2018, at 05:31, Peter van Dijk <[email-masked]> wrote:
> 
> root-servers.net.    3600000    IN    SOA    a.root-servers.net. nstld.verisign-grs.com. 2017111600 14400 7200 1209600 3600000
> 
> 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).
> 
> 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).
> 
> What does dnsop think?
> 
> Kind regards,
> -- 
> Peter van Dijk

---

From: 神明達哉 <[email-masked]>
Date: Fri, 5 Jan 2018 10:27:31 -0800

At Thu, 4 Jan 2018 08:12:26 +1100,
Mark Andrews <[email-masked]> wrote:

> The reply also has to work for STD13 clients which already know
> about the child zone. The NODATA response is the correct one despite
> it requiring more work for a DNSSEC client.

Section 2.2.1.1 of RFC 3658 also explains that point:

   [...]  As these queries are only expected to originate
   from recursive nameservers which are not DS-aware, the authoritative
   nameserver MUST answer with:

      RCODE:             NOERROR
      AA bit:            set
      Answer Section:    Empty
      Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]

   That is, it answers as if it is authoritative and the DS record does
   not exist.  DS-aware recursive nameservers will query the parent zone
   at delegation points, so will not be affected by this.

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Wed, 10 Jan 2018 15:30:49 -0500

> 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

-- 
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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Jan 2018 07:42:49 +1100

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-masked]> wrote:
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 10 Jan 2018 17:05:00 -0800

>    at delegation points, so will not be affected by this.
I hate having my own RFC thrown at me,
but it may or may not apply as there is another corner case that I/WG did
not consider,
what if the NameServer is authoritative for a zone above the parent.
In this case it has to select does it answer from the closest zone that can
answer DS record or
from the zone it self.

In the spirit of being helpful to recursive resolvers the right answer IMHO
is the referral from the
zone above the query name.

  Olafur

---

From: 神明達哉 <[email-masked]>
Date: Thu, 11 Jan 2018 11:26:26 -0800

At Wed, 10 Jan 2018 17:05:00 -0800,

> zone above the query name.

I'm not sure if I understand you so please let me be more explicit.
Are you talking about the so-called grandparent problem case, like the
case of this thread?

>> The root servers are authoritative for root-servers.net. and for . , but not for net

and, when this server gets a query for root-servers.net/DS, it should
return a referral to net instead of NODATA answer?  (If so, I'm
confused about what you said above "another corner case that I/WG did
not consider", since 2.2.1.2 of RFC3658 actually talks about that
corner case).

--
JINMEI, Tatuya

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 11 Jan 2018 11:29:20 -0800

> Are you talking about the so-called grandparent problem case, like the

yes

---

From: 神明達哉 <[email-masked]>
Date: Thu, 11 Jan 2018 18:11:41 -0800

At Thu, 11 Jan 2018 11:29:20 -0800,

Okay, then, I don't think this is correct:

>> but it may or may not apply as there is another corner case that I/WG did not consider,

in that you should have considered it at the time of drafting RFC3658
(Section 2.2.1.2.).  And, at the risk stating something too obvious to
you, my understanding of the rationale of the RFC is that:

  when a server authoritative for root-servers.net. and for . , but
  not for net receives a query for root-servers.net/DS and if it
  returns a referral to net, a non-DNSSEC-aware resolver can consider
  it a lame delegation, since the resolver may think it already
  reaches the root-servers.net zone but see a referral higher than
  that.

This makes sense to me.  Now, given you should already well understand
it, perhaps you mean this case should be considered too minor and it's
better to make DNSSEC-aware resolvers happier at the cost of making
older resolvers suffer from false-lame?  If so, I see it's worth
discussing.  But IMO that would be far beyond the scope of an errata
(as this thread originally suggests) - it should be discussed in a
scope of some official bis specification.

--
JINMEI, Tatuya