Slashdot Mirror
VeriSign Changes DNS Servers: No ASCII Needed
An anonymous reader points to this story at The Register and this one (in French) at news.yahoo, writing "VeriSign has made changes to the root DNS so that they handle non-ascii names (for .com and .net).
Furthemore, an erroneous lookup results in getting a VeriSign IP, not an error message." An excerpt: "The IAB [Internet Architecture Board] feels that the system VeriSign had deployed for .com and .net contains significant DNS protocol errors, risks the further development of secure DNS, and confuses the resolution mechanisms of the DNS with application-based search systems."
You can see what they're talking about by
running this command:
[robert@alpaca robert]$ dig `perl -e 'print chr(160).".com";'` @A.GTLD-SERVERS.NET A
I tried to paste the output but the comment
system prevented me saying "too much junk" --
anyway;
It seems the article is right. Any
domain containing a non-ascii character is resolved to 198.41.1.35 which reverses to
www.idnnow.com. My guess is they need to do this
in order to do http redirects for their customers,
since nobody will have a broken nameserver able
to serve these 'international' domains for themselves.
but since verisign still runs the actual DNS
servers that run
registry just contracted the actual nameserver
work right back to them!) maybe it won't be too
long before we see this on
Verisign are now introducing propriatary, Internet Explorer only, DNS mechanisms much like the system I saw a couple of years ago where by using another company's DNS servers you could have domain.anything. Not only does this mean that anyone not using IE cann't access sites that use this 'special mechanism', but people with standard keyboards cann't access other 'language sites' without using character map - and even that does not contain japaneese/chineese characters IIRC.
Oh, may I also draw your attention to this part of the EULA:
11. Automatic Updates/No Maintenance.
VeriSign has the right, but not the obligation, to provide you periodically with automatic modifications, updates, upgrades, or error fixes for the Software using the transmission mechanism described above. This license does not entitle you to any support or maintenance for the Software.
Another browser 'add-on' that gives itself the right to install whatever the fuck it wants. Verisign should of been closed long ago.
It seems that nothing is sacred anymore. First you get everybody and his brother trying to introduce alternate root zones, then you get morons like NewNet that go a step further and require a browser plugin. Now Verisign does this.
I understand that having non-ascii characters in host/domain names would be desirable, however if they can't do it without breaking the DNS protocol, then they should get their ass right back to the R&D lab and try harder.
This issue is extensively discussed on D.J. Bernstein's page, here.
Before anyone complains about this:
Furthemore, an erroneous lookup results in getting a VeriSign IP, not an error message
Remember that if you use IE, you automatically get thrown to a Microsoft Web site if you go to a non-existant domain.
Although, bizarrely, I've been getting 500 Server Errors on every incorrect/non-existant domain I've been going to in the last few days. Could this be connected to the main story?
mogorific carpentry experiments
The I18N specification has been published by the IETF for a long time.
The point is to drive deployment of I18N through the existing root infrastructure. The IE plug in means that 90% of the browsers in use can use the international names today.
There is not much point in doing a Mozilla plug in. The Mozilla user base tends to upgrade pretty regularly and will pick up the internationalization code soon enough. That is meant to be the whole point of open source.
I can't wait to see the next O'Reilly book: "Verisign DNS vs BIND"
BIND also supports the international names.
The real story here is people who actually want to deploy stuff versus the foot draggers in ICANN and the IETF. The IETF has been dicking arround for at least six years on this issue and no closer to a resolution.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
In Finnish the problem is that there's no valid transliteration for å, ä, ö (we use the same characters). Actually, ae and oe are understood by some people but officially they aren't correct _at all_ in Finnish.
Why? Simply because we have also words that already use the combinations ae and oe; e.g. koe, aikaennätys, paeta...
The only de-facto correct way is just to drop the points from the alphabets. Hämeenkatu becomes Hameenkatu. There's however again the problem that the meaning of the word changes. Hämeenkatu is "Häme street" but Hameenkatu means "skirt street". :P
hapo
They type it just fine, because a Russian keyboard (like mine) has Russian letters written under the latin ones. The english layout is the main one, because AFAIK nobody made an OS that lets you give commands in Russian to it yet.
Removing the latin letters would be completely impossible. How would people deal with english command line programs? What would be 'explorer.exe' called in Windows? How would you type an english domain name?
In Windows, you use what's called an Imput Method Editor. (IME) For example, if you computer runs Japanese Windows XP, and you type into Notepad, you phonetically type out the character names on an English keyboard, and it maps the characters to the appropriate Kanji characters. Or if you just want to play with this in English, you can install some other languages and fonts... but don't hit Left-Shift and Left-Alt (as I once did) while in the password dialog... You can't type an English password in Arabic...
Because English keyboards have far fewer letters than asian alphabets, the Speech recognition and Handwriting IMEs are much more popular in these regions. It's also really weird how RTL/LTR directions are handled in Windows when you type multiple languages on the same line of text. English goes left to right, then Hebrew or Arabic which goes right to left, and if you go left, it goes right or left depending on where you are...
Here's an analogy: let's say you try to implement a method to display a pop-up search window when an executable file is not found. The obvious and clean way to do that is at the application level. When the application gets "file not found" from the filesystem, it arranges to pop up a search window. You'd only resort to alternate means if you can't modify existing applications.
Alternatively, you could implement a hideous hack where the file system instead opens a default executable. The application then never knows that the file wasn't found and executes it. It's achieved the same end, but it'll have a lot of side-effects. For a start, the application may not have wanted to execute it. It might even be trying to detect whether it exists. Other applications may not be expecting that behaviour and it'll break them. Another operating system may have that file system remotely accessed and end up running a non-native executable when it was looking for a native one. And years later, developers will still be working around this messed up behaviour because hacks are hard to get rid of once they are deployed at large.
DNS is not supposed to be a "lookup service for http transfers". Assuming that every lookup will be because of web browsing (by IE no less) is stupid. It's not even a good hack. As someone else who has replied to this article has pointed out it may not even cover the majority users. What about all those email servers bouncing email all over the place? What about all the peer-to-peer users? VeriSign would end up getting an enormous amount of non-web related connections hitting their "default IP".
VeriSign may be trying to get something out the door, but they could at least have implemented one of the preliminary specs (like simple UTF-8 encoding or mangling). Not a hack which only works for http transfers initiated specifically by IE, which breaks every other protocol and every other application.
or just hit the Option key: ø©ø......ß.........
To handle single-byte international character sets wouldn't have been that difficult
Except for the fact that there's no such thing; a single-byte character set can cover common usage for western Europe, or Greece, but not both, and there's no single-byte character set that can cover Japanese or Chinese.
But Unicode's two-byte characters make this fail badly - if the bytes happen to be aa, changing them to AA gets you an entirely unrelated character, and vice versa
They aren't just sticking in UTF-16 and hoping it works. aa is aa, not a double byte character.