Subject: Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 24 Oct 2015 21:16:54 +0200

[Re-reading all emails...]

On Fri, Jul 10, 2015 at 11:53:30AM -0700,
 神明達哉 <[email-masked]> wrote 
 a message of 62 lines which said:

> Regarding Section 5 (possible side effect on root servers), I wonder
> about the implication of qname-minimization (which I expect will be
> deployed much sooner than this proposal).  A resolver that supports
> qname-minimization would first send a query to "local." to the root
> server upon receiving a "foo.local" query, and cache the result of
> NXDOMAIN for "local.".  It will suppress subsequent external queries
> for any subdomain of it.

Yes. Qname minimization relies on the fact that resolvers follow the
tree structure of the DNS. If "toto." does not exist, it means
"foobar.toto." certainly does not exist and there is no point querying
any authoritative server about it, a resolver can send back NXDOMAIN
immediately.

In ietf-dnsop-qname-minimisation-07, it is discussed in section 3.

---

From: P Vixie <[email-masked]>
Date: Sat, 24 Oct 2015 22:54:15 +0000

To me this is a feature, possibly the most important feature.

On October 25, 2015 6:16:54 AM GMT+11:00, Stephane Bortzmeyer <[email-masked]> wrote:
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 25 Oct 2015 11:49:14 +0100

On Sat, Oct 24, 2015 at 10:54:15PM +0000,
 P Vixie <[email-masked]> wrote 

> To me this is a feature, possibly the most important feature.

Specially now that Akamai's authoritative name servers properly handle
ENTs:

% dig A e8921.dscx.akamaiedge.net

; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> A e8921.dscx.akamaiedge.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33630
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;e8921.dscx.akamaiedge.net. IN A

;; ANSWER SECTION:
e8921.dscx.akamaiedge.net. 7 IN	A 104.85.82.14

;; AUTHORITY SECTION:
dscx.akamaiedge.net.	3987 IN	NS n0dscx.akamaiedge.net.
dscx.akamaiedge.net.	3987 IN	NS n6dscx.akamaiedge.net.
dscx.akamaiedge.net.	3987 IN	NS n3dscx.akamaiedge.net.
...

% dig @n6dscx.akamaiedge.net A dscx.akamaiedge.net 

; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @n6dscx.akamaiedge.net A dscx.akamaiedge.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11794
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;dscx.akamaiedge.net.	IN A

;; AUTHORITY SECTION:
dscx.akamaiedge.net.	1000 IN	SOA n0dscx.akamaiedge.net. hostmaster.akamai.com. (
				1445770097 ; serial
				1000       ; refresh (16 minutes 40 seconds)
				1000       ; retry (16 minutes 40 seconds)
				1000       ; expire (16 minutes 40 seconds)
				1800       ; minimum (30 minutes)
				)

;; Query time: 10 msec
;; SERVER: 2.16.117.216#53(2.16.117.216)
;; WHEN: Sun Oct 25 11:48:17 CET 2015
;; MSG SIZE  rcvd: 101

---

From: Paul Vixie <[email-masked]>
Date: Sun, 25 Oct 2015 23:39:25 -0700

sanity check, someone?

i believe that in dnssec, an empty non-terminal has a proof that the name 
exists, and a proof that there are no RR's. thus, vastly different from the 
signaling for NXDOMAIN.

this ought to end, for all time, the debate about whether empty nonterminals 
exist or not. (there are some authority servers who return NXDOMAIN for them, 
and we need to know whether those servers are wrong, before we advance query 
minimization.)

vixie

---

From: Ray Bellis <[email-masked]>
Date: Mon, 26 Oct 2015 09:08:46 +0000

On 26/10/2015 06:39, Paul Vixie wrote:
> sanity check, someone?
> 
> i believe that in dnssec, an empty non-terminal has a proof that the 
> name exists, and a proof that there are no RR's. thus, vastly 
> different from the signaling for NXDOMAIN.

