Dear colleagues,
The DNS Extensions Working Group has been asked to consider how to
make two zones "work the same way" on the Internet.
In order to address this desire, DNSEXT held a virtual interim meeting
in February in an effort to understand what options are open to us and
what sort of problem we think we have. One consequence of that
discussion was a plan to take one hour of our planned meeting in
Anaheim, and devote it to this topic. (If you want more information
about what happened in that meeting, the minutes have been sent to the
proceedings address. Since they won't be available immediately that
way, we've also uploaded them to the DNSEXT wiki pages on the IETF
tools site.)
We need feedback from the wider IETF (and Internet) community on what
problem, exactly, we are trying to solve, and whether it is even
possible to solve that problem. The WG co-chairs are therefore asking
interested people to consider this topic, and either to send their
remarks to the DNS Extensions mailing list
(namedroppers(_at_)ops(_dot_)ietf(_dot_)org), to come to the DNSEXT meeting in
Anaheim,
or both. The remainder of this message is some background to the
discussion. Apologies for the length.
Here is what the DNSEXT chairs believe so far.
The immediate stimulus for this work is Internationalized Domain
Names for Applications, and particularly the IDNA2008 work. In the
context of IDNA, some operators apparently have a need to operate
"variant" zones, with two different DNS names apparently working as
though they are "the same". There are some other obvious contexts,
however, in which similar functionality could be useful.
It is not entirely clear what "the same" means in the above. It might
mean that the two labels work exactly the same way with respect to
caches, it might mean that loose coupling roughly similar to the way
(say) DNAME works would be good enough, or it might be something
else. It is also possible that the issue is one that could be
supported almost completely by alterations to provisioning practices.
The two existing approaches to "aliasing" zones in the DNS do not
solve the problem as we currently understand it. DNAME can alias
everything underneath a name, but does not provide a mechanism to
alias the name itself. CNAME, on the other hand, can alias the name
itself but not things underneath that name. CNAME and DNAME cannot
both exist at the same name in the DNS. And both of these have
implications further down the DNS tree, for record types like MX.
Three Internet Drafts have so far appeared in the repository around
this general topic:
draft-vixie-dnsext-dnsshadow
draft-yao-dnsext-bname
draft-yao-dnsext-identical-resolution
One of our goals in Anaheim will be to try to confirm whether our
understanding of the acceptable compromises for these "aliases" is
correct. In the discussion so far, we have mostly been assuming that
the traditional loose coherence of the DNS applies also to "aliases",
so that it would be technically possible for a single client to get
different answers to the same type and class of query for two names
that are aliases of one another. We have also mostly been assuming
that it is acceptable for one name to be "prior" to all others
aliases, as long as there is an (in-protocol) mechanism to discover
which name has priority. Finally, we have mostly been assuming that,
if the work is really needed, it can require some additions to the DNS
protocol.
We are hoping that people who are interested in using the DNS for
these purposes will help us confirm that the problem we believe people
said they have is actually the problem they have, and that the
assumptions we are making about what is acceptable are correct. We
ask those interested to use the namedroppers(_at_)ops(_dot_)ietf(_dot_)org
mailing list
for the discussion.
Many thanks for your indulgence of this long message.
Olafur Gudmundsson and Andrew Sullivan
DNSEXT co-chairs
--
Andrew Sullivan
ajs(_at_)shinkuro(_dot_)com
Shinkuro, Inc.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf