LDH-label terminology

Frank Ellermann hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com
Sat Jul 26 04:08:17 CEST 2008

John C Klensin wrote:

> the UTF-8 bit doesn't seem to me to be something we need to
> discuss.  There are many ways to violate any protocol, this
> among them.

A security note that it could cause havoc when TLDs allow the
registration of octet labels (non-LDH) might help.  Otherwise
the bad guys could register say öko.example (UTF-8 octets)
and phish for traffic that should go to xn--ko-eka.example.

If some (maybe old) applications treat octets with a "let's
see what happens" strategy, they could arrive at the phisher.
Ditto for öko.example in legacy charsets.  

[Remotely related, I just found that a whois script handling
 cp 850 to UTF-8 as it should gets a windows-1252 ö for a
 cp-850 ö entered on the command line, arriving at UTF-8 ÷,
 and the DENIC whois informs me that ÷ko is no valid U-label.]
>> is there something about IDNA and SRV I've never heard of ?
> The fact that one can't have the protocol part(s) of an SRV
> FQDN be IDNs will, I suspect, come back to generate complaints
> at some point.  I think "you can't do that" is worth saying

Got it.  For the same example as above _xn--ko-eka.example is
no problem, but attempts to find the A-label for _öko are a
bad idea, xn--_ko-sna is very different from _xn--ko-eka, and
obviously not LDH, let alone a valid A-label.

> I think it is worth mentioning, even if not worth spending
> much energy one.

+1  Maybe add an example such as xn--_ko-sna vs. _xn--ko-eka.


More information about the Idna-update mailing list