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."

5 of 202 comments (clear)

  1. All nonascii domains resolve to 198.41.1.35 by MacroHard · · Score: 5, Informative


    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 .com or .net
    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. .org domains currently don't do this
    but since verisign still runs the actual DNS
    servers that run .org (it seems the 'new' .org
    registry just contracted the actual nameserver
    work right back to them!) maybe it won't be too
    long before we see this on .org as well.

    1. Re:All nonascii domains resolve to 198.41.1.35 by MacroHard · · Score: 5, Informative

      Also.. check this out:

      perl -e ' print "GET / HTTP/1.1\nHost: ".chr(160).".com\n\n"; '| nc www.idnnow.com 80

      It looks like they're planning to use framesets
      to keep the 'international' url in the url box while opening the actual site inside a frameset.

  2. Re:Adverts. by Jimmy_B · · Score: 5, Informative
    An erroneous lookup results in getting directed at an advert, instead of getting told you're in error, more like.
    Not exactly. It looks at the query and decides whether it thinks you want a non-English domain, and if so, directs you to a page to get an IE plugin which adds support for international URLs. A very dirty hack and not in any way part of the DNS standard, but not advertising.
  3. Re:God what a clusterfsck by Q+Who · · Score: 5, Informative

    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.

  4. Mixing layers by pslam · · Score: 5, Informative
    The real story, just like the IAB says, is that it's a hack, and it messes with the distinction between application and service.

    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.