Idna-update Digest, Vol 27, Issue 47

Andrew Sullivan ajs at shinkuro.com
Thu Mar 12 23:21:37 CET 2009


On Thu, Mar 12, 2009 at 10:09:07PM +0000, Shawn Steele (???) wrote:
> 
> 104.164.92.66.in-addr.arpa.  PTR xd--strae-oqa.shinkuro.com.
> 
> That shouldn't break anything, although admittedly reverse DNS isn't very consistent.  Clients could require that the name at least mapped to the name they were looking for.
> 

I think that's going to make a mess for hosts that rely on PTR records
for other things.  This is a more promising line, though.  My big
question is still how you're going to get to it -- all I ever hear
from application programmers is how they can't get to any of this DNS
data anyway.

> What about an IDN type? :)

That's what I've been arguing you actually need for this, and it will
require all kinds of upgrades.  Basically, any node that doesn't
understand the new RRTYPE won't be able to do anything with it.  _And_
you need this to be returned automatically with the A/AAAA record of
the target RNAME.  Special processing of this sort requires the server
to know how to do it, and it's a really big deal -- it certainly
requires IETF consensus to add.  (To draw an analogy, what you really
want here is not another column, but an ON SELECT trigger.  ON SELECT
triggers are a big problem to add.)

The whole reason IDNA is this bag-on-the-side design is because
unfortunately upgrading the DNS to do this properly is very, very hard
in practice, even though it ought not to be very hard to do in principle.

A

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


More information about the Idna-update mailing list