Subject: [DNSOP] Special-use TLDs in resolvers

From: Vladimír Čunát <[email-masked]>
Date: Fri, 16 Aug 2019 11:30:06 +0200

Hello,

I've been wondering what's best to do around these TLDs: invalid, local,
onion, test.  The RFCs say that resolvers SHOULD recognize them as
special and answer NXDOMAIN without any interaction with nameservers (by
default).  What do you think about NOT following this "advice", subject
to some conditions that I explain below?

1. QNAME minimization (in the root at least), so that if e.g.
foo.bar.test. query arrives and the cache is empty, the resolver only
asks the root for test. and the rest does not leak.
2. RFC 8020 -style caching (in the root at least), so that we keep the
goal of reducing load on root servers.  Note that this is subsumed by
aggressive caching (RFC 8198), which should work for the root zone in
some commonly used resolvers for about a year already (I believe:
Unbound, BIND, Knot Resolver).

This pair of conditions seem quite reasonable defaults regardless of
special TLDs, in which case I'd argue it's better not to special-case
these four TLDs.  One advantage is that this allows supplying the
denials with DNSSEC proofs, which e.g. avoids problems in case the
client is missing some of these special cases and wants to validate. 
Well, that's arguably a relatively unlikely combination, but my
motivation is mainly that it feels nicer to remove them :-)

Reference RFCs for these TLDs, respectively: 6761.6.4.4, 6762.22.1.4,
6762.2.4, 6761.6.2.4

--Vladimir

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 09:10:02 -0400

If you look up “onion”, you have revealed that the user is trying to use tOR, even if you haven’t revealed where they are going. 

What’s the motivation behind this proposal?

Sent from my iPhone

> On Aug 16, 2019, at 05:30, Vladimír Čunát <[email-masked]> wrote:
> 
> 
> Hello,
> 
> I've been wondering what's best to do around these TLDs: invalid, local, onion, test.  The RFCs say that resolvers SHOULD recognize them as special and answer NXDOMAIN without any interaction with nameservers (by default).  What do you think about NOT following this "advice", subject to some conditions that I explain below?
> 
> 1. QNAME minimization (in the root at least), so that if e.g. foo.bar.test. query arrives and the cache is empty, the resolver only asks the root for test. and the rest does not leak.
> 2. RFC 8020 -style caching (in the root at least), so that we keep the goal of reducing load on root servers.  Note that this is subsumed by aggressive caching (RFC 8198), which should work for the root zone in some commonly used resolvers for about a year already (I believe: Unbound, BIND, Knot Resolver).
> 
> This pair of conditions seem quite reasonable defaults regardless of special TLDs, in which case I'd argue it's better not to special-case these four TLDs.  One advantage is that this allows supplying the denials with DNSSEC proofs, which e.g. avoids problems in case the client is missing some of these special cases and wants to validate.  Well, that's arguably a relatively unlikely combination, but my motivation is mainly that it feels nicer to remove them :-)
> 
> Reference RFCs for these TLDs, respectively: 6761.6.4.4, 6762.22.1.4, 6762.2.4, 6761.6.2.4
> 
> --Vladimir
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 16 Aug 2019 15:26:13 +0200

On 8/16/19 3:10 PM, Ted Lemon wrote:
> If you look up “onion”, you have revealed that the user is trying to
> use tOR, even if you haven’t revealed where they are going.

Well, in this particular case the tOR client would probably better not
send onion queries to DNS resolver, but generally there would be a leak,
though the TTL is a whole day.  At least unless combined with one of the
"local root" schemes (which are so far not commonly deployed, I think).

> What’s the motivation behind this proposal?

As I wrote, supplying the answer with a DNSSEC proof seems better to
me.  And it makes my camel a tiny bit happier, I guess :-)  At that
moment I didn't realize that if you forward to a resolver that does
respect that SHOULD, you will not be able to obtain the proof in this
way and consequently regress, so the change would be double-edged in
this respect.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2019 09:30:58 -0400

> "local root" schemes (which are so far not commonly deployed, I think).

It could leak accidentally if the URL gets sent to the wrong browser. 

> way and consequently regress, so the change would be double-edged in

There is no need for DNSSEC proof of the nonexistence of these zones. They are nonexistent by postulate, not by theorem. :)

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 16 Aug 2019 10:46:55 -0400

As I often note, I work for ISOC but I'm not speaking for it.

> to some conditions that I explain below?

I think it's less than ideal, because the point of resolvers immediately
answering NXDOMAIN is that these are not and never will be names in
the global DNS.  That is, they really are special-use, and part of
that specialness is that they're part of the domain name space but not
part of the global DNS name space.

This is particularly true of onion, which is a protocol switch.  It's
intended to signal that you should _never_ look up that name in the
DNS.  That's its whole function.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Steve Crocker <[email-masked]>
Date: Fri, 16 Aug 2019 10:59:29 -0400

At the risk of revealing that I haven't been following this thread
carefully, I don't understand how a resolver is supposed to know all of the
special names.  Resolvers that are configured to know that invalid,
local, onion,
and test are special will not know about the next name that's put on the
special list.

I guess the larger picture is that onion is a protocol switch, so it's not
sufficient for a resolver to know that it shouldn't look up strings ending
in onion in the global DNS; it must also know what it should do.

Steve

---

From: Paul Vixie <[email-masked]>
Date: Fri, 16 Aug 2019 15:24:59 +0000

On Friday, 16 August 2019 13:10:02 UTC Ted Lemon wrote:
> ...
> ...

i think it's to reduce the time between a mouse click and an advertising 
impression, but i'm not an author so that's not "authoritative". it seems to 
me that the web's technical community doesn't love its surrounding context 
(the internet, i mean) and expects to eventually subsume it. (guessing.)

resolvers exist for reasons. resolverless anything requires strong motivation.

-- 
Paul

---

From: Joe Abley <[email-masked]>
Date: Fri, 16 Aug 2019 11:56:43 -0400

On 16 Aug 2019, at 10:59, Steve Crocker <[email-masked]> wrote:

> At the risk of revealing that I haven't been following this thread carefully, I don't understand how a resolver is supposed to know all of the special names.  Resolvers that are configured to know that invalid, local, onion, and test are special will not know about the next name that's put on the special list.

The pragmatic answer right now is that vendors and package maintainers do a good job with their default configurations. DNS software tends to get upgraded frequently enough in applications with significant user bases that this goes some of the distance.

I can see your point though that there might be some merit in having a way to retrieve a current list, or at least telling whether the list you have is up-to-date. I don't know that I think it's a particularly pressing problem though (I think DNSSEC trust anchor distribution for the root zone is higher up the priority list, for example).

Joe

---

From: Steve Crocker <[email-masked]>
Date: Fri, 16 Aug 2019 11:59:29 -0400

Ack.  Tnx.

On Fri, Aug 16, 2019 at 11:56 AM Joe Abley <[email-masked]> wrote:

> special names.  Resolvers that are configured to know that invalid, local,
> onion, and test are special will not know about the next name that's put on
> the special list.
>
> The pragmatic answer right now is that vendors and package maintainers do
> a good job with their default configurations. DNS software tends to get
> upgraded frequently enough in applications with significant user bases that
> this goes some of the distance.
>
> I can see your point though that there might be some merit in having a way
> to retrieve a current list, or at least telling whether the list you have
> is up-to-date. I don't know that I think it's a particularly pressing
> problem though (I think DNSSEC trust anchor distribution for the root zone
> is higher up the priority list, for example).
>
>
> Joe
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Aug 2019 10:19:49 -0700

To put things in perspective, the special use TLD defined according to
RFC 6761 account for about 4% of the traffic seen at the L root,
according to https://ithi.research.icann.org/graph-m3.html. Of those,
".local" account for a bit more than 3%, ".localhost" a bit less than
0.5%, and ".invalid" a bit more than 0.25%. The other reserved names see
very little traffic.

There are other sources of noise at the root, including traffic to
".home" (more than 2.5%), ".lan" (a bit less than 1%), ".internal",
".ip", ".dhcp" and ".localdomain", each accounting for about 0.5% of
traffic.

This pales in comparison to the computer generated unique names, which
account for 50% of the traffic seen at the root -- about equally spread
between generated lengths of 7 to 15 characters.

-- Christian Huitema

On 8/16/2019 8:59 AM, Steve Crocker wrote:
> Ack.  Tnx.
>
> On Fri, Aug 16, 2019 at 11:56 AM Joe Abley <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 16 Aug 2019, at 10:59, Steve Crocker <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     > At the risk of revealing that I haven't been following this
>     thread carefully, I don't understand how a resolver is supposed to
>     know all of the special names.  Resolvers that are configured to
>     know that invalid, local, onion, and test are special will not
>     know about the next name that's put on the special list.
>
>     The pragmatic answer right now is that vendors and package
>     maintainers do a good job with their default configurations. DNS
>     software tends to get upgraded frequently enough in applications
>     with significant user bases that this goes some of the distance.
>
>     I can see your point though that there might be some merit in
>     having a way to retrieve a current list, or at least telling
>     whether the list you have is up-to-date. I don't know that I think
>     it's a particularly pressing problem though (I think DNSSEC trust
>     anchor distribution for the root zone is higher up the priority
>     list, for example).
>
>
>     Joe
>
>

---

From: Erik Kline <[email-masked]>
Date: Fri, 16 Aug 2019 11:28:36 -0700

https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain

<random>
I have wondered whether or not it would be useful for IANA to have a git
repo where these canonical data could live alongside scripts that transform
them into things like C #include header files and zone file formats and so
on.
</random>

On Fri, 16 Aug 2019 at 08:00, Steve Crocker <[email-masked]> wrote:

> local, onion, and test are special will not know about the next name
> that's put on the special list.
>

---

From: Joe Abley <[email-masked]>
Date: Fri, 16 Aug 2019 15:28:47 -0400

On 16 Aug 2019, at 14:28, Erik Kline <[email-masked]> wrote:

> I have wondered whether or not it would be useful for IANA to have a git repo where these canonical data could live alongside scripts that transform them into things like C #include header files and zone file formats and so on.
> </random>

Since the nice IANA people have already made most (all?) of their registries available at stable URLs as XML, perhaps a collection of useful curated scripts such as you describe don't need to be kept in the same place as the data.

A script could be maintained in github to consume

  https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml

and produce things like

  special-use-domain-names.h
  special-use-domain-names.json
  special-use-domain-names.mp4 (the movie!)

without having to do any extra work on the IANA side. Well done to the IANA team for doing this, by the way. Having registries available in any structured format (even XML! :-) is a great improvement over the earlier text-based documents.

Joe

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 16 Aug 2019 15:30:18 -0400

I am like 2 minutes behind Joe on the XML link

Thanks Joe

On Fri, Aug 16, 2019 at 3:29 PM Joe Abley <[email-masked]> wrote:

> Since the nice IANA people have already made most (all?) of their
> registries available at stable URLs as XML, perhaps a collection of useful
> curated scripts such as you describe don't need to be kept in the same
> place as the data.
>
> without having to do any extra work on the IANA side. Well done to the
> IANA team for doing this, by the way. Having registries available in any
> structured format (even XML! :-) is a great improvement over the earlier
> text-based documents.
>
>
> Joe
>