Subject: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.

From: Edward Lewis <[email-masked]>
Date: Mon, 29 Feb 2016 12:51:16 +0000

On 2/25/16, 17:58, "DNSOP on behalf of Warren Kumari"
<[email-masked] on behalf of [email-masked]> wrote:

>We have recently updated "Believing NSEC records in the DNS root"
>(https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01).

My objection to this document is based on the draft's proposal to specify
a change to the protocol based on the data being carried in one particular
deployment of the protocol.

(The temptation to define the special protocol behaviors for a special use
case came up when we'd considered altering the DNSSEC signing definition
for dotCOM.  At the time, a 750K delegation-large zone was larger than a
100MHz PC could handle.  We didn't, eventually an "opt-out" proposal was
adopted that would work with any zone.)

The DNS protocol is used in more than just the global public Internet.
I.e., there are other inter-network environments in production use, run
independently of the internet.  The cross-over between the such
environments and the internet is the use of the same software.

If the DNS is built to assume that the root zone is DNSSEC signed with
NSEC records and this is then "burned into software" the other
inter-networks will be given the choice of having to turn on DNSSEC and
NSEC for their root zone or developing other software.  (Or...other
inconvenient mitigations.)

This has nothing to do with whether NXDOMAIN responses can or should be
assembled by a DNS intermediary.  That's an entirely different question.

---

From: Shane Kerr <[email-masked]>
Date: Mon, 29 Feb 2016 15:12:20 +0100

Ed,

At 2016-02-29 12:51:16 +0000

> deployment of the protocol.

Interesting concern, although I don't see how it can be otherwise. We
don't know what the properties of future protocols will be, so I don't
know how we can specify the behavior of resolvers using such protocols
would be.

> inconvenient mitigations.)

Can't a couple sentences address this concern?

"If the root zone is not DNSSEC signed with NSEC records then the
Cheese Shop is closed and this document does not apply. Resolvers MUST
continue to work in such an environment."

Cheers,

--
Shane

---

From: Edward Lewis <[email-masked]>
Date: Mon, 29 Feb 2016 14:34:39 +0000

On 2/29/16, 9:12, "DNSOP on behalf of Shane Kerr" <[email-masked]

>know how we can specify the behavior of resolvers using such protocols

I don't think I was clear - this is only about the DNS protocol.  This
document proposes that the DNS protocol behave differently depending on
the data being carried (QNAME) in it's own messages.

(I.e., the rule could be stated: if the QNAME is a single label, then if
the QTYPE is NSEC the NSEC can be used to assemble other NXDOMAIN
responses.  This assumes the root zone owns only single label names [and
is DNSSEC signed with NSEC], which might not be true for all root zones.)

This isn't about processing different values differently, this is about
changing the behavior of the protocol based on environmental factors.

---

From: Shane Kerr <[email-masked]>
Date: Mon, 29 Feb 2016 16:03:57 +0100

Ed,

At 2016-02-29 14:34:39 +0000
> the data being carried (QNAME) in it's own messages.

[...]

> changing the behavior of the protocol based on environmental factors.

Ah. So you don't like identifying magic zones (other than in-addr.arpa,
ip6.arpa, .example, .local, ...). Fair enough.

But AIUI, the proposal is an observation that Fujiwara's
NXDOMAIN-from-NSEC proposal can be implemented safely today for the root
zone, so we may as well go ahead and do that while considering wider
usage.

Nothing about it prevents Fujiwara's technique from moving on, and
eventually being more widely deployed. If changes are needed in the
root or resolver behavior later... well, they would have been needed
anyway, right?

I don't expect to change your mind but hopefully I understand your
position and can thus disagree with your actual stance. ;)

Cheers,
--
Shane

---

From: Edward Lewis <[email-masked]>
Date: Mon, 29 Feb 2016 15:37:49 +0000

>ip6.arpa, .example, .local, ...). Fair enough.

What's magic about any of them?  In the protocol they all are processed
the same.

There is no "reverse DNS" protocol, what's confusing is that there is a
convention for storing addresses in the DNS.  (E.g.,
myhost.*.foo.bar.in-addr.arpa. is an acceptable domain name.  Applications
never seriously look it up.)

If asked on port 53, name servers will return NXDOMAIN for names under
"example." and "local." if those names lack NS sets in the root zone.

All magic treatment of those names occur in other software layers.

>position and can thus disagree with your actual stance. ;)

I have no idea why assembling a NXDOMAIN response from cached DNSSEC
negative answers is any different if the QNAME is managed by the root zone
or is managed by a zone delegated away from the root.  The only thing
unique to the root zone is that there is no authority that can publish the
root zone's DS record, which has nothing to do with the question at hand.

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 29 Feb 2016 07:47:41 -0800

> continue to work in such an environment."

