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

2015-10-26 Thread 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

2015-10-26 Thread 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

2015-10-26 Thread 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

2015-10-26 Thread 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

2015-10-26 Thread 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

2015-10-26 Thread 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

2015-10-26 Thread 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

2015-10-26 Thread 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

2015-10-26 Thread 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] Using NSEC authoritatively - cutting down on NXD requests...

2015-10-26 Thread Bob Harold 
On Sat, Oct 24, 2015 at 3:17 PM, Stephane Bortzmeyer 
wrote:

> On Thu, Oct 15, 2015 at 01:53:51PM -0400,
>  Warren Kumari  wrote
>  a message of 33 lines which said:
>
> > draft-wkumari-dnsop-cheese-shop-00 - "Believing NSEC records in the
> > DNS root" -
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-cheese-shop/
> >
> > Basically this is a simplification of Kazunori Fujiwara's
> > I-D.fujiwara-dnsop-nsec-aggressiveuse,
>
> For me, it has the same problem as fujiwara-dnsop-nsec-aggressiveuse:
> it is a DNSSEC-specific solution, while we already have a generic
> solution, described in section 3 of vixie-dnsext-resimprove (mentioned
> by Shumon Huque in
> )
>
> It looks to me like they address two separate cases:
vixie-dnsext-resimprove  addresses the case where a single name 'b.example'
and everything below it do not exist, found by a query for 'b.example'.
That's as much as we can determine without DNSSEC.  And it breaks if a DNS
server returns NXDOMAIN for ENT's.
fujiwara-dnsop-nsec-aggressiveuse addresses the case where 'a.example'
exists, but the range 'b.example' thru 'g.example' do not exist,
found by a single query for anything in the range.  But it only works with
DNSSEC signed zones.

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

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

2015-10-26 Thread 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

2015-10-26 Thread 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

2015-10-26 Thread 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

2015-10-26 Thread 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

2015-10-26 Thread 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