Impact of Punycode

Dean Anderson dean at
Thu Mar 25 22:30:11 CET 2010

IDN impacts DNS if it makes DNS case-specific.  There is another
proposal right now in DNSEXT that I can't oppose (due to dishonest,
unlawful censorship) that would make unknown Resource Records case
specific.  It is a consequence of broken Dynamic Update and the
introduction of unknown Resource Record types.  What should have
happened is for Dynamic Update to be fixed to avoid unknown RR types.  
But the people who could do that are silenced and threatened, and the
people in charge don't have the necessary skills, other than cronyism
and a desire to further frauds of the Cerf/Adams/Crocker/Vixie cartel,
or at least to DOS-attack my business (e.g. my recent post on Chris
Morrow, GROW WG Chair and Andrew Sullivan, DNSEXT Chair)  (See
for discussion of the Unknown RR issue)

How does one compare case-insensitively in punycode?

IDN requires more thought. Updating DNS servers and resolvers seems
unavoidable in order to do proper caseless comparison. And the cost of
updating clients also needs to be considered.


On Thu, 25 Mar 2010, Shawn Steele wrote:

> I’m NOT arguing changing or replacing IDN.  I’m saying that it
> isn’t easy to fix ALL of the client apps.  We made it “easy”
> (sort of) for the DNS side, but at the expense of confusion on the
> client side.
> I am suggesting that for Email, the EAI approach is less problematic.  
> Yes, e-mail servers will need updated, but there will be less
> long-term confusion.
> -Shawn
> From: idna-update-bounces at [mailto:idna-update-bounces at] On Behalf Of Vint Cerf
> Sent: Poʻahā, Malaki 25, 2010 11:28 AM
> To: Shawn Steele
> Cc: idna-update at
> Subject: Re: Impact of Punycode
> shawn, if you have a better strategy maybe it is timely to start
> another BOF. In the past attempts to do IDN, the client-only approach
> has been adopted because of the difficulty of changing all the servers
> and resolvers. If enough simplification would result from such a
> mandate, perhaps it is at least worth looking at fully. My
> recollection is that some people tried for a new Class of DNS record
> other than IN because it could have different properties (that would
> have to be known to the servers and the resolvers, of course). That
> approach did not gain consensus.
> vint
> On Thu, Mar 25, 2010 at 2:18 PM, Shawn Steele <Shawn.Steele at<mailto:Shawn.Steele at>> wrote:
> > Nothing about IDNA200x should have any effect of any sort on any DNS server
> > that "handled UTF-8".  DNS labels are not restricted to ASCII, and never have
> > been: they're octets.  The LDH rule is not a "DNS restriction".  It's an effect of
> > the way the hostname syntax got used inside the DNS.
> IDN doesn't impact "DNS".  It impacts people using domain names.  Now
> the APPLICATIONS have to have domain knowledge about a protocol that
> means very little to the application.  For example, if you make an
> http request, the xn-- name can get into the http request.  Certainly
> the IDNAxxxx docs say nothing about http requests.  What's a web
> server to do if it gets a UTF-8 request?  A Punycode request?
> In making things "simple" for DNS, we made things very hard for the
> rest of the system.
> Sort of way off topic for an IDNA list, and I'm not suggesting that we
> abandon IDNA, but I'd MUCH rather see the EAI approach than experience
> the same problems with other protocols.
> - Shawn
> _______________________________________________
> Idna-update mailing list
> Idna-update at<mailto:Idna-update at>

Av8 Internet   Prepared to pay a premium for better service?         faster, more reliable, better service
617 256 5494

More information about the Idna-update mailing list