Eszett and IDNAv2 vs IDNA2008

[Andrew Sullivan]

On Thu, Mar 12, 2009 at 12:45:28PM -0700, Erik van der Poel wrote:
> ;; QUESTION SECTION:
> ;strasse.shinkuro.com.      IN  A
> 
> ;; ANSWER SECTION:
> strasse.shinkuro.com.   300 IN  A 66.92.164.104
> 
> ;; AUTHORITY SECTION:
> shinkuro.com.   300 IN  NS  UDNS2.ULTRADNS.net.
> shinkuro.com.   300 IN  NS  xd--strae-oqa.shinkuro.com.
> shinkuro.com.   300 IN  NS  UDNS1.ULTRADNS.net.
> 
> As I said, there may well be some good reasons not to do this. I'm
> sure DNS experts could come up with some reasons.

So you want me to add a new NS record to my domains whenever I want an
ASCII label to appear differently than the actual ASCII label that's
looked up?  And then sometimes resolvers will use that NS record to
mean "look up things here" and other times resolvers will also use
that NS record to mean "display the hostname in this other format"?
And just to be clear, this new NS record is in fact a real name
server?

One built-in problem is that you have a limit to how many hosts you're
going to be able to do this for.  The actual maximum number of name
servers you may have for any given name is actually variable under the
protocol, as it depends on other factors about your zone.  By
convention it's 13, and that's certainly the maximum number permitted
by many registries.  For a small zone like shinkuro.com, this might
not matter; but it'd be a rather big deal for .de, I bet.

What makes you sure that the application is going to be able to see
all those NS records?  On the apps-discuss list, I started a thread
about exactly what application designers need from the DNS, and
several people have weighed in with remarks about how impossible it is
to get anything into the application, because the APIs aren't there.
The application does getaddrinfo().  IDNA gives you a rule for how you
translate a U-label into the A-label that goes into getaddrinfo().
Ideally, I suppose, you'd hand a U-label to getidnaddrinfo() and it
does all the magic.  But the getidnaddrinfo APIs isn't shipping yet,
AFAIK, and so we're back to what Jaap said: you need every resolver in
the world to be upgraded for this to work reliably.  Either that, or
accept that it will work very unreliably for a long time (which raises
the question of why anyone would bother).

And this takes us back to my worm-can complaint: the day we start
talking about any solution that requires all the resolvers in the
world to be upgraded, we will have everyone with a DNS axe to grind
lined up, saying, "As long as you're replacing everything, let's fix
this at the same time."  (I think there are people on this list who
will join the line.)  And if we're going to require that all the
resolvers get fixed, I can think of better ways to do this than to
overload the meaning of one RRTYPE so that sometimes it means one
thing, and sometimes it means two things.  Frankly, we have enough
problems in the DNS due to clever re-use of RRTYPEs to tell us that
doing it with the NS records as well is a bad idea.  The details of
that are way off-topic for this list, but I'll be happy to expand in
another venue, if need be.

So the short answer is that your proposal could sort of be made to
work, as a filthy hack, some of the time.  I am strongly opposed to
making such an approach into any kind of standard.  To undertake
equivalent functionality correctly amounts to starting work on DNS2, a
project that even in my wildest moments of optimism I believe will
take more than 20 years to get working (DNSSEC isn't flully deployed
yet, after all).  And that's why some of us regard the discussion as a
distraction: even if it has some merit, it's not going to yield the
kind of results we want in the period of time we'd like.

Best,

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.