Shane's proposal would be a good addition and should alleviate Ed's 
concern. That is, the proposal is "in this zone at this time, X makes Y 
possible". Adding "If you implement this proposal, you have to check 
whether X still is valid and, if not, go back to what you were doing 
before" is a good idea.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Feb 2016 16:03:00 +0000

> zone, so we may as well go ahead and do that while considering wider

Yup. I believe we should still pursue Fujiwara's document, but that is
likely to take a significant time, and there are hurdles to overcome. This
document limits things to a subset where we know things work correctly (and
seem OK within 4035) - once we have demonstrated that things work OK here,
it paves the way for more aggressive NSEC.

> root or resolver behavior later... well, they would have been needed
Yup. We view this as complementing, not competing with aggressive-nsec.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Feb 2016 16:13:29 +0000

> continue to work in such an environment."

I *think* that the document / proposal implicitly handles this case already.

If the root (of whatever tree / name resolution system you have) is not
DNSSEC signed, you do not get back valid NSEC records. If you do not get
back valid NSEC records, there is no work to do.
I guess I could sprinkle "DNS" all over:
"The scope of this document is limited to the special case of recursive
DNSSEC validating resolvers querying the root zone.", e.g
"The scope of this document is limited to the special case of recursive
DNSSEC validating resolvers querying the IANA administered DNS root zone."

I'm (as always) happy to accept text - I've tossed Shane's in to make it
clearer (?) - editor copy:
https://github.com/wkumari/draft-wkumari-dnsop-cheese-shop

I also have some comments from Jinmei (thanks!) to incorporate, hopefully
later this afternoon.

W

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 29 Feb 2016 08:26:44 -0800

> I *think* that the document / proposal implicitly handles this case 

Please make the "if the root zone isn't signed with NSEC then fall back" 
explicit. Implicit to you is confusing to others.

> back valid NSEC records, there is no work to do.

It's more than that. It is "and you have to go back to doing 4035".

> DNSSEC validating resolvers querying the IANA administered DNS root 

Please no. (Ed might disagree with me on this.) I think every document 
that talks about the DNS in the IETF is about the IANA-administered DNS 
except where loudly noted.

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Mon, 29 Feb 2016 16:54:49 +0000

>except where loudly noted.

I very much disagree coming from operating DNS on networks other than the
global public Internet.

This isn't about alternate versions of root zones, but about separating
the operations ecosystem from the protocol engineering architecture.

>continue to work in such an environment."

I have problems with this.  It's not that the proposal would be okay if
wrapped in 15 layers of "this only works for this small problem, don't
extrapolate".  Setting a precedent for special handling of one zone would
be a bad example for future expeditions.  Some might take this as meaning
that assembling an NXDOMAIN from DNSSEC negative answers can only ever be
done for the root zone.

The question I have is "why is the root zone special?"  Why is it
supposedly a simple use case?  The draft document does not establish why
the root is special.

Quoting section 2:

# The scope of this document is limited to the special case of
# recursive DNSSEC validating resolvers querying the root zone.  This
# is because the root zone has some well known properties which make it
# a special case - we know it is DNSSEC signed, and uses NSEC, the
# majority of the queries are "junk" queries, the rate of change is
# relatively slow, and there are no odd corner cases such as wildcards.

For any zone I can discover any of these things.  We can tell if the data
set is supposed to be signed, from that the zone, the presence of
wildcards, and so on.  A cache could, in a few retrievals, obtain all of
the relevant records to determine a name error.

in Section 3:

# For the limited use case of this document (the DNS root) we believe
# that this is an acceptable trade off - the (current) TTL of the
# "negative cache" (in the SOA) is the same as the NSEC TTL (1 day).

Again - what's significant?  The values - for any zone easily
discoverable.  The timing?  The TTL setting here is one hand clapping,
what's the rate of queries toward the zone?  It's relative.

My discomfort regarding fracturing the protocol is that the recommendation
is to alter a core algorithm of DNS resolvers (not tools around the DNS)
based on the qname believed to be managed from the root zone.  Will the
"only-root" remain, will this open the barn for other protocol hacks to be
special for a particular zone?  Those are future considerations that drive
me to keep operation optimizations out of the core algorithm.  More
pragmatically, what happens to code drops that restrict this to just the
root once it is opened up to the rest of the tree?  More planned
obsolescence?

I don't see why aggressive use of DNSSEC negative answers is any more or
less risky at other levels of the hierarchy.  I don't see why the root is
special.  I'm not convinced by the draft that it is.

And I don't see this as much of an interoperability issue.  We know that
not all resolvers are written to be equal - there are domain names that
appear in the upper rankings of URL activity that cannot be resolved via
conventional means - yet people get to the sites.  Resolvers already do
funky things - and as someone who has been on the authoritative side for a
long time, there's no standard behavior across resolvers.  (Server
selection, anyone?)  So, why worry about this in an IETF document?  Why
don't implementers just try it and then compare "performance" (in quotes
because I leave it up to the viewer to define the measurement)?

What about an "experimental" describing trying this, with metrics for
success, to be follow up in a year or so with numbers on the trade off?
The mere documentation of how might be enough for some developers to
include this in their code.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Feb 2016 17:27:22 +0000

> It's more than that. It is "and you have to go back to doing 4035".

"If the root zone is no longer DNSSEC signed with NSEC records then this
document no longer applies. Resolvers MUST continue to work in such an
environment."

Not sure where I can add the "do 4035" wording - if the root is no longer
DNSSEC signed, 4035 doesn't apply at all. I think that the above text
handles things, but I may be missing something...

> except where loudly noted.

I added "global DNS root zone." initially, but I've just removed global (in
the editor copy / github version - I'm try to incorporate people's comments
as I get them, so that folk can follow along at home and make sure that I'm
accurately capturing what they are requesting. Current version is
(hopefully always!) at:
https://github.com/wkumari/draft-wkumari-dnsop-cheese-shop/ )

---

From: 神明達哉 <[email-masked]>
Date: Mon, 29 Feb 2016 10:30:55 -0800

At Mon, 29 Feb 2016 16:54:49 +0000,

> I very much disagree coming from operating DNS on networks other than the

I'm with Ed here.  In my understanding RFCs of DNS related protocols
generally don't make such explicit notes but are still generally used
in DNS operations in closed intranet.  And I think that's more
sensible default interpretation.  So, if a document relies on specific
characteristics of the IANA-administered DNS like this draft, it's
better to note that explicitly (on the other hand, I don't think we
should consider draft-fujiwara-dnsop-nsec-aggressiveuse to be limited
to the IANA-administered DNS simply because it doesn't loudly note it
can be used more generally).

--
JINMEI, Tatuya

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Mar 2016 08:24:05 +1100

In message <CAJE_bqeuPrvnyS5NXBqMUjxOES-SrQftXN=[email-masked]>
> can be used more generally).

You could apply the technique to any signed zone where you are not
worried about not having instant visibility after adding a new name
to the zone.  It is the later that is a property of the root zone
which is missing in many others.  People want to be able to create
a delegation in .com and have it available for use within a couple
of minutes.

That said .COM is OPTOUT (NSEC3 is fine) so you can't do ANC there
anyway but the principle still applies to other zones.

I'm not worried about this one at all and no one else should be
either if you think about it.  This is a opportunistic optimisation.

If you have the NSEC records then you can synthesis the negative
response.  If you don't, which will happen with a fresh cache, then
you perform a lookup, validate the response, etc.  The worst that
will happen is that you waste time looking for NSEC records in the
cache and don't find them.

Mark

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

---

From: 神明達哉 <[email-masked]>
Date: Mon, 29 Feb 2016 13:41:00 -0800

At Tue, 01 Mar 2016 08:24:05 +1100,

> a delegation in .com and have it available for use within a couple

In case you are replying to my message: I guess we're talking about
different things...I thought that the specific point in this
sub-thread is that *given the author's intent is to focus on the root
zone*, whether this should be explicitly noted or whether we should
rather omit such a note as the obvious.  You seem to talk about
whether we should focus on the root in the first place or whether
nsec-aggressiveuse is risky or not in general.  That's a totally
different discussion, on which I already stated I have no particular
opinion.

--
JINMEI, Tatuya

---

From: "John Levine" <[email-masked]>
Date: 29 Feb 2016 22:53:56 -0000

>to the zone.

I don't understand this.  If I ask for foo.example and get NXDOMAIN,
and 10 ms later you add a record at foo.example, my negative answer is
cached for your SOA TTL is.  Using NSEC to synthesize responses
doesn't fundamentally change the situation, it just increases the set
of names that negative cache entries will cover and maybe changes the
time if the NSEC and SOA TTLs are different.  Unless all of your TTLs
are zero, there's no such thing as a new name that's instantly visible
to every client.

If someone's going to argue that you carefully watch your query stream
and only add new names for which there hasn't been a NXDOMAIN query
within the appropriate interval from any of your DNS servers, I'll
believe it when I see it.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Mar 2016 10:36:06 +1100

> are zero, there's no such thing as a new name that's instantly visible

For 99.999999999% of names you don't look them up unless you have
a priori knowledge that the name exist.  This means you don't have
many NXDOMAIN records in a cache sans DoS attacks, prefixes to known
names (e.g. TLSA for service) and Internet reachability tests using
the DNS etc.  Even with search lists you are looking for a known
name with a set of suffixes.  You are not looking for unknown names.

ANC changes that.  It effectively adds lots of NXDOMAIN records for
stuff you don't have a priori knowledge of, for unknown names.

Yes, ANC breaks using the DNS for Internet reachability testing.

Named has code to return zero TTLs on negative answers to SOA queries
to avoid polluting caches with NXDOMAIN results when searching for
zone cuts.  Nsupdate and similar tools need to be able to find the
containing zone of names that are about to be added and cached
NXDOMAIN responses are a right-royal-pain-in-the-butt if you want
to lookup the name just after you have added it to the DNS.

SOA and NS are the only two types that should exist in every zone
and looking these up works even when the authoritative servers don't
support negative caching.  For UPDATE you need to do both SOA and
NS lookups to work out where to send the UPDATE message to.  You
start with the name to be added/removed and query for a SOA record
at that name, you keep stripping the left hand label until you get
a positive answer or a negative answer with a SOA record.  You then
make a NS query for the owner of the SOA record.  For completeness
you could also start with NS lookups and then perform a SOA lookup
with optimisations if you get a cachable negative response.

Mark

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 1 Mar 2016 00:20:05 +0000

> On Feb 29, 2016, at 3:36 PM, Mark Andrews <[email-masked]> wrote:
> 
> 

[CITATION NEEDED] Please?

Actual data seems to tell a different story:

$ sudo tcpdump -n -i eth0 -c 10 dst host a.root-servers.net and src host 74.125.74.4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:14:53.448321 IP 74.125.74.4.36867 > 198.41.0.4.domain: 53200 [1au] A? u2t11ngt0b-7j.unarubxvgjclkbxmgmfim.tv.adelina.local. (81)
00:14:53.609935 IP 74.125.74.4.60074 > 198.41.0.4.domain: 47352 [1au] A? cid:4104657c5b1627c4161ccc7fcb012308.box. (69)
00:14:53.767055 IP 74.125.74.4.64713 > 198.41.0.4.domain: 30524 [1au] AAAA? eait3235vr0vk.clients3.google.com.gp3.s86.loc. (74)
00:14:53.953686 IP 74.125.74.4.49501 > 198.41.0.4.domain: 8537 [1au] SRV? _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.teh-system.local. (97)
00:14:54.095375 IP 74.125.74.4.49952 > 198.41.0.4.domain: 35033 [1au] AAAA? g2xkqe1z1kj1h.ups.virool.com.gbiad. (63)
00:14:54.096339 IP 74.125.74.4.59901 > 198.41.0.4.domain: 6762 [1au] A? HH.gkab.loc. (40)
00:14:54.143732 IP 74.125.74.4.49996 > 198.41.0.4.domain: 42468 A? q2jv2af4g-jzh.dns1.be.weather.com. (51)
00:14:54.231436 IP 74.125.74.4.42995 > 198.41.0.4.domain: 52187 [1au] AAAA? oobca2949e5mc.bd.unba.lan. (54)
00:14:54.238082 IP 74.125.74.4.54627 > 198.41.0.4.domain: 47410 A? byz-372osga4d.dns3.be.weather.com. (51)
00:14:54.321907 IP 74.125.74.4.64277 > 198.41.0.4.domain: 62335 [1au] SRV? neesb94pfizrq._ldap._tcp.us179._sites.dc._msdcs.gvsucentr.corp. (91)

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Mar 2016 12:11:01 +1100

In message <[email-masked]>, "Wessels, Duane" writes:
> 00:14:53.448321 IP 74.125.74.4.36867 > 198.41.0.4.domain: 53200 [1au] A?
> u2t11ngt0b-7j.unarubxvgjclkbxmgmfim.tv.adelina.local. (81)
> 00:14:53.609935 IP 74.125.74.4.60074 > 198.41.0.4.domain: 47352 [1au] A?
> cid:4104657c5b1627c4161ccc7fcb012308.box. (69)
> 00:14:53.767055 IP 74.125.74.4.64713 > 198.41.0.4.domain: 30524 [1au]
> AAAA? eait3235vr0vk.clients3.google.com.gp3.s86.loc. (74)
> 00:14:53.953686 IP 74.125.74.4.49501 > 198.41.0.4.domain: 8537 [1au] SRV?
> _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.teh-system.local. (97)
> 00:14:54.095375 IP 74.125.74.4.49952 > 198.41.0.4.domain: 35033 [1au]
> AAAA? g2xkqe1z1kj1h.ups.virool.com.gbiad. (63)
> 00:14:54.321907 IP 74.125.74.4.64277 > 198.41.0.4.domain: 62335 [1au]
> SRV? neesb94pfizrq._ldap._tcp.us179._sites.dc._msdcs.gvsucentr.corp. (91)

I see nothing there that disproves my statement.  There are lots
of leaked names but nothing that says that the lookup wasn't based
on a known name.

Mark