RFC 4035 §3.1.3.2 appears to say differently :(

The subject of that section is "Including NSEC RRs: Name Error
Response", and it says:

"Note that this form of response includes cases in which SNAME
 corresponds to an empty non-terminal name within the zone (a name
 that is not the owner name for any RRset but that is the parent name
 of one or more RRsets)."

Paul and I already exchange mail off-list - I think we're both equally
surprised at the above.

Clarification from the authors of the rationale for this would be useful
here!

Ray

---

From: "Roy Arends" <[email-masked]>
Date: Mon, 26 Oct 2015 09:50:42 +0000

Speaking only for myself, though I happen to be one of the authors.

> Clarification from the authors of the rationale for this would be 

An Empty Non Terminal NoData response requires the same NSEC records as 
an Name Error Response.

Roy

---

From: Ray Bellis <[email-masked]>
Date: Mon, 26 Oct 2015 09:52:24 +0000

> An Empty Non Terminal NoData response requires the same NSEC records as

That's clear - what isn't perhaps, is what the RCODE should be, given
that this text is in a section with "Name Error" in its title.

Ray

---

From: Roy Arends <[email-masked]>
Date: Mon, 26 Oct 2015 10:12:42 +0000

> On 26 Oct 2015, at 09:52, Ray Bellis <[email-masked]> wrote:
> 
> 
> 

This section doesn’t give guidance on what RCODE to set.

I understand that you’re surprised and I hope I clarified it.

Roy

---

From: Ray Bellis <[email-masked]>
Date: Mon, 26 Oct 2015 10:15:37 +0000

> that this text is in a section with "Name Error" in its title.

For what it's worth, I expect the answer to be NOERROR, but I think the
text that lumps empty-non-terminals in with "name error" causes
sufficient ambiguity and confusion that an errata may be in order.

Ray

---

From: Evan Hunt <[email-masked]>
Date: Mon, 26 Oct 2015 15:32:19 +0000

> RFC 4035 §3.1.3.2 appears to say differently :(

But RFC 5155 is clear on the subject; empty non-terminal nodes are
mentioned under "no data" rather than "name error".

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Shumon Huque <[email-masked]>
Date: Mon, 26 Oct 2015 11:54:16 -0400

> ;; WARNING: recursion requested but not available

Hmm, what is the original full query name you were trying to resolve here
Stephane?

Perhaps it's fixed in the akamaiedge.net zone, but it isn't fixed in
another Akamai zone I just tested (edgesuite.net):

>> Resolving 'www.upenn.edu'
>> Query: edu. A IN at zone .
>>        [Got Referral to zone: edu.]
>> Query: upenn.edu. A IN at zone edu.
>>        [Got Referral to zone: upenn.edu.]
>> Query: www.upenn.edu. A IN at zone upenn.edu.
www.upenn.edu. 300 IN CNAME www.upenn.edu-dscg.edgesuite.net.
>> Query: net. A IN at zone .
>>        [Got Referral to zone: net.]
>> Query: edgesuite.net. A IN at zone net.
>>        [Got Referral to zone: edgesuite.net.]
>> Query: edu-dscg.edgesuite.net. A IN at zone edgesuite.net.
ERROR: NXDOMAIN: edu-dscg.edgesuite.net. not found
www.upenn.edu. 300 IN CNAME www.upenn.edu-dscg.edgesuite.net.

Shumon Huque

---

From: Ray Bellis <[email-masked]>
Date: Mon, 26 Oct 2015 15:59:10 +0000

> mentioned under "no data" rather than "name error".

Ah, thanks, that's useful to know, and further it specifically says that
the NSEC3 ETN response is different to an NSEC ETN response.

I still thinks that RFC 4035 merits an errata, with perhaps all that's
required is for the "Name Error" title to be expanded to say "Name Error
Response or Empty Non-Terminal Response" (thus avoiding any implication
that an ETN Response is a subset of a "Name Error Response").

Ray

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 26 Oct 2015 12:03:33 -0400

As a Chair, I'm actually very happy were' having deeper discussions 
around this draft.   I think there is some good work inside here, and it 
appears that the WG feels the same.

tim

---

From: Shumon Huque <[email-masked]>
Date: Mon, 26 Oct 2015 12:19:01 -0400

> that an ETN Response is a subset of a "Name Error Response").

