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

[Samuel Weiler]

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.


Yes, it does.  With NSEC3 it is an explicit proof.  With NSEC you have to 
read between the lines.


NSEC3: see RFC5155 sections 7.1 and B.2.1.

NSEC: if foo.example is an empty non-terminal, then there will exist an 
NSEC record such as "echo.example NSEC alpha.foo.example ..." - the ENT's 
name is part of the "next domain name".


-- Sam

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Roy Arends]

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

On 26 Oct 2015, at 9:08, Ray Bellis wrote:


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!


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


Roy




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ray Bellis]

On 26/10/2015 09:52, I wrote:

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ray Bellis]

On 26/10/2015 09:50, Roy Arends wrote:
> Speaking only for myself, though I happen to be one of the authors.
>
> ...
>
> An Empty Non Terminal NoData response requires the same NSEC records as
> an Name Error Response.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Roy Arends]

> On 26 Oct 2015, at 09:52, Ray Bellis  wrote:
> 
> 
> 
> On 26/10/2015 09:50, Roy Arends wrote:
>> Speaking only for myself, though I happen to be one of the authors.
>> 
>> ...
>> 
>> An Empty Non Terminal NoData response requires the same NSEC records as
>> an Name Error Response.
> 
> 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.

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

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

Roy





___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ray Bellis]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

In message <562ded9e.40...@bellis.me.uk>, Ray Bellis writes:
> 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 =A73.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)."

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.

> 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
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

On Monday, October 26, 2015 10:15:37 AM Ray Bellis wrote:
> On 26/10/2015 09:52, I wrote:
> > 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.
> 
> 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.

strong +1.

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

-- 
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Mon, Oct 26, 2015 at 10:03 PM, Paul Vixie  wrote:

> On Monday, October 26, 2015 10:15:37 AM Ray Bellis wrote:
> > On 26/10/2015 09:52, I wrote:
> > > 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.
> >
> > 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.
>
> strong +1.
>
> 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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

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


On 10/26/15 11:59 AM, Ray Bellis wrote:



On 26/10/2015 15:32, Evan Hunt wrote:


But RFC 5155 is clear on the subject; empty non-terminal nodes are
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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Evan Hunt]

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

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

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Mon, Oct 26, 2015 at 11:59 AM, Ray Bellis  wrote:

>
>
> On 26/10/2015 15:32, Evan Hunt wrote:
>
> > But RFC 5155 is clear on the subject; empty non-terminal nodes are
> > 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").
>

I agree with Ray. An errata should be filed.

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Sun, Oct 25, 2015 at 6:49 AM, Stephane Bortzmeyer 
wrote:

> On Sat, Oct 24, 2015 at 10:54:15PM +,
>  P Vixie  wrote
>  a message of 73 lines which said:
>
> > To me this is a feature, possibly the most important feature.
>
> Specially now that Akamai's authoritative name servers properly handle
> ENTs:
>
> % 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
>


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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ray Bellis]

On 26/10/2015 15:32, Evan Hunt wrote:

> But RFC 5155 is clear on the subject; empty non-terminal nodes are
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Viktor Dukhovni]

On Sun, Oct 25, 2015 at 11:39:25PM -0700, Paul Vixie wrote:

> sanity check, someone?

Yes, you're quite sane. :-)

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

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.

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

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 2015110500 2015101500 
56271 maartenburie.nl. ...
maartenburie.nl.NSECmaartenburie.nl. A NS SOA MX TXT RRSIG NSEC 
DNSKEY
maartenburie.nl.RRSIG   NSEC 8 2 86400 2015110500 
2015101500 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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Stephane Bortzmeyer]

On Sat, Oct 24, 2015 at 10:54:15PM +,
 P Vixie  wrote 
 a message of 73 lines which said:

> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Stephane Bortzmeyer]

[Re-reading all emails...]

On Fri, Jul 10, 2015 at 11:53:30AM -0700,
 神明達哉  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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[P Vixie]

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

