[as112-ops] Advice requested on a proposal to delegate .local to AS112

[Stephane Bortzmeyer]

On Thu, Apr 28, 2016 at 07:43:35AM -0400,
 Joe Abley <jabley at hopcount.ca> wrote 
 a message of 252 lines which said:

> "Root" is a bit vague if you're not a DNS addict,

OK, I made sure that root is never used naked and that it's always
"root zone" or "root nameservers" depending on the case.

> and "delegation" is a bit inaccurate, since you're not actually
> talking about a delegation here.

RFC 7534 uses it "The extension of the AS112 service to include the
ability to have additional zones delegated for sinking or removed
using the DNAME resource record."

While searching for a better term ("redirection"?), I put it between
quotes everywhere.
   
> >    TLDs which are in the Special-Use Domain Names registry, in
> >    order to ensure they receive an appropriate reply (NXDOMAIN)
> >    and that the root is not too bothered by them.
> 
> They won't receive an NXDOMAIN from the root servers, of course.

They do but the important word is "and"

> Specifically, the suggestion is presumably that the amount of
> unwanted traffic arriving at the root servers is reduced. How
> confident are you that this proposal would help? Name errors from
> the root servers are presumably cached by well-behaved clients;
> DNAME responses would also be cached, and name errors from
> AS112.ARPA servers would be cached.
> 
> Is the benefit of caching the extra DNAME non-zero for the root
> servers? That is, in practice, do enough clients honour TTLs and
> demonstrate caching of the DNAME and the name error? Note that we're
> talking about clients that are sufficiently poorly-behaved to be
> sending these queries in the first place, so relying upon their
> correct implementation seems potentially to be a silly thing to do.

Caching does not solve everything because a request to the resolver for
le-pc-de-jean.local followed by one for joe-s-pc.local would still
make two requests. See draft-dnsop-nxdomain-cut for details and
discussion.

Regarding the "badly behaved" argument, I think there are two ways to
be badly behaved. One is a configuration error, the machines query a
resolver which is not authoritative for .local and therefore leak
data. Such setup is bad (it sends .local queries to the root
nameservers) but it normal, from a DNS protocol point of view. Such a
resolver would obey caching, DNAME, etc.

The second way is really broken software, sending queries
everywhere. In that case, and in that case only, you are right, they
would not use the new sink.

Any idea of a test setup to prove that there would be a win? Because
we can suspect that many real clients would not behave properly, a lab
with BIND, NSD and Unbound would not be enough. IMHO, the only real
way to be sure would be to add a DNAME during 24 hours in the real
root (may be during a DITL).

> Incidentally you have this document marked for the standards track;
> BCP might be less controversial.

This document requests IANA to do something in a critical resource. I
don't think it will work without at least a document on the standards
track.

> >    Every TLD ([RFC7719], section 2) which is in the Special-Use
> >    Domain Names registry [3] ([RFC6761]) SHOULD be delegated by
> >    IANA through a DNAME to empty.as112.arpa as described in
> >    [RFC7535] if and only if the registration of this TLD say that
> >    resolvers should not or must not look them up in the DNS.
> 
> It might be worth spelling out what you mean by TLD.

RFC 7719, section 2 :-)

> Are you just talking about single-label domains in that registry, or
> might you include a future name that had empty non-terminals?

Well, other non-TLD names make less problems. 
 
> Also, if it makes sense for ONION to earn a DNAME in the root zone,
> might it not make sense for B.E.F.IP6.ARPA or EXAMPLE.ORG?

example.org does not fit the rules (no special handling in the DNS),
anyway. That's not because it is made of two labels. 

> It's not clear if "should" or "must" are normative since they're
> lower-case. I presume the intention is that they are normative.

It's complicated because it's a reference to the RFCs actually
"reserving" these TLD. The RFCs use capitals, so I switched to capitals.

> >    Regarding DNSSEC, do note the future DNAMEs in the root will be
> >    signed, but the target, empty.as112.arpa, is not.
> 
> I seem to recall there is some commentary in 7535 about this.

I didn't find it.

> Signatures over EMPTY.AS112.ARPA have no value since they would rely
> upon the use of a private key that was essentially public. Any
> signature would be compromised and therefore useless (untrustworthy)
> by design.

I agree.

> I usually direct the IANA. And when I see them at meetings I buy
> Michelle a beer.

Not Amanda?

> at least one investigation into the use of DNAME in the root zone
> commissioned, however, and I remember that report being delivered
> and published. Whether or not you can find it today is a separate
> question :-) The author was João Damas

Added to the draft (as well as SAC-009 and a few others).

> that machinery would not be used and the DNAMEs would be added in
> the same way that other irregular changes (like root servers being
> renumbered) that don't fit in RZM are managed.

Not a real problem, the Special-Use domain registry is quite static.

draft-bortzmeyer-dname-root-02 now published, thanks.