I agree with Ray. An errata should be filed.

Shumon.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 26 Oct 2015 16:48:57 +0000

> sanity check, someone?

Yes, you're quite sane. :-)

> I believe that in dnssec, an empty non-terminal has a proof that the name 

Definitely.  

In my surveys of DANE adoption for SMTP, I'm exercising the
"authenticated denial of existence" support of a fairly large number
of nameservers (my scans cover ~5 million domains).

My validating recursor is unbound, and it rejects NXDOMAIN replies
in which the NSEC/NSEC3 records demonstrate that the qname is an
empty non-terminal.  Conversely it rejects NODATA replies where
the NSEC/NSEC3 records prove the non-existence of the qname.

When I've reported either issue to the responsible operators,
excepting cases where the guilty party has simply buried their head
in the sand and not responded, upgrades of the DNS software to a
more recent supported version (of say PowerDNS) have resolved the
problem.

> and we need to know whether those servers are wrong, before we advance query 

The servers that return NXDOMAIN for empty non-terminals are wrong.

Example:

    @nszero1.axc.nl.
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13022
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    ;_25._tcp.mail.maartenburie.nl. IN TLSA
    maartenburie.nl.        SOA     nszero1.axc.nl. hostmaster.maartenburie.nl. 2015013000 14400 3600 1209600 86400
    maartenburie.nl.        RRSIG   SOA 8 2 14400 20151105000000 20151015000000 56271 maartenburie.nl. ...
    maartenburie.nl.        NSEC    maartenburie.nl. A NS SOA MX TXT RRSIG NSEC DNSKEY
    maartenburie.nl.        RRSIG   NSEC 8 2 86400 20151105000000 20151015000000 56271 maartenburie.nl. ...

    $ unbound-host -t tlsa -v _25._tcp.mail.maartenburie.nl
    _25._tcp.mail.maartenburie.nl has no TLSA record (BOGUS (security failure))
    validation failure <_25._tcp.mail.maartenburie.nl. TLSA IN>: nodata proof failed from 159.253.2.101

The "proof" above is valid for NXDOMAIN, but not NODATA.  In this
case the problem is a bit more subtle, in addition to the zone
apex, this domain has a wildcard A record, but seems to leave it
out of the NSEC chain.  So NODATA is actually correct, but the NSEC
records are wrong.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 Oct 2015 10:59:54 +1100

In message <[email-masked]>, Ray Bellis writes:
> > =
> > i believe that in dnssec, an empty non-terminal has a proof that the =
> 
> > name exists, and a proof that there are no RR's. thus, vastly =
> 
> RFC 4035 =A73.1.3.2 appears to say differently :(
> 

It's a heads up to say you need to be very careful here.  The NSEC
record provides both noexistance and potentially existance proofs
for names in the range on the NSEC.  It's not saying the ENT get
Name Error.

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Oct 2015 19:03:34 -0700

> sufficient ambiguity and confusion that an errata may be in order.

strong +1.

names that don't exist can't have children.

-- 
P Vixie

---

From: Shumon Huque <[email-masked]>
Date: Mon, 26 Oct 2015 22:31:22 -0400

> names that don't exist can't have children.

I agree, however I'm slightly amused that we are having this discussion in
2015. Is there anyone that is claiming that the response code for empty
non-terminals should not be NOERROR. Yes, there are some CDNs and hosting
providers that currently issue Name Error for empty non-terminals, but
every one of them I've spoken to has positively acknowledged that this is a
defect that they are planning to fix.

If we need to provide a reference, RFC 4592, Section 2.2.2 has a pretty
good treatment of empty non-terminals (updating 1034), that pretty
definitively states that they exist, and thus their response code cannot be
Name Error.

Shumon.