Subject: [DNSOP] [[email-masked]: I-D Action: draft-bortzmeyer-dnsop-nxdomain-cut-00.txt]

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Nov 2015 09:22:38 +0100

The stuff discussed in Yokohama yesterday.

Subject: I-D Action: draft-bortzmeyer-dnsop-nxdomain-cut-00.txt
From: [email-masked]
To: <[email-masked]>
Date: Fri, 06 Nov 2015 00:18:31 -0800
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : NXDOMAIN really means there is nothing underneath
        Author          : Stephane Bortzmeyer
	Filename        : draft-bortzmeyer-dnsop-nxdomain-cut-00.txt
	Pages           : 7
	Date            : 2015-11-06

Abstract:
   This document states clearly that when a DNS resolver receives a
   response with status code NXDOMAIN, it means that the name in the
   question section AND ALL THE NAMES UNDER IT do not exist.

   REMOVE BEFORE PUBLICATION: this document should be discussed in the
   IETF DNSOP (DNS Operations) group, through its mailing list.  The
   source of the document, as well as a list of open issues, is
   currently kept on at Github [1].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-nxdomain-cut/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-bortzmeyer-dnsop-nxdomain-cut-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 11 Nov 2015 01:15:37 +0000

Hi Stephane,

I read over this and have a few thoughts to share:

This updates RFC 2308 (Negative Caching of DNS Queries).  This would seem to be the
key text from 2308 to update:

   A negative answer that resulted from a name error (NXDOMAIN) should
   be cached such that it can be retrieved and returned in response to
   another query for the same <QNAME, QCLASS> that resulted in the
   cached negative response.

RFC 2308 defines four types of NXDOMAIN responses, all of which have a CNAME RR
in the answer section.  They differ in the contents of the authority and additional
sections.  I'm not sure why 2308 doesn't have a simple NXDOMAIN type (with no
answer RRs) but it seems likely the new draft will need to address CNAME and friends.

I think the WG needs to discuss and agree whether or not to make the NXDOMAIN cut
based on QNAME only, or on the SOA owner name.  If the goal is to thwart random
qname attacks, then it would be better to use the SOA (or hope for wide adoption
of qname minimization).

Implementing NXDOMAIN cut should also reduce the effectiveness of a Kaminsky attack
since the attack relies on the cache to forward numerous non-existent names.

I think its a little dangerous to say that an NXDOMAIN response SHOULD cause
a cache to delete already cached "positive" data.  Perhaps MAY is a better
choice there.  Or SHOULD when DNSSEC validated, but MAY without.

In Acknowledgements, s/Roland/Rodney

DW

> On Nov 6, 2015, at 12:22 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> From: <[email-masked]>
> Date: November 6, 2015 at 12:18:31 AM PST
> Reply-To: <[email-masked]>
> 
> 
> 
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Nov 2015 13:07:25 +1100

In message <[email-masked]>, "Wessels, Duane
> answer RRs) but it seems likely the new draft will need to address CNAME and 

Because the intent of the examples was to show the target of the CNAME was
the subject of the NXDOMAIN.  The surounding text makes it clear that CNAMES
are not required.  For some reason people like to take things out of context
when the context was written for a reason.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Nov 2015 13:31:37 +1100

In message <[email-masked]>, Mark Andrews writes:
> > I think the WG needs to discuss and agree whether or not to make the
> > NXDOMAIN cut based on QNAME only, or on the SOA owner name.  If the
> > goal is to thwart random qname attacks, then it would be better to
> > use the SOA (or hope for wide adoptionof qname minimization).

How can the NXDOMAIN be based on the SOA owner name?  It identifies the
administrative boundary not whether names exist or not.

NSEC / NSEC3 can thwart random qname as those define the containing
namespace.  <random>.existing.name.example can't be thwarted by
looking for parent NXDOMAINs as they don't exist.

Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 12 Nov 2015 09:15:14 +0100

On Wed, Nov 11, 2015 at 01:15:37AM +0000,
 Wessels, Duane <[email-masked]> wrote 
 a message of 107 lines which said:

> This updates RFC 2308 (Negative Caching of DNS Queries).

Good point, I'll add that. Also, I did not dare to add "Updates: RFC
1034". Should I?

> NXDOMAIN cut based on QNAME only, or on the SOA owner name.

This is discussed (shortly) in section 5 of the draft. Apparently, it
can be risky to rely on the SOA. More discussion welcome.

> If the goal is to thwart random qname attacks, then it would be
> better to use the SOA

Sure, if you don't have access to the resolver (if you do, you can
"poison" it with a request QNAME=apex-of-the-attack).

> Implementing NXDOMAIN cut should also reduce the effectiveness of a
> Kaminsky attack since the attack relies on the cache to forward
> numerous non-existent names.

Right.

> I think its a little dangerous to say that an NXDOMAIN response
> SHOULD cause a cache to delete already cached "positive" data.

Could you elaborate why is it dangerous? (See also the second
paragraph of section 7.)

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 12 Nov 2015 09:54:42 -0800

> Good point, I'll add that. Also, I did not dare to add "Updates: RFC

Yes.

> can be risky to rely on the SOA. More discussion welcome.

...and is needed.