On October 25, 2015 6:16:54 AM GMT+11:00, Stephane Bortzmeyer 
 wrote:
>[Re-reading all emails...]
>
>On Fri, Jul 10, 2015 at 11:53:30AM -0700,
> 神明達哉  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.
>
>___
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[fujiwara]

Thanks to Jinmei, Shumon and Mark.

 From: 神明達哉 jin...@wide.ad.jp
 While I see what it tries to say and don't disagree with it, I think
 this is not very accurate.  In fact, NXDOMAIN for a.example.com says
 there is no such name *or any subdomain of it*.  So it would still be
 usable to suppress unnecessary external query for, e.g.,
 foo.a.example.com.

I will add some text in next revision.

 From: Shumon Huque shu...@gmail.com
 That's indeed the literal meaning of NXDOMAIN, but it turns out most
 current resolver implementations don't treat it that way. The wording in
 RFC2308, Section 5 is not entirely precise, but it seems to say that
 negative answers should be cached only for the exact qname, and not
 (necessarily) for anything below it.

 From: Mark Andrews ma...@isc.org
 Because the consensus at the time was not to support nxdomain
 synthesis from signed zone (speaketh the author of RFC 2308).

I will add texts to update RFC 2308.

 Extreme care needs to be taken with nxdomain synthesis. You need
 to choose the correct NSEC records especially for qnames which are
 the subdomain of the NSEC owner name.  The NS bit MUST NOT be set
 in this case as the presence of the NS bit indicates a delegation.
 
 NSEC3 is even more complicted.

YES.

 DLV is only defined to use NSEC signed zones as I wasn't interested
 in having to working out all the rules for NSEC3.

I think the procedure is the same as NSEC3 validation.

# and qname minimization discussion is interesting.
# It may be listed in draft-ietf-dnsop-root-loopback 
# as a different approach.

--
Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Casey Deccio]

Hi,

Some thoughts below, strictly on the NSEC/NSEC3 algorithm.  They're quite
rough, but hopefully they're useful.

Cheers,
Casey

On Tue, Jul 7, 2015 at 5:20 AM, fujiw...@jprs.co.jp wrote:

 Please check this algorithm.


Several times, the phrase query as usual is used.  However, something
might need to be said about the resolver modifying query as usual to save
NSEC/NSEC3 records associated with wildcard and negative responses in a way
that they can be used by the algorithm.

For example, the following indexes could be maintained:

Indexes:
NSEC_TABLE = a canonically ordered mapping of NSEC owner names to NSEC
records, grouped by corresponding SOA name
NSEC3_TABLE = a canonically ordered mapping of NSEC3 owner names to NSEC3
records, grouped by corresponding SOA name and NSEC3 parameters
NSEC3_NAMES = a canonically ordered mapping of names to their corresponding
NSEC3-hashed names (or records)

QNAME = the query name;
 if (QNAME name entry exists in the cache) {
 resolve the query as usual;
 // if RRSet (query name and query type) exists in the cache,
 // the resolver responds the RRSet from the cache
 // Otherwise, the resolver needs to iterate the query.
 }

 // Find closest enclosing NS RRset in the cache.
 // The owner of this NS RRset will be a suffix of the QNAME
 //- the longest suffix of any NS RRset in the cache.
 SIGNER = closest enclosing NS RRSet of QNAME in the cache;


You should now find the SOA record corresponding to SIGNER.  If there is no
SOA record in cache, then there are no previously cached negative
responses, so you can resolve the query as usual.

if (SIGNER zone does not have a special NSEC/NSEC3 data structure) {
 Resolve the query as usual;
 }


I'm not sure what this means.


 if (SIGNER zone is not signed or not validated) {
Resolve the query as usual;
 }


You mean here: if the SOA record is not validated (signed is implied by
validated).

