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

[Joe Abley]

Hi Stéphane,

On 28 Apr 2016, at 03:25, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:

> I received one approval and one request for precision. In the next
> version of the Internet-Draft, can I write:
> 
> "AS 112 operators were consulted on 21-04-2016 and expressed no
> objection."

That seems accurate, as written :-)

I had not noticed your draft. Since I don't have much else going on this morning over breakfast, I read it and made a few notes that might be useful (see below).


Joe

> Network Working Group                                      S. Bortzmeyer
> Internet-Draft                                                     AFNIC
> Intended status: Standards Track                          April 21, 2016
> Expires: October 23, 2016
> 
> 
>      Using DNAME in the root for the delegation of special-use TLDs
>                      draft-bortzmeyer-dname-root-01

"Root" is a bit vague if you're not a DNS addict, and "delegation" is a bit inaccurate, since you're not actually talking about a delegation here.

How about something like "Sinking Special-Use TLD Queries on AS112 Name Servers using DNAME"?

> Abstract
> 
>    This documents asks IANA to add DNAME records in the DNS root for

"root zone"

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

>    REMOVE BEFORE PUBLICATION: there is no obvious place to discuss this
>    document.  May be the IETF DNSOP (DNS Operations) group, through its
>    mailing list (the author reads it).  Or may AS112 operators mailing
>    lists?  The source of the document, as well as a list of open issues,
>    is currently kept at Github [1].

You could use this list as a venue. People here are at least evidently listening.

> [...]
> 
> 1.  Introduction and background
> 
>    The DNS root receives a lot of requests for TLDs which do not exist.

Root servers receive queries for names under TLDs which do not exist.

>    See for instance [fujiwara-root-traffic] or [icann-l-root-stats] or
>    [ssac-045].  In the spirit of [RFC7534], it would be good if they
>    could be redirected to a sink such as AS112, to save root's
>    resources.

"Root servers". 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.

>    Some of these names, and specially one of the biggest offenders,
>    .local ([RFC6762]), are registered in the Special-Use Domain Names
>    registry [2] of [RFC6761].  They are obvious candidates for a
>    delegation to the sink.

See above re obvious. I think there are some questions to answer to make this argument more persuasive.

>    It is proposed to use the new AS112, the one described by [RFC7535]
>    to implement this sink.
> 
>    TODO: results of the discussion with AS112 people

Hi!

> 1.1.  Requirements Terminology
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].

Incidentally you have this document marked for the standards track; BCP might be less controversial. I don't remember procedurally whether either of these is easier than the other for an individual-stream submission. You might ask a friendly AD.


> 2.  Rules
> 
>    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. Are you just talking about single-label domains in that registry, or might you include a future name that had empty non-terminals?

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? I realise those have practical problems (the former RIR policy and the latter gTLD policy) but it's not like the root zone is without those kinds of difficulties either (see below).

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 is important to notice that this document does not define a policy
>    to decide if a TLD should be "delegated" or not.  Instead, it relies
>    on the existing Special-Use Domain Names registry and its rules.
> 
>    RFC-EDITOR: remove before publication.  As of today, with these
>    rules, .local ([RFC6762]) or .onion ([RFC7686]) would be delegated
>    but not .example (its registration in [RFC6761] does not define
>    special handling for resolvers) or .home or .belkin (this last one
>    generates a huge traffic at the root but is not in the Special-Use
>    Domain Names registry).
> 
> 3.  Benefits
> 
>    The main benefit is less load on the root and a better efficiency of
>    the caches, therefore helping the entire DNS ecosystem.

See above. I think some investigation of this benefit both with reference to the standards and with reference to observed traffic is warranted.

> 4.  Possible issues
> 
>    Of course, the solution described in this document requires a good
>    support of DNAME by the resolvers.  Appendix A of [RFC7535] describes
>    an experiment which was run in 2013 and which shows that, indeed, we
>    can rely on DNAME (quoting the authors: "We conclude that there is no
>    evidence of a consistent failure on the part of deployed DNS
>    resolvers to correctly resolve a DNAME construct.").

As co-author of 7535 I approve of this message.

>    Regarding DNSSEC, do note the future DNAMEs in the root will be
>    signed, but the target, empty.as112.arpa, is not.  See George
>    Michaelson's message [4].  So, it will not be possible to validate
>    the answers.  Not a problem since these requests should never have
>    been sent to the root, anyway.

I seem to recall there is some commentary in 7535 about this. 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.

> 5.  IANA Considerations
> 
>    IANA is requested (TODO what is the appropriate wording?) to add a
>    DNAME in the root for every TLD which fits the rules of Section 2.

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

>    RFC-EDITOR: remove before publication.  There is currently no DNAME
>    in the root.  It is expected that the creation of the first one will
>    require a top-down, multi-stakeholder, long and complicated process
>    with a lot of meetings, reports by consultants and design teams.

I think it's anybody's guess would be or might not be difficult with regard to root zone management policy at this current point in governance history. Back in the days when variant IDN TLDs were a hot topic there was 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 who you know, so you might ask him if Google has not heard of it.

I would observe though that the machinery currently in place to manage the contents of the root zone took years and years to implement, and to my knowledge only supports delegation (with NS sets). So presumably if there was a call to deploy DNAMEs in the root zone that was not held up indefinitely for layer-9 reasons, 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.

> 6.  Security Considerations
> 
>    The requests for the TLD in the Special-Use Domain Names registry are
>    typically NOT supposed to leak to the authoritative public name
>    servers such as the ones of the root.  If they do, it means a
>    misconfiguration somewhere.  The leak is independant on whether the
>    name is delegated to AS112 or not.  See section 8 of [RFC7534] for an
>    analysis.  Some people believe there are added risks, because the
>    queries will be seen by AS112 servers which, unlike the root, are
>    managed by many "random people".

I think this document needs some discussion of the privacy implications.

This document would leave a dribble of leaked queries for special-use names on the root servers, but would (likely, see above) send the bulk of it to AS112 servers. This means that population of people who can see the query streams is increased from the set of root server operators and people that they (e.g.) share DITL data with, to potentially anybody. There's no defence against a malefactor hijacking AS112 traffic, because in a real sense that traffic is intended to be hijacked.

This seems like a problem for LOCAL and ONION, since in both cases the whole special-use specified for them involves the isolation of resolution to a separate protocol, and any unexpected leaking is bad but presumably more is worse. This proposal would cause queries to leak further, which feels a bit like more? Perhaps that's worse?


Joe