Request for input and participation (fwd)
dean at av8.com
Mon Mar 8 21:35:12 CET 2010
It seems that ambiguity in IDNA-Update is causing operational problems,
and the DNSEXT Chairs are stumped. Well, that isn't very surprising
given both the ambiguity cited by JFC Morfin and the lack of relevant
experience of the DNSEXT chairs. But it isn't helped by the fact that
Sullivan hasn't any relevant engineering experience. Sullivan was a
Database Administrator for Affilias before being appointed Chair.
Sullivan has a master degree in philosophy, but that usually qualifies
one to be a clerk in a book store or a Teaching Assistant in Philosophy
at a small college, rather than being put in charge of DNS protocol
development. Both DNSEXT WG Chairs now work for Steven Crocker, who has
given Sullivan the title of "Internet Scientist", despite a lack of
Internet or Scientific credentials and lack of relevant experience.
JFC: What's the status of your appeal?
---------- Forwarded message ----------
Date: Mon, 8 Mar 2010 14:03:11 -0500
From: Andrew Sullivan <ajs at shinkuro.com>
To: ietf at ietf.org
Subject: Request for input and participation
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
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.ietf.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:
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
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.ietf.org mailing list
for the discussion.
Many thanks for your indulgence of this long message.
Olafur Gudmundsson and Andrew Sullivan
ajs at shinkuro.com
Ietf mailing list
Ietf at ietf.org
More information about the Idna-update