While colloquially we talk about zones being signed, in this case, you want
an actual RRset--one that matters at that.  The SOA record fits the bill
here because of its role with negative responses.


 if (SIGNER zone is signed with NSEC) {


While in theory a zone is signed with either NSEC or NSEC3, in practice all
that matters is the NSEC or NSEC3 proofs provided in individual responses.
While not necessarily desirable, it is entirely possible that subsequent
responses could different NSEC/NSEC3 results.  Therefore, for algorithm
robustness, checking whether a zone is signed with NSEC or NSEC3 is less
useful than simply looking at both NSEC and NSEC3 records in the cache.

I would eliminate if SIGNER zone is signed with NSEC and its
corresponding else/else if altogether.  You should really check both
NSEC and NSEC3.

BEGIN NSEC SECTION

 if (covering NSEC RR of QNAME at SIGNER zone
doesn't exist in the cache) {
 Resolve the query as usual.
 }


s/Resolve the query as usual/Go to NSEC3 SECTION/



 TEST = Find the longest existing domain name of QNAME
from the covering NSEC RR;


You could use the term closest encloser/CLOSEST_ENCLOSER instead of
longest existing domain name/TEST.

if (*.TEST name entry exists in the cache) {
 the resolver can generate positive response
 or resolve the query as usual;
 }


s/resolve the query as usual/Go to the NSEC3 SECTION

It could be a NODATA response (which is a negative response), if the type
doesn't exist.  Although, I think that's what you mean by positive
response or resolve the query as usual.


 if covering NSEC RR of *.TEST at SIGNER zone exists
  in the cache {
 the resolver can generate negative response;
 }


s/resolver can generate negative response/Return synthesized negative
response/


 // Lack of information, need to resolve the query as usual


No. move on to NSEC3 now.


 } else

if (SIGNER zone is signed with NSEC3 and does not use Opt-Out) {


Eliminate this else if SIGNER zone is signed with NSEC3 and does not use
Opt-out check too.

BEGIN NSEC3 SECTION

TEST = SIGNER;


Again, I would look for closest encloser (CLOSEST_ENCLOSER) here (e.g.,
using the NSEC3_NAMES table).  There might be multiple NSEC3 records for a
single closest encloser if multiple sets of NSEC3 parameters are used
across different responses, but really all you need is one.  In this case,
you would need to iterate through the different sets of NSEC3 parameters.

Once you have the closest encloser, the algorithm looks more (but not
entirely) like the NSEC portion above, but with NSEC3 instead.  I'm not
sure I follow the logic in the previously written NSEC3 section.  I've made
some modifications below.

   if (no CLOSEST_ENCLOSER is found) {
Go to FALLBACK SECTION
}

NEXT_CLOSEST_ENCLOSER_PROOF_FOUND = False
 for each set of parameters corresponding to NSEC3 names in the appropriate
zone {
if (there is a NSEC3 RR covering the next closest encloser (i.e.,

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

[Shumon Huque]

On Tue, Jul 14, 2015 at 1:00 PM, 神明達哉 jin...@wide.ad.jp wrote:

 At Mon, 13 Jul 2015 22:01:29 -0400,
 Shumon Huque shu...@gmail.com wrote:

  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, this will certainly be a very beneficial result of qname
 minimization.

 And the same remark should apply here, too.  We'd need Stopping
 Downward Cache Search on NXDOMAIN in addition to qname minimization
 for this to work.


I think we can distinguish the negative caching algorithm and the iterative
resolution algorithm.

The current iterative resolution algorithm already interprets NXDOMAIN
literally (unlike negative caching), so I don't think we need to explicitly
say this for the qname minimization variant of iterative resolution either.
However, I suppose there's no harm in adding explicit text around this
point.

Shumon Huque
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

At Mon, 13 Jul 2015 22:01:29 -0400,
Shumon Huque shu...@gmail.com wrote:

  While I see what it tries to say and don't disagree with it, I think
  this is not very accurate.  In fact, NXDOMAIN for a.example.com says
  there is no such name *or any subdomain of it*.  So it would still be
  usable to suppress unnecessary external query for, e.g.,
  foo.a.example.com.

 That's indeed the literal meaning of NXDOMAIN, but it turns out most
 current resolver implementations don't treat it that way. The wording in
 RFC2308, Section 5 is not entirely precise, but it seems to say that
 negative answers should be cached only for the exact qname, and not
 (necessarily) for anything below it.

Ah, yes, thanks for pointing it out.  I don't know or didn't check
other resolver implementations, but BIND 9 certainly behaves that way.
I should have known this, but I guess I was confused about the
meaning of NXDOMAIN, the behavior of authoritative server
implementations and the behavior of recursive server implementations.

 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, this will certainly be a very beneficial result of qname minimization.

And the same remark should apply here, too.  We'd need Stopping
Downward Cache Search on NXDOMAIN in addition to qname minimization
for this to work.

--
JINMEI, Tatuya

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

In message CAHPuVdU-1e_7KPH9JdSvbPn-tYptaXbHrQvQz=uev+qjdse...@mail.gmail.com
, Shumon Huque writes:
 
 On Fri, Jul 10, 2015 at 2:53 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 jinm=
 e...@wide.ad.jp wrote:

  On Tue, Jul 7, 2015 at 2:20 AM,  fujiw...@jprs.co.jp wrote:
  [...]
  In Introduction it states:
 
 While negative (non-existence) information of DNS caching mechanism
 has been known as DNS negative cache [RFC2308], it requires exact
 matching in most cases.  [...]
 This was because the NXDOMAIN response just says
 there is no such name a.example.com and it doesn't tell anything
 for b.example.com.
 
  While I see what it tries to say and don't disagree with it, I think
  this is not very accurate.  In fact, NXDOMAIN for a.example.com says
  there is no such name *or any subdomain of it*.  So it would still be
  usable to suppress unnecessary external query for, e.g.,
  foo.a.example.com.
 

 That's indeed the literal meaning of NXDOMAIN, but it turns out most
 current resolver implementations don't treat it that way. The wording in
 RFC2308, Section 5 is not entirely precise, but it seems to say that
 negative answers should be cached only for the exact qname, and not
 (necessarily) for anything below it.

Because the consensus at the time was not to support nxdomain
synthesis from signed zone (speaketh the author of RFC 2308).

Extreme care needs to be taken with nxdomain synthesis. You need
to choose the correct NSEC records especially for qnames which are
the subdomain of the NSEC owner name.  The NS bit MUST NOT be set
in this case as the presence of the NS bit indicates a delegation.

NSEC3 is even more complicted.

DLV is only defined to use NSEC signed zones as I wasn't interested
in having to working out all the rules for NSEC3.

 Section 3 of http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00
 (Stopping Downward Cache Search on NXDOMAIN) proposed to fix this
 resolver behavior. It would be great if this was standardized and adopted.

 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, this will certainly be a very beneficial result of qname
 minimization.

 Shumon.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Fri, Jul 10, 2015 at 2:53 PM, 神明達哉 jin...@wide.ad.jp wrote:

 On Tue, Jul 7, 2015 at 2:20 AM,  fujiw...@jprs.co.jp wrote:
 [...]
 In Introduction it states:

While negative (non-existence) information of DNS caching mechanism
has been known as DNS negative cache [RFC2308], it requires exact
matching in most cases.  [...]
This was because the NXDOMAIN response just says
there is no such name a.example.com and it doesn't tell anything
for b.example.com.

 While I see what it tries to say and don't disagree with it, I think
 this is not very accurate.  In fact, NXDOMAIN for a.example.com says
 there is no such name *or any subdomain of it*.  So it would still be
 usable to suppress unnecessary external query for, e.g.,
 foo.a.example.com.


That's indeed the literal meaning of NXDOMAIN, but it turns out most
current resolver implementations don't treat it that way. The wording in
RFC2308, Section 5 is not entirely precise, but it seems to say that
negative answers should be cached only for the exact qname, and not
(necessarily) for anything below it.

Section 3 of http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00
(Stopping Downward Cache Search on NXDOMAIN) proposed to fix this
resolver behavior. It would be great if this was standardized and adopted.

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, this will certainly be a very beneficial result of qname minimization.

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[fujiwara]

 From: Bob Harold rharo...@umich.edu
 On Tue, Jul 7, 2015 at 5:20 AM, fujiw...@jprs.co.jp wrote:
 
 Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01.


 https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/


 ...
 
 --
 Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp

 I am concerned that the AN flag allows for easy zone walking, defeating
 the purpose of minimal range NSEC records.  So I don't think authoritative
 servers would want to respect it.

It's the problem.
However, authoritative DNS servers can detect random subdomain attacks.
They can generate NSEC resource records with wider range
under random subdomain attacks.

 I am also concerned that random subdomain queries will set the CD bit, if
 that avoids aggressive negative caching.  So I would think that the CD bit
 should not be allowed to stop aggressive negative caching.

Thanks.
I will add.

Regards,

--
Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[fujiwara]

Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01.

  https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/

* Added reference to DLV {{RFC5074}} and imported some sentences.
* Added Aggressive Negative Caching Flag idea.
* Added detailed algorithms in Appendix.

Please check and comment.

I made a mistake at detailed algorithm part in -01.
I added updated version in this mail and I will update the draft.
NSEC3 validation is difficult for me.
Please check this algorithm.

And where is the pseudo code writing guide ?

~~~
QNAME = the query name;
if (QNAME name entry exists in the cache) {
resolve the query as usual;
// if RRSet (query name and query type) exists in the cache,
// the resolver responds the RRSet from the cache
// Otherwise, the resolver needs to iterate the query.
}

// Find closest enclosing NS RRset in the cache.
// The owner of this NS RRset will be a suffix of the QNAME
//- the longest suffix of any NS RRset in the cache.
SIGNER = closest enclosing NS RRSet of QNAME in the cache;

if (SIGNER zone does not have a special NSEC/NSEC3 data structure) {
Resolve the query as usual;
}

if (SIGNER zone is not signed or not validated) {
   Resolve the query as usual;
}

if (SIGNER zone is signed with NSEC) {
// NSEC mode
if (covering NSEC RR of QNAME at SIGNER zone
   doesn't exist in the cache) {
Resolve the query as usual.
}

TEST = Find the longest existing domain name of QNAME
   from the covering NSEC RR;

if (*.TEST name entry exists in the cache) {
the resolver can generate positive response
or resolve the query as usual;
}
if covering NSEC RR of *.TEST at SIGNER zone exists
 in the cache {
the resolver can generate negative response;
}
// Lack of information, need to resolve the query as usual
} else
if (SIGNER zone is signed with NSEC3 and does not use Opt-Out) {
// NSEC3 mode

TEST = SIGNER;
while (TEST != QNAME) {
// if any error happens in this loop, break this loop
UPPER = TEST;
add a label from the QNAME to the start of TEST;
  // TEST = label.UPPER
if (TEST name entry exist in the cache) {
continue; // need to check rest of QNAME
}
if (covering NSEC3 of TEST exist in the cache) {
// (non-)terminal name TEST does not exist
if (*.UPPER name entry exist in the cache) {
// TEST does not exist and *.UPPER exist
the resolver can generate positive response;
} else
if (covering NSEC3 of *.UPPER exist in the cache) {
// TEST does not exist and *.UPPER does not exist
the resolver can generate negative response;
}
break; // Lack of information
} else
if (NSEC3 of TEST does not exist in the cache) {
break; // Lack of information
}
// TEST label exist, then need to check rest of QNAME
}
// Lack of information, need to resolve the query as usual
}
Resolve the query as usual
~~~
--
Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop