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

From: Brian Dickson <[email-masked]>
Date: Fri, 14 Oct 2016 17:05:36 -0700

On Fri, 14 Oct 2016, Stephane Bortzmeyer wrote:

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

On Fri, Oct 14, 2016 at 10:04:21AM -0400,

Paul Wouters <paul at nohats.ca> 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.

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

One of the cleverer things about DNAME is that it requires synthesis of
QNAME-matching CNAMEs.
So, if the stub client does not speak DNAME but the resolver does, the
resolver MUST synthesize the CNAME.
And, if the resolver does not speak DNAME, it only understands the
synthesized CNAME and only caches that.

Of course, in the AS112 usage, it is a DNAME or CNAME to an NXDOMAIN, by
design.

I think that any other proposal (e.g. Mark A's idea, or other localized
things) can happily co-exist with the AS112 thing.

At a minimum, it lowers the rate of noise queries to root servers.
One possible beneficial side-effect is the encouragement of deployment of
more AS112 instances.

I think it is worth documenting, and then seeing how much support there is
once the wording is polished.

Identifying the benefits and cases that it best fits are useful, IMHO.

I think demonstrating that the idea of "Do AS112 for ALT, and be done with
it" scales well, is something it could document.

Brian

P.S. Apologies for any formatting wonkiness. Cut/paste from archives, which
is where I read some groups these days.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 Oct 2016 17:16:43 -0700

A short time ago, in a time zone not far away, Warren Kumari wrote:

>> 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,

> 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?

My observation here is "yes and no"; the nature of AS112 is that anyone can
deploy an instance, pretty freely/easily.

Basically, the only thing that changes is where those leaks go, not whether
they occur.

The DNAME to AS112++ is a (root) server-side thing, which is not mutually
exclusive (compared to resolver side solutions).

Doing BOTH is probably the most conservative approach. DNAME will work in a
backwards-compatible fashion with older resolvers.
(This was confirmed in the AS112++ work, by Geoff Huston and George
Michaelson, kudos to them. DNAME w/CNAME synthesis FTW.)
Anything else is an optimization, e.g. RFC 6303 stuff.

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.

A minor caveat: we should be careful in the language we use, to distinguish
"delegate" (use NS) vs DNAME.
A delegation would indeed be lame, while DNAME to AS112++ will never be
lame, per se.

I agree, we should take "delegate" off the table.

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.

What is the consensus view of now vs 2014? Has anything changed, do we
think?
(I recognise the difficulty in consulting the "magic 8 ball" where
deployment in the root is concerned.)

There is also a big difference between "reserving" something and

actually getting it delegated, even for a "null" answer.

Again, technically, in the DNAME to AS112++, this would be for an
"NXDOMAIN" answer.
But, this is a big difference, in that the result is indistinguishable from
the querier's point of view.

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.

(I would point out that doing "in situ" AS112++ on the caching DNS server
is one way to accomplish this.)

   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.

For this (5), using the DNAME solution does this explicitly, while "reserve
but don't do anything" does this implicitly.
I like the explicitness of DNAME, only because it tells a human making
inquiries that this is in fact "special".

Brian "DNAME" Dickson