Valid domain name registration for Unicode characters

Question

I'm trying to figure out what is valid for domain name registration, apparently some Unicode characters are translated weirdly while others do not at all.

This address:

http://xn--ippleman-dmj.com/

Translates to:

http://Nippleman.com/

and

http://xn--ggle-0nda.com/

should translate to:

http://gοοgle.com/

but for some reason the browser prevents it.

How is the format for these domains determined, and what is or isn't blocked by the browser?

http://xn--ippleman-dmj.com/ is a valid URL, while http://www.gοοgle.com is not. Yet Chrome only replaces the Unicode on the second URL.

score 2 · Answer 1 · answered Mar 09 '17 at 20:34

2

It appears that you're trying to do an IDN homograph attack. The Wikipedia page nicely explains what Chrome is doing to stop you.

answered Mar 09 '17 at 20:34

Calle Dybedahl

5,228
2
18
22

2

I'm really just trying how the attack works. According to this Chrome only allows character which are included in my preffered language character set, but I wasn't aware that the unicode 'N' was included with english – johnny 5 Mar 09 '17 at 20:39
@johnny5 : there is more looks alike character inside Unicode than you imagine. You can try it out here : https://www.irongeek.com/homoglyph-attack-generator.php – mootmoot May 16 '17 at 10:50
@mootmoot apparently the website will only show if it's not conflicting with major top level domains and is consistent character within a single language – johnny 5 May 16 '17 at 13:34

score 1 · Answer 2 · edited Oct 07 '21 at 11:32

First, to your question. The valid domain name must conform to RFC1035 regardless of browser, i.e. the whole domain name must not exceed 255 valid ASCII character (in octet) and it is case insensitive. Even IDN must comply with this standard. So to display IDN, RFC evolve come out with the Punycode 'xn--' conversion idea.

Then there is proof of concept of IDN homograph attack. Currently, Unicode.org update and maintain a confusable list. You can download current version TR39 and play around with it.

Previously, Chrome and firefox will translate domain name start with xn-- to correspondence Unicode found inside the browser font cache. If the browser can't find the font, it will display the raw 'xn--' punycode domain name.

This is known issues. Firefox even has manual option to enable/disable the Punycode domain name display. Google decide to remove the conversion post version 58+, while Firefox 53 will follow to make display Punycode as default.

I don't know whether Google will show Unicode(s) not inside TR39 or just remove the Punycode to Unicode conversion for all.

Valid domain name registration for Unicode characters

2 Answers2