[idn] iDNS transition: end-system vs. infrastructure?

[Dave Crocker <dcrocker@brandenburg.com>]

Folks,

I've been dogmatically applying the standard view that having to change
only end-systems is  much, much better for transition than having to
change
the infrastructure.  That is why MIME-like encapsulated encoding of the
UTF-8 string makes sense.

The only weakness to such an approach is when it is not possible to do
such
a change.  That is, when it is not possible to limit changes only to
"end
systems". IPv6 is largely an example of needing to change more than
end-systems, namely needing to change infrastructure, except for
IPv6-over-IPv4 tunneling and gatewaying between 6 and 4.  But really,
basic
IPv6 transition is a pure, dual-stack approach.  It does not work unless
and until the infrastructure has been upgraded to support it.  I've been
assuming that iDNS is better using MIME-like encoding than IPv6
dual-stack.

But is it really?

DNS Exchanges are between a client and a true server -- that is, the
entire
transaction is between the DNS client and the DNS server.  The DNS
server
is the real and only target.  By contrast for email, there is a sender
at
one end (email originator) a receiver at the other (email destination)
with
an infrastructure in the middle (SMTP relays).

The DNS infrastructure comprises the DNS servers, I think.  But iDNS
does
not work unless new types of strings are IN THE SERVER.  The "MIME"
model
has been applied on the theory that the server changes are limited to
the
administrative software, which installs an iDNS string into an otherwise
unchanged server.

However it strikes me that having to change a server's administrative
software is no different than having to change some other part of the
server.  That means that iDNS is inherently an infrastructure
transition,
and not really subject to an an end-system transition strategy like
encapsulation.

Let's look at this from another perspective:

There is no problem with a aDNS (old-time ascii DNS) client talking to
an
iDNS server, I assume.  So we can ignore that case.  iDNS client talking
to
iDNS server is even more uninteresting.

So the only interesting case is an iDNS client talking to an aDNS
server.

What is an iDNS client?  It is a user with an iDNS string.

Test 1 (DNS client-side):  If a user enters a UTF-8 string to DNS client
software, what breaks?  That is, if the user with an international
domain
name tries to use client software not ready for it, what happens?

Test 1, tentative answer:  What happens whenever any user tries to use
facilities not supported by their client software?  Bad things.  But
that
is the user's problem to work out with the client software supplier.
This
is no different.  We can therefore, I think, ignore this case,
dismissing
it as "tell the user to upgrade".

Test 2 (DNS server-side):  A user with an iDNS string and an
iDNS-capable
client queries a non-iDNS server.

Test 2, meta-answer:  This is already an error condition; the query is a
mistake.  That is if the server does not support iDNS, then it certainly
won't be holding the entry for the iDNS name that is being
provided.  Hence, querying that DNS server should not be happening!

Test 2, part a:  The UTF-8 shows up at the aDNS server.  The most
important
question is whether the server crashes.  A server that crashes from
malformed input data is a pretty sorry server, but IFF the condition is
prevalent it cannot be ignored.  If the condition is rare, then it can
perhaps be ignored, or treated as less than a showstopper.

Test 2, part b:  If the aDNS server does not crash, does the response
from
the server cause the iDNS *client* to crash?  We can constrain the
problem
by finding out what these responses are, currently, and writing them
into a
client specification.  That should eliminate this factor as a concern.

Test 3:  Client side application-level support for iDNS (the software
that
is the iDNS client's client.)  As with Test 1, this can be ignored by
virtue of being between consenting user and client software provider.

Test 4, parts a and b:  Replicate Test 2 questions, but for
application-level iDNS string servers.  This needs to be sampled around
the
net.  Any substantial amount of server applications crashing (hence Test
4,
part a) is a serious problem, possibly with no clear resolution.

What cases have I missed?

How hard would it be to do some large-scale sampling of deployed servers
around the net?


Summary:

         Users of iDNS currently need revised software.  No matter what
the
technical approach for creating iDNS, users will always need revised
software.  It must be both revised application software and revised DNS
client software.

         Hence, the primary concern for "just do pure UTF-8" is the
effect
of sending UTF-8 to an aDNS server.  However the nature of DNS is such
that
a DNS field with a UTF-8 string only gets sent to a server that is
supposed
to be able to resolve the that field.  With one exception:  The only
time
an aDNS server is likely to get an iDNS query is when the server is
doing
primary support for end-users.  That is, when it is the DNS server that
is
first contact by a client.

d/



----------
Dave Crocker   <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464