Eszett and IDNAv2 vs IDNA2008

[Erik van der Poel]

On Thu, Mar 12, 2009 at 2:18 PM, Andrew Sullivan <ajs at shinkuro.com> wrote:
> 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 about using CNAME with xd-- like this:

;; QUESTION SECTION:
;www.strasse.de.   IN  A

;; ANSWER SECTION:
www.strasse.de.  0 IN  CNAME www.xd--strae-oqa.de.
www.xd--strae-oqa.de.  300 IN  A 78.47.200.154

> 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).

Sure, I can understand that it takes time to come up with new APIs and
get their implementations into users' hands. In the meantime, you can
use http://<domain-name>/idndisp.txt. That's why I said that
idndisp.txt can be used during the transition. And, even if the app
has not been upgraded yet, it's hardly a disaster if it displays
strasse instead of straße.

> 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.

xd-- tells the client to do something special at display time. So does
xn--. If xn-- gets to have special treatment, why can't xd--?

> 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.

Sure, xd-- is a filthy hack. But we already know that there is no
clean solution. We already know that we have to choose the least
stinky solution.

Note that this idea is not necessarily my "final" position. I prefer
to explore various ideas so that we can be sure that we considered all
(or many) possibilities.

Erik