]>
Using DNAME in the DNS root zone for sinking of special-use TLDsAFNIC1, rue Stephenson78180Montigny-le-BretonneuxFrance+33 1 39 30 83 46bortzmeyer+ietf@nic.frhttp://www.afnic.fr/This documents asks IANA to add DNAME records in the DNS root zone for
TLDs which are in the Special-Use Domain Names registry, in order to ensure they receive an
appropriate reply (NXDOMAIN) and that the root nameservers are not too bothered by them.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.The DNS root nameservers receive a lot of requests for TLDs which do not
exist. See for instance or or . In the spirit of , it would be good
if they could be redirected to a sink such as AS112, to save
root nameservers's resources.Some of these names, and specially one of the biggest
offenders, .local (), are registered in
the Special-Use Domain Names registry of . They are obvious candidates for a "delegation" to
the sink.It is proposed to use the new AS112, the one described by
to implement this sink.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 .Every TLD (, section 2) which is in the
Special-Use Domain Names registry ()
SHOULD be "delegated" by IANA through a DNAME () to empty.as112.arpa as
described in if and only if the
registration of this TLD say that resolvers SHOULD NOT or MUST NOT
look them up in the DNS.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 ()
or .onion () would be "delegated" but not .example (its
registration in does not define special
handling for resolvers) or .home () or .belkin (this last one generates a huge
traffic at the root nameservers but is not in the Special-Use Domain Names registry).The main benefit is less load on the root nameservers and a better efficiency
of the caches, therefore helping the entire DNS ecosystem.Of course, the solution described in this document requires a
good support of DNAME by the resolvers. Appendix A of 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."). The technical tests documented in have the same conclusion: DNAMEs work
fine.Currently, the root is managed both by ICANN and by Verisign,
with an EPP link between them (see ).
There is no EPP mapping for DNAME "delegations", does not envision this case. A project is under
way, to create a new EPP extension for DNAME "delegation", see
. Of course, it is
expected that this small technical problem is of little importance
compared with the "Internet governance" problem of having ICANN
allowing such DNAMEs (see ).Because DNAME require additional processing by the authoritative
servers (, section 3.2), root name servers
operators may estimate that it will add an unknown risk for them (at
least, it will be more work for the server).What could be the expected "saving" of resources by this
"delegation"? Well-behaved resolvers should cache the NXDOMAIN
(negative caching duration in the root zone is currently one day)
but this covers only the requested name, not the whole TLD (until
is widely deployed and
it would only partially solved the issue). There
is also a concern that the requests for these non-existing TLDs are
not issued by "proper" systems (because they are supposed to never
leave the local network). If these requests are sent by badly
programmed or badly configured systems, can we be sure they will
honor the "delegation" and the caching? To summarise, it would be
interesting to design and conduct an experiment to measure the
expected effect. Ideas are welcome (the most obvious one, running a
"delegation" during a moment then deleting it and comparing the
results, is difficult to foresee, for political reasons).To be sure AS112 could handle the load, AS 112 operators were
consulted and expressed no
objection.Regarding DNSSEC, do note the future DNAMEs in the root zone will be
signed, but the target, empty.as112.arpa, is not. See George
Michaelson's message. So, it will not be possible to validate
the answers. Not a problem since these requests should never have
been sent to the root nameservers, anyway.RFC-EDITOR: remove before publication. As of today, it exists
apparently five nodes in the new AS112. There is no "official" "delegation" to
it. Do note that, as a consequence of the new AS122 structure, it is
not possible to see how many unofficial "delegations" exist (to see an
example, see sink.bortzmeyer.fr).IANA is directed to add a
DNAME in the root zone for every TLD which fits the rules of .RFC-EDITOR: remove before publication. There is currently no DNAME
in the root zone. 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. We already have one short mention of this possibility in , then one decision by ICANN to study the matter and one technical
report made after that decision ("This
report found no failure in resolution nor in the ability to perform
DNSSEC validation when DNAME was used in the root zone.")TODO: if DNAMEs in the "real" root zone are delayed, is it
possible/realistic for IANA to create an experimental root zone
containing the new AS112 "delegations", so that roots like Yeti could
publish it and test it?REMOVE BEFORE PUBLICATION: there are today TLDs with a DNAME at their
apex (not the same thing): xn--kprw13d and xn--mgba3a4f16a.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 zone. 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 for an analysis.Nevertheless, privacy considerations have to be taken into
account. Some people believe there are added risks, because the
queries will be seen by AS112 servers which, unlike the root
nameservers, are managed by many "random people". This means that
population of people who can see the query streams is increased from
the set of root nameserver operators and people that they share 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.Thanks to Paul Hoffman to say that it may be a good idea, for
Patrik Faltstrom for documentation and research,
for Joe Abley for tough proofreading and many suggestions, and for Ted
Lemon to give the final impulse, with his .
&rfc2119;
&rfc6672;
&rfc6761;
&rfc7534;
&rfc7535;
&rfc7719;
&rfc5731;
&rfc6762;
&rfc7686;
&rfc7788;
&rfc8020;
&rfc8244;
&I-D.bortzmeyer-regext-epp-dname;
2014 Root DITL Data analysis and TLD popularity analysis
(OARC workshop)QTYPE values for most popular TLDs (ICANN's L-root server
public statistics)SAC 009 - Alternative TLD Name Systems and Roots: Conflict, Control and ConsequencesSAC 045 - Invalid Top Level Domain Queries at the Root Level
of the Domain Name SystemReport on the Assessment of Security and Stability
Implications of the Use of DNAME Resource Records in the
Root Zone of the DNSAdopted Board Resolutions - IDN VariantsUpdate on IANAThis alternative was drafted by John Levine. It works without
adding DNAME records in the root zone, which solves some of the issues
noted in and , but it
requires new IANA work: setting up new zones (and it still requires
changes in the root zone).To delegate, say, .onion:
onion. NS a.iana-servers.net.
onion. NS b.iana-servers.net.
onion. NS c.iana-servers.net.
And, in the tiny zone file hosted at *.iana-servers.net:
onion. SOA whatever
onion. NS a.iana-servers.net.
onion. NS b.iana-servers.net.
onion. NS c.iana-servers.net.
onion. DNAME empty.as112.arpa.
It does not have exactly the same result as the main proposal, since a DNAME record
works only for names under it, not for the owner name itself.