> Could you elaborate why is it dangerous? (See also the second

If the NXDOMAIN response is not signed, it allows an attacker to block 
resolution of a name that was good, yes?

--Paul Hoffman

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 12 Nov 2015 18:13:04 +0000

> On Nov 12, 2015, at 12:15 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

That I don't know.  Someone with more experience should probably answer.

> can be risky to rely on the SOA. More discussion welcome.

As Mark pointed out, we can't use the SOA to make NXDOMAIN more aggressive.

For a name like foo.bar.example.com and an NXDOMAIN response from example.com
we can't assume that there would be a zone cut between foo and bar.  

> Could you elaborate why is it dangerous? (See also the second

I'm thinking of worst-case scenarios where, say, an entire TLD is purged
from the cache due to a spoofed response.  Or, could you imagine a spoofed
"NXDOMAIN ." response?

In addition to denying service for the purged domain, a large purge also
causes the resolver to do a lot of (possibly CPU intensive) work, and
could also affect the traffic levels between a recursive and authoritatives.

Perhaps a cache may want to limit the number of nodes/records that it deletes
per NXDOMAIN response.  Or perhaps it could be configured to not "bulk delete"
TLDs (or root).  

Perhaps a recursive might be designed to negatively cache an entire zone
(including TLD) but continue answering positively cached answers in the zone
until they expire normally.

DW

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Nov 2015 08:36:53 +1100

In message <[email-masked]>, "Wessels, Duane
> until they expire normally.

Or we can not do anything special w.r.t. TLDs.  DNSSEC prevents this attack.
TLD operators are all in a position to do the right thing and deploy DNSSEC.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 13 Nov 2015 20:33:57 +0100

On Wed, Nov 11, 2015 at 01:15:37AM +0000,
 Wessels, Duane <[email-masked]> wrote 
 a message of 107 lines which said:

> This updates RFC 2308 (Negative Caching of DNS Queries).  This would
> seem to be the key text from 2308 to update:

Yes, good catch, added to the online copy
<https://github.com/bortzmeyer/ietf-dnsop-nxdomain>

> Perhaps MAY is a better choice there.  Or SHOULD when DNSSEC
> validated, but MAY without.

Don't you think that the second paragraph of section 7 in -00 address
this concern? (My opinion is that this "attack" is nothing new and,
without DNSSEC, everything can be poisoned.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 13 Nov 2015 20:46:15 +0100

On Thu, Nov 12, 2015 at 09:54:42AM -0800,
 Paul Hoffman <[email-masked]> wrote 
 a message of 43 lines which said:

> If the NXDOMAIN response is not signed, it allows an attacker to
> block resolution of a name that was good, yes?

I do not see why it's new: without DNSSEC, a resolver can be poisoned,
"NXDOMAIN cut" or not. It is the case today.

[The only new thing is the possibility to deny existence of not just a
name but an entire subtree. Again, the solution is to use DNSSEC.]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 13 Nov 2015 20:50:15 +0100

On Thu, Nov 12, 2015 at 06:13:04PM +0000,
 Wessels, Duane <[email-masked]> wrote 
 a message of 57 lines which said:

> For a name like foo.bar.example.com and an NXDOMAIN response from
> example.com we can't assume that there would be a zone cut between
> foo and bar.

Could anyone explain in detail why is it so? [I don't understand why
the zone cut is important here: using the SOA does not depend on
whether there is a zone cut or not.]

Let's say I query foo.bar.example to example's name servers. I get:

...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64182
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1
...
;; QUESTION SECTION:
;foo.bar.example.		IN SOA
...

example.			5400 IN	SOA nsmaster.nic.example. hostmaster.nic.example. (
				2222956935 ; serial
				3600       ; refresh (1 hour)
                                ....

It can mean only one thing, that bar.example does not exist. How could
it be different?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 13 Nov 2015 20:52:05 +0100

On Thu, Nov 12, 2015 at 06:13:04PM +0000,
 Wessels, Duane <[email-masked]> wrote 
 a message of 57 lines which said:

> Perhaps a recursive might be designed to negatively cache an entire
> zone (including TLD) but continue answering positively cached
> answers in the zone until they expire normally.

Clever algorithm but I'm afraid it will make debugging more
difficult. Such a behaviour will be highly non-intuitive for the
user. (One of the motivations for NXDOMAIN cut is to make DNS behave
according to its data model, which is a tree.)

---

From: "John Levine" <[email-masked]>
Date: 13 Nov 2015 20:13:09 -0000

>It can mean only one thing, that bar.example does not exist. How could

My name server (running NSD) appears to disagree with you.  This is real data, feel
free to poke at it yourself.

$ dig @sdn.iecc.com bogus.www.examp1e.com a

; <<>> DiG 9.8.3-P1 <<>> @sdn.iecc.com bogus.www.examp1e.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9914
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;bogus.www.examp1e.com.		IN	A

;; AUTHORITY SECTION:
examp1e.com.		3600	IN	SOA	ns1.he.net. hostmaster.examp1e.com. 2015111219 10800 900 604800 7200

$ dig @sdn.iecc.com www.examp1e.com a

; <<>> DiG 9.8.3-P1 <<>> @sdn.iecc.com www.examp1e.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9303
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.examp1e.com.		IN	A

;; ANSWER SECTION:
www.examp1e.com.	3600	IN	CNAME	ghs.googlehosted.com.

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 13 Nov 2015 21:03:52 +0000

> On Nov 13, 2015, at 11:50 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

If 'bar.example IN A 127.0.0.1' existed in the example zone, what would you expect
for the response to your query above?

DW

---

From: Tony Finch <[email-masked]>
Date: Wed, 18 Nov 2015 15:31:13 +0000

> we can't assume that there would be a zone cut between foo and bar.

If QNAME = foo.bar.example.com and NXDOMAIN SOA owner = example.com, you
know that foo.bar.example.com and bar.example.com are not delegation
points. You know that foo.bar.example.com does not exist. You do not know
whether bar.example.com exists. (You can find that out with another query
if you want to raise the NXDOMAIN bar.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger, Fisher: Cyclonic, mainly southwest, 5
to 7, occasionally gale 8 or severe gale 9, except in Cromarty. Moderate or
rough, occasionally very rough except in Cromarty, becoming high for a time
later in Dogger. Rain or showers. Moderate or good, occasionally poor except
in Cromarty.