Subject: [DNSOP] Future of "Using DNAME in the DNS root zone for sinking of special-use TLDs" ?

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 14 Oct 2016 15:31:35 +0200

draft-bortzmeyer-dname-root
<https://datatracker.ietf.org/doc/draft-bortzmeyer-dname-root/?include_text=1>,
which proposes to "sink" special-use TLD (may be you've heard of RFC
6761 "special use domain names"?) using AS 112, will expire soon. From
the discussions, the two biggest issues were the "governance"
difficulties (adding DNAME records in the root...) and the privacy
issues (sending .local requests to random AS 112 operators).

It seems there is not enough interest for this work, so I was thinking
of just documenting the current state of the discussion, in case other
people rediscover the problem. May be an individual RFC?

Any ideas or opinions? I'll be in Seoul for those who want to talk
AFK.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 14 Oct 2016 10:04:21 -0400 (EDT)

> people rediscover the problem. May be an individual RFC?

This is tricky. We want DNS resolvers to not send these onto the
internet. But by adding delegations in the root to AS112, aren't
we making it more likely that the queries leak further onto the net?

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 14 Oct 2016 16:09:05 +0200

On Fri, Oct 14, 2016 at 10:04:21AM -0400,
 Paul Wouters <[email-masked]> wrote 
 a message of 19 lines which said:

> But by adding delegations in the root to AS112, aren't we making it
> more likely that the queries leak further onto the net?

That's precisely the point described in section 6, second paragraph.

---

From: "John Levine" <[email-masked]>
Date: 14 Oct 2016 14:56:41 -0000

I would rather we abandon this draft.  I don't think the benefit is
worth the cost.

It is not my impression that the load on the roots from special-use
leakage is a significant fraction of the overall flood of garbage they
get.  Whether or not it is, we have at least three things going on
that would decrease all root garbage queries, not just leakage:

RFC 7706 (local root mirror)
	
draft-ietf-dnsop-nsec-aggressiveuse-04 (Aggressive use of NSEC/NSEC3)
	
draft-ietf-dnsop-nxdomain-cut-05 (NXDOMAIN really means there is nothing underneath)

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Fri, 14 Oct 2016 11:48:37 -0400 (EDT)

On Fri, 14 Oct 2016, Stephane Bortzmeyer wrote:

>     "Using DNAME in the DNS root zone for sinking  of special-use TLDs" ?
> 

The difference is between "doing the draft and reducing the problem
caused" versus "this problem is big enough to not do the draft".

I do not know yet where I stand on this. I do feel that since we are
talking about "bad old DNS software" that wouldn't already be suppressing
special use names, it is most likely that this old software also does
not support DNAMEs.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Sat, 15 Oct 2016 06:51:39 +1100

In message <[email-masked]>, Paul Wouters w
> special use names, it is most likely that this old software also does

A alternative is to insecurely delegate .local to the root servers
themselves and to request that recursive servers maintain their own
empty .local.  The roots will then get just DS queries for .local
when there is a validating recursive client behind the recursive
server that is leaking <foo>.local queries into the DNS.

The same solution also works for .onion.
 
Having a local copy of the root zone still works with this.

This stops leaks of <foo>.local to the root servers which qname
minimisation doesn't.  The extent of the leak is that you know
.local is in use when you have a validating recursive client.

Mark

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Bob Harold <[email-masked]>
Date: Tue, 18 Oct 2016 11:15:32 -0400

> .local is in use when you have a validating recursive client.
I would think that the best approach might be:
- insecure delegation to 127.x.x.x, so that queries do not leak past the
host of the local resolver.  This is the best we can do for the CPE
equipment and other resolvers that will not be updated until they are
replaced.
- add .local to resolvers that do update, so they don't bother trying to
query 127.x.x.x
- local root is still an option, and reduces queries to the root even more.

This does not cause any additional load on the AS112 servers.

-- 
Bob Harold

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 18 Oct 2016 17:20:18 +0200

On Tue, Oct 18, 2016 at 11:15:32AM -0400,
 Bob Harold <[email-masked]> wrote 

> This does not cause any additional load on the AS112 servers.

Sparing the AS 112 servers is a non-goal. Their operators never said
they were overloaded.

---

From: "John Levine" <[email-masked]>
Date: 18 Oct 2016 17:53:40 -0000

>- local root is still an option, and reduces queries to the root even more.

If we're going to ask people to change their software, how about
asking them to implement aggressive NSEC or NXDOMAIN-means-NXDOMAIN in
their caches?  Those deal with .local and .onion leaks at the same time
they do other useful stuff.

I still see this proposal as a distraction from other more general proposals.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Tue, 18 Oct 2016 16:53:31 -0400

> we making it more likely that the queries leak further onto the net?

So, back in ~Feb 2014 we had very similar discussion about ALT-TLD,
AS112 delegations and DNAME.

Initially the ALT-TLD document
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/) had .alt
being delegated to "new style" AS112 nameservers, but Joe Abley
pointed out that this would be a lame delegation.
We also discussed using DNAME, but the general view seemed to be that
getting this deployed in the root would be an uphill battle; much of
this discussion was happening during the new gTLDs process , "the
variants problem", bundling, etc.
There is also a big difference between "reserving" something and
actually getting it delegated, even for a "null" answer.

The consensus seemed the be that adding things like .alt to the
RFC6303 ( "Locally Served DNS Zones") registry was sufficient. I think
that the consensus was correct -- RFC6303 zones come baked into most
authoritative resolver packages, and the time to upgrade the majority
of "served users" isn't that long (especially if you get this into the
registry shortly before a large CVE :-P). Anything which isn't caught
by Locally Served Zones simply flows upwards till it hits the root --
which is already handling this garbage anyway...

So, back to Stephane's original question  -- I think that documenting
the current state is useful, or we will have this discussion all over
again in a few months....

Below is the .ALT IANA considerations, and extracts of the 6761 "questions":

4.  IANA Considerations

   The IANA is requested to add the ALT string to the "Special-Use
   Domain Name" registry ([RFC6761], and reference this document.  In
   addition, the "Locally Served DNS Zones" ([RFC6303]) registry should
   be updated to reference this document.

4.1.  Domain Name Reservation Considerations

   This section is to satisfy the requirement in Section 5 of RFC6761.
[SNIP]

4.  Caching DNS servers SHOULD recognize these names as special and
       SHOULD NOT, by default, attempt to look up NS records for them,
       or otherwise query authoritative DNS servers in an attempt to
       resolve these names.  Instead, caching DNS servers SHOULD
       generate immediate negative responses for all such queries.

   5.  Authoritative DNS servers SHOULD recognize these names as special
       and SHOULD, by default, generate immediate negative responses for
       all such queries, unless explicitly configured by the
       administrator to give positive answers for private-address
       reverse-mapping names.

   6.  DNS server operators SHOULD be aware that queries for names
       ending in .alt are not DNS names, and were leaked into the DNS
       context (for example, by a missing browser plugin).  This
       information may be useful for support or debugging purposes.

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Oct 2016 08:11:45 +1100

> they do other useful stuff.

No.  They slow the leaks.  They do not STOP the leaks.  They depend on
leaks to work.

---

From: "John R Levine" <[email-masked]>
Date: 18 Oct 2016 17:44:29 -0400

> No.  They slow the leaks.  They do not STOP the leaks.  They depend on

With a 24 hour TTL on the root zone, it ain't going to leak very much.

Or if you get to hack on your cache, you can just do what unbound already 
did and put in dummy stub zones, no new code needed.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Oct 2016 09:07:16 +1100

> With a 24 hour TTL on the root zone, it ain't going to leak very much.

The practical TTL is 3 hours.
 
> did and put in dummy stub zones, no new code needed.

But dummy stub zones (which is what is being I'm requesting) require
changes in the root zone to add a insecure delegation to not break
other things.  That requires IANA to be instructed to do so.

You may not care that validating stub resolvers that ask for
example.local get back answers that can be validated as NXDOMAIN
without leaking queries to the root but I do.  Just adding the zone
locally without having the insecure delegation results in just that
condition.

For all the zones in RFC 6303 that is what we instructed IANA to
do.  I had to open a few trouble ticket with IANA to get them all
installed but there was the documentation there to back up the
trouble tickets.  We then had to do this for 100.64/10 with RFC
7793 which was required co-ordinatation between IANA and ARIN.

Mark

---

From: "John R Levine" <[email-masked]>
Date: 18 Oct 2016 18:38:47 -0400

> The practical TTL is 3 hours.

How come?  This is a real question, unbound appears to believe the 24 hour 
TTL.

> other things.  That requires IANA to be instructed to do so.

Hm, I see your point.

R's,
John

---

From: George Michaelson <[email-masked]>
Date: Wed, 19 Oct 2016 08:43:29 +1000

I would encourage you to write up some terminal state, either for
publication as an informational or in some other document series.
People find stuff, and if you link to it in the mail archives, it will
be a useful reminder of where we got to on the conversation.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Oct 2016 09:54:12 +1100

> How come?  This is a real question, unbound appears to believe the 24 hour 

Because that is what RFC 2308 says to do with negative answers.

---

From: George Michaelson <[email-masked]>
Date: Wed, 19 Oct 2016 09:04:21 +1000

Mark, thats a bit of an unsatisfactory answer. the RFC (which you
authored) says:

"...As with caching positive responses it is sensible for a resolver to
   limit for how long it will cache a negative response as the protocol
   supports caching for up to 68 years.  Such a limit should not be
   greater than that applied to positive answers and preferably be
   tunable.  Values of one to three hours have been found to work well
   and would make sensible a default.  Values exceeding one day have
   been found to be problematic. ..."

So your response is an appeal to authority, which then cites nothing
to state why 1-3 hours is ok, and >24 is a problem.

The language is useful when it says "such a limit should not be
greater than that applied to positive answers" But it doesn't actually
tell us *why* Three Hours is a magic number.

The RFC is from 1998. The DNS has changed a bit since then.

Can you explain in a modern, 2016 DNS, why three hours is the "best"
time to chose, for this specific purpose?

(I can believe btw, its a good choice)

-G

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Oct 2016 10:15:45 +1100

> to state why 1-3 hours is ok, and >24 is a problem.

I didn't say 24 hours is a problem.  I stated the practical limit
is / will be 3 hours as that is what is the default negative cache
limit is.

> time to chose, for this specific purpose?

Because it a trade off in how long people are prepared to wait for
new names to become visible.  People don't like waiting a day.  3
hours is a stretch.

---

From: Aleksi Suhonen <[email-masked]>
Date: Tue, 18 Oct 2016 15:00:28 +0300

> That's precisely the point described in section 6, second paragraph.

For .local, I can see the point of sinking it as locally as possible.
But it does not make sense for all DNS software and all resolver admins
to try to keep track of all the zones that need to be sinked.

I don't remember if Teredo address space (0.0.0.0.1.0.0.2.ip6.arpa.) was
in the proposal, but it's a good example anyhow, isn't it?

-- 
	+358 44 9756548 / http://www.trex.fi/
	Aleksi Suhonen / TREX Regional Exchanges Oy

	You say "potato", I say "closest-exit."

---

From: "John Levine" <[email-masked]>
Date: 19 Oct 2016 14:09:54 -0000

>locally without having the insecure delegation results in just that

It just occurred to me that we seem to disagree about what problem
we're solving here.

If we see a DNS query for .local or .onion, an application is trying
to use mDNS or Tor on a machine that doesn't implement them.  On
machines that do implement mDNS and Tor, neither does DNSSEC
signatures, so there is no reason to provide answers that the
application is not looking for.

So a cache stub that provides unsigned answers to .local and .onion
queries is just fine.  If the client treats that as SERVFAIL or
whatever it does with unverified answers, that's fine too.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 19 Oct 2016 14:13:48 -0000

>difficulties (adding DNAME records in the root...)

Nobody's mentioned the governaance issues, but speaking as someone who
spends too much time hanging around ICANN, that will be a huge can of
worms.  

If we tell them that DNAMEs are OK for one purpose, I can guarantee
that the domain crowd will demand DNAMEs for other purposes, in
particular to alias TLDs.  There's already a ccTLD that consists of
nothing but a DNAME, and now that the IETF has blessed top level
DNAMEs, they must be fine for ICANN TLDs, too.

Please, let us not go anywhere near there and abandon this unwise
proposal.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Oct 2016 06:10:47 +1100

> whatever it does with unverified answers, that's fine too.

SERVFAIL is a temporary error.
NXDOMAIN is a permanent error which is cachable.

SERVFAIL is not "fine".

---

From: "John R Levine" <[email-masked]>
Date: 19 Oct 2016 18:28:10 -0400

> NXDOMAIN is a permanent error which is cachable.

Hmmn.  Keeping in mind that these responses are sent by the cache, could 
you explain what "cacheable" means in this context?

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Oct 2016 09:33:52 +1100

In message <[email-masked]>, "John R Levine" wri
> you explain what "cacheable" means in this context?

Applications can, and some do, cache responses.

---

From: "John R Levine" <[email-masked]>
Date: 19 Oct 2016 18:43:28 -0400

> Applications can, and some do, cache responses.

No doubt, but I have a hard time believing that a few extra queries to the 
local cache from apps that a) maintain their own private DNS caches, b) 
want to use special use names, and c) are misconfigured so the queries 
aren't caught by the software that's supposed to handle them is a big 
enough deal to be worth inventing new rules for what goes in the root 
zone.

Like I said in another message, for political reasons DNAMEs in the root 
will be a big can of worms.

R's,
John