Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
The Internet

VeriSign Changes DNS Servers: No ASCII Needed 214

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."
This discussion has been archived. No new comments can be posted.

VeriSign Changes DNS Servers: No ASCII Needed

Comments Filter:
  • Adverts. (Score:5, Insightful)

    by Big Mark ( 575945 ) on Sunday February 02, 2003 @08:58AM (#5209658)
    " an erroneous lookup results in getting a VeriSign IP, not an error message."
    An erroneous lookup results in getting directed at a n advert, instead of getting told you're in error, more like.

    -Mark
    • Re:Adverts. (Score:5, Funny)

      by Ed Avis ( 5917 ) <ed@membled.com> on Sunday February 02, 2003 @09:14AM (#5209688) Homepage
      Q. What do you call an error message which contains no useful information?

      A. An advertisement.
    • Re:Adverts. (Score:5, Informative)

      by Jimmy_B ( 129296 ) <jim.jimrandomh@org> on Sunday February 02, 2003 @09:23AM (#5209711) Homepage
      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.
      • Re:Adverts. (Score:5, Insightful)

        by gmuslera ( 3436 ) on Sunday February 02, 2003 @09:35AM (#5209737) Homepage Journal
        So now the only meaning for name resolving is to use IE, no other browsers, nor other protocols (i.e mail).

        Buying that kind of domains from Verisign is a very bad idea.

        I can't wait to see the next O'Reilly book: "Verisign DNS vs BIND"
        • Re:Adverts. (Score:5, Informative)

          by Zeinfeld ( 263942 ) on Sunday February 02, 2003 @10:17AM (#5209855) Homepage
          So now the only meaning for name resolving is to use IE, no other browsers, nor other protocols (i.e mail).

          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.

          • Mixing layers (Score:5, Informative)

            by pslam ( 97660 ) on Sunday February 02, 2003 @11:49AM (#5210145) Homepage Journal
            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.

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

              First off email is going to be afected very little because there won't be MX records in the zone and port 25 won't answer. So the end user will get back an error message. Life will go on without bad things happening. Peer to peer will be much the same.

              Secondly, in the real world IE won the browser wars, live with it. The end users voted with their mice.

              Ad hoc configurations to ease in infrastructure transitions have always taken place in the real world and the old farts of the IAB have mostly resisted them. They stuck their heads in the sand on the 32 bit address problem issuing notices about how dreadful NAT is. Fact is that without NAT the Internet would already be out of addresses. But don't expect the IAB to pro-actively investigate ways of making NAT really work well. They have decided not to bother with that until IPv6.

              • Re:Mixing layers (Score:3, Insightful)

                by pslam ( 97660 )
                First off email is going to be afected very little because there won't be MX records in the zone and port 25 won't answer. So the end user will get back an error message. Life will go on without bad things happening. Peer to peer will be much the same.

                Well there's three breakages already:

                • DNS says the domain is valid, but there's no MX records - which gives an error something like "No MX records for this domain/host" instead of "Domain/host doesn't exist".
                • DNS says the domain is valid, the emailer somehow tries the host directly (which you could configure it to do) and finds it's not responding. This gives the error "Host not responding" rather than "Host doesn't exist".
                • Peer-to-peer apps will try an address and it won't respond. This gets treated internally "Host not responding, try later" rather than "Host doesn't exist, delete from list".

                Secondly, in the real world IE won the browser wars, live with it. The end users voted with their mice.

                I think that at least one justice system has found this to be untrue - users didn't vote with their mouse, it was won by illegal means. I mostly agree with that ruling. The world is more than just Windows and IE - that's what a proper platform independent protocol is supposed to be all about.

                NAT is a hack. It also makes a mess of transparency and isn't 100% in the minority of cases. However, the minority of cases usually break completely. Even things like Quake broke originally until the protocol was modified and people put in special handling in their NAT stuff.

                But NAT isn't a fair analogy at all. People use NAT on their home networks, office networks, and other small LANs. Or simply as a poor man's firewall. We're not asking VeriSign (or a local cache) for information on how we should NAT. It's a local hack with the locals completely understanding that it's in there. VeriSign's DNS hack has global effect and can't be turned off.

                Unless, of course, you filter the response of "198.41.1.35" (what they return) to mean "host not found". But that would be a hack to fix another hack... which is usually how these poorly thought out "fixes" end up...

              • "Secondly, in the real world IE won the browser wars, live with it. The end users voted with their mice."
                Whether the users voted IE into its current stranglehold position is entirely debatable, especially considering recent legal findings. Regardless, even if IE is most popular now, consider that Netscape Navigator was most popular several years ago, and another browser may be most popular in the future.

                In any case, this whole argument is irrelevant to the matter at hand, because DNS does not belong exclusively to the web. Several other posters have already given good examples of this.
            • First of all, I am not opposed to answering non-ascii queries, but one has to realize that those queries might be rather limited in audience as those of us who rely on Ascii and standard US keyboards won't be abloe to type the addresses very well ;-)

              However on the subject of a default IP address--

              For example, if I am trying to reach my Jabber server, I would rather get a host not found error than a valid IP address that is not listening on that port-- it makes troubleshooting what is going wrong a whole lot easier. Again, with email, I would rather have my program give me a "Host not found" error than tell me than wait for the connection to time out, or be refused. Again, it leads to a very admin-hostile environment.

              What they are trying to do is put up those "This domain is not yet ownzed. Click here to buy it now!
          • The IETF has been dicking arround for at least six years on this issue and no closer to a resolution.

            Not true. The IETF solution was approved by the IESG some months ago for publication as a Proposed Standard.

            One of the four documents has recently been published as an RFC, and the remaining three are in the RFC Editor Queue pending final RFC Editor and authors' review (ie publication as RFC is iminent).

            draft-ietf-idn-idna-14 Internationalizing Domain Names in Applications (IDNA)

            RFC 3454 Preparation of Internationalized Strings ("stringprep")

            draft-ietf-idn-nameprep-11 Nameprep: A Stringprep Profile for Internationalized Domain Names

            draft-ietf-idn-punycode-03 Punycode: A Bootstring encoding of Unicode for IDNA
      • Here is an example (Score:2, Insightful)

        by cscx ( 541332 )
        Try going to http://www.épocas.com [pocas.com].

        Although you will have to cut/paste as Slashcode strips intl character from the URL (they killed all unicode and non- [A-za-z0-9] characers after all that crapflodding).
      • Re:Adverts. (Score:2, Interesting)

        by NoMaster ( 142776 )
        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.


        Bullshit. It's advertising IE. If it wasn't, it'd have either a) "plug ins" for *every* browsing engine out there (impossible - think Lynx, or a webspider...), or b) a totally server-side solution. It has neither - just an IE plugin...
  • The start of .... (Score:4, Interesting)

    by josh crawley ( 537561 ) on Sunday February 02, 2003 @08:59AM (#5209661)
    Perhaps this is the start of having he "other" dns'es take off. We all know how bad Verisign is with DNS (like slamming, overcharging, and in general cheating).

    Seems like they're pulling a Microsoft to me. But this time, the big guys are pulling a "WTF" on them.
    • Never ascribe to malice what can be more easily explained by stupidity.
    • Perhaps this is the start of having he "other" dns'es take off. We all know how bad Verisign is with DNS (like slamming, overcharging, and in general cheating).

      I think you're confusing Verisign Global Registry Services, who run the .com and .net registries with Network Solutions, a division of Verisign, Inc who are a registrar for .com and .net (amongst other domains).
    • Not enough. They won't be overthrown until the big guys pull an "OMG WTF".
  • by KDan ( 90353 ) on Sunday February 02, 2003 @09:00AM (#5209663) Homepage
    We all know we can trust corporations to do the right thing. I'm sure they'll sort it out and it will all be alright. Anyone who says they're trying to screw everyone to get some sort of competitive advantage by breaking well-established protocols is an unpatriotic leftist and should be arrested under the terms of the PATRIOT act and put away to let the good people get on with God's work.

    Daniel
  • by cyberlotnet ( 182742 ) on Sunday February 02, 2003 @09:14AM (#5209687) Homepage Journal
    Small town in Florida overnight adopted a new set of street signs they feel create a friendlier driving enviroment, and allow the non-usa population to drive safer.

    Within 24 hours the whole city was gridlocked due to wrecks from confused and misguided drivers who didn't understand what was going on...

    Yes its a Dramatic example, but valid one of what happens when things are changed without properly informing the public, Just taking things into your own hands.

    This change is not going to serve to improve the internet but instead confuse people.
  • by Spazzz ( 577014 ) on Sunday February 02, 2003 @09:16AM (#5209694)
    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.

    • by Q Who ( 588741 ) on Sunday February 02, 2003 @09:53AM (#5209784)

      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 [cr.yp.to].

      • This issue is extensively discussed on D.J. Bernstein's page, here [cr.yp.to].

        Actually, Dan Bernstein is discussing a different issue.

        He is arguing that his own solution (IDNC3) is superior to the solution that the IETF has adopted (IDNA).

        This has nothing to go with whether Verisign GRS should be allowed to break the DNS to promote internationalized domain names.
    • The mass additions of TLDs, the hacking up of DNS to fix short-term problems...the Internet's changed a lot, and the new target audience is the web-only, Windows-using, Internet Explorerite. Other uses of the Internet are secondary at best, and need not be catered to.

      Fortunately, as long as the backbone ISPs don't screw around too much, we can still use alternate DNS roots (like OpenDNS [unrated.net]) that hopefully make better decisions.

      Seems like any time a company gets big, it gets mean, evil, and totally unable to make the best technical decision.

      I hope and pray that Red Hat never ends up there. So far, so good...
    • 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.

      The DNS protocol has been extended to support non-ascii characters years ago. There is no real disagreement over the general approach, you simply use an approach similar to Base64 encoding on the domain name with a prefix of '--' which is safe because leading dashes are not permitted in DNS names, although the servers are required to resolve them. [i-d-n.net]

      If the IAB were not almost exclusively American academics this whole spec would have been finished four years ago. Instead they are happy to discuss any issue for years so long as there is no danger of a resolution.

      It is particularly ironic that they are waffling about DNSSEC since it is the timidity and ineffectiveness of the IAB and IESG that has caused that spec to be delayed so long. It has taken three years for them to accept that the original DNSSEC spec was broken.

      Internationalization and DNSSEC have been going on for ten years. The IAB seem quite content for them to go on for another ten years.

      So don't get too excited by IPV6. It does not look likely that anyone is going to kick the IAB and IESG into action.

  • by MacroHard ( 107619 ) on Sunday February 02, 2003 @09:17AM (#5209698) Homepage

    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.
    • by MacroHard ( 107619 ) on Sunday February 02, 2003 @09:28AM (#5209724) Homepage
      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.

    • As near as I can tell by reading the Verisign documentation, they're doing this to redirect web page requests using a browser plugin, but they're not doing anything about email - so your email client can't resolve username@ChineseServerName.com, and even if it did, 198.41.1.35 probably won't accept it. (And if they _did_ accept it, they'd be the World's Largest Open SMTP Relay, which has its own entertainment value.)

      Spectacularly broken, but fortunately it only works for people who use Verisign's IE plugin, which makes it much harder to sell these domain names.

  • Big assumption (Score:5, Insightful)

    by deepchasm ( 522082 ) on Sunday February 02, 2003 @09:17AM (#5209699)

    To spur uptake of i-Nav, the company configured the DNS servers for .com and .net to reply to some erroneous domain lookups with the IP address of a VeriSign web site, as opposed to an error message.
    ...
    The system guesses that the user is looking for an internationalized domain name (IDN) and presents them with a way to access it.

    Doesn't that assume that users only look up the names of webservers?

    What happens when a user mistypes a URL and the VeriSign system merrily sends them a verisign IP, but they are using "ssh", or an IMAP mail client, or any other service that the verisign server is unlikely to be running?

    The user receives unhelpful "Connection refused" messages, instead of being prompted to correct their typo by a "Can't find..." message.

    • Re:Big assumption (Score:3, Insightful)

      by 0x0d0a ( 568518 )
      What happens when a user mistypes a URL and the VeriSign system merrily sends them a verisign IP, but they are using "ssh", or an IMAP mail client, or any other service that the verisign server is unlikely to be running?

      Yes, techies get screwed over here. However, the vast masses know of no program but the web browser (and, for the time being, the email client). And where the masses are, there is also the money, and hence VeriSign.
    • Email fails (Score:5, Insightful)

      by billstewart ( 78916 ) on Sunday February 02, 2003 @11:02AM (#5209992) Journal
      At least the way I read the document, it does only support web servers, which means that SMTP email fails, as well as all the other services. So you can have http://MyChineseServerName.com but not postmaster@MyChineseServerName.com, which is spectacularly broken.
    • Doesn't that assume that users only look up the names of webservers?

      Yes. I believe they said an e-mail protocol will work too, I don't remember which one.

      The user receives unhelpful "Connection refused" messages, instead of being prompted to correct their typo by a "Can't find..." message.

      They also assume that everyone runs Internet Explorer, which by default simply displays the unhelpful "The page could not be displayed" or redirects to MSN's search engine. Being redirected to a Verisign plugin page won't seem too strange to these users.
  • Great.. not really (Score:5, Interesting)

    by k98sven ( 324383 ) on Sunday February 02, 2003 @09:28AM (#5209725) Journal
    Ok.. now I have full understanding why people want
    DNS adresses in their own language.

    For instance, I live in Sweden, where the township of Mönsterås [monsteras.se] has to use the
    URL "monsteras", which happens to mean "monster-carcass"..

    But on the other hand, a big point of the internet is that it's supposed to be international,
    how are for instance americans supposed to type unique swedish characters to find the web site?

    Not to mention chinese and japanese sites..
    • But on the other hand, a big point of the internet is that it's supposed to be international, how are for instance americans supposed to type unique swedish characters to find the web site?

      How are for instance Russians supposed to type latin characters to find an American web site?

      (I suppose that they have keyboards that allow the user to type ASCII characters as well as cyrillic ones, but is that because they want to or because they have to?)

      • by vadim_t ( 324782 )
        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?
    • by billstewart ( 78916 ) on Sunday February 02, 2003 @11:33AM (#5210094) Journal
      We've been dealing with internationalization for more than a decade - applications either support UTF8 or Unicode or CP850 or some similar standard for handling them, or else they don't, and most operating systems provide some hook for inputting them. (That won't help 7-bit-character implementations of vi, but too bad :-) Windows has their Character Map application, so I can go get an Å and a å and cut&paste them into my document.

      The real problem is that the DNS standards say that capital and lower-case letters are equivalent, so example.com and EXAMPLE.COM and ExAmPlE.com all get the same result, and DNS lookups translate everything to the same case before looking it up. To handle single-byte international character sets wouldn't have been that difficult - either define a mapping from uppercase to lowercase, or else require that users translate all of those things by hand. 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, but the DNS standards force this to be done, because they don't know about double-byte characters. The most serious problems this causes are that only about 1/4 of the characters are valid in DNS, which makes far too many words unavailable - it's bad enough that aa and AA and aA and Aa all become aa, but the chances of a 10-letter word being available are way too low (and think about the trademark problems of coke.com vs. COKE.com vs. CoKe.com etc.) Other problems include the chance that you can't display reverse DNS names properly (because the database has the wrong case in it) or alternatively that the canonical forward and reverse DNS names are different, which is annoying enough for 7-bit character sets where only the case is different, but when the letters change entirely, it's really bad.

      • 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.
        • When I used "aa", "AA", etc., I wasn't referring to the Danish AA = Å (Duhh - I should have thought of that problem; I've been to Århus/Aarhus and Aalborg/Ålborg); I was referring to two bytes which could be interpreted as two single-byte characters or one double-byte character, demonstrating that this can lead you to do the wrong thing. I probably should have used xy/XY/Xy/xY or some U+4-digits instead.
      • Single-byte characters suck, to put it mildly. Try using Japanese, French, Russian, and English at once with single-byte characters. (That's what I do - but not with single-byte).

        With proper implementation, there is no upcase problem; your string ops library uses a Unicode upcase table that has matchings for all uppercase/lowercase character pairs in Unicode.
    • But on the other hand, a big point of the internet is that it's supposed to be international,
      how are for instance americans supposed to type unique swedish characters to find the web site?


      If your audience is international, then you chose a domain name that they all can type. If your webpage is only in Armenian, it doesn't really matter if your domain name is too; if someone else wants to read it, they can cut and paste the link in.
    • I guess we go back to the old reliable way of doing things... maintaining our own /etc/hosts file.

      I understand the need/desire for international character support, but since I can't read Kanji... it doesn't really matter if I get the correct UTF-8 name, or an ASCII mangling of it... it will won't mean anything to me.

      What we really need is not character representations, but rather translations. If we had "root" servers which would respond to language-specific lookup requests, we could ask for the name in whatever character set we needed.

      In a prior example, Mönsterås might come up as Mönsterås in swedish, but in english it would resolve to whatever that actually translates to (sorry, don't have a lookup handy), and in ASCII it would become "Monsteras".

      I get tons of spam email on one of my accounts, and I asked the postmaster (yahoo, BTW) why they didn't just filter out all messages where the sender or subject didn't use ASCII from my delivery? *I* can't read it, so either it should be translated or ignored. BTW: Their anti-spam filter can't handle non-ascii characters, and thus defaults to delivery... joy.
  • by Neophytus ( 642863 ) on Sunday February 02, 2003 @09:50AM (#5209777)
    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.
    • but people with standard keyboards cann't access other 'language sites' without using character map

      Mac OS makes it really easy to type most accented characters in the standard 8-bit ASCII character set with a normal US keyboard, in addition to providing a character map (Key Caps). So, I can easily type domain names in languages like Spanish, German, etc. That doesn't help me with languages that use other character sets like Russian, Japanese, etc. but I can't read those languages anyway, and if I could, I'm sure I'd figure out a way to type them.
  • 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?
    • by yggdrazil ( 261592 ) on Sunday February 02, 2003 @10:55AM (#5209974)
      Remember that if you use IE, you automatically get thrown to a Microsoft Web site if you go to a non-existant domain.

      But Verisign change the behaviour of the underlying DNS system, no matter which portnumber, application or OS you use. Yet they only provide a MSIE for windows plugin for IDN domain names.

      The internet is not all web, and the changes they made can be bad for applications like mail. The changes they made to DNS behaviour is not a good thing.

      Verisign is evil. This is yet another proof. Take the .com and .net registry away from them ASAP.
    • Yeah, that's really annoying. Is it possible to change it to just say 'Dns Error' or 'Connection Refused' ?

      When you get the stupid IE error page you dont know if it was a dns error or the side was down, unless you look at the statusbar in time and see 'dnserror.shdoc.navdll' or whatever
  • by jazdc ( 217401 ) <jon@k a r lfeldt.net> on Sunday February 02, 2003 @10:15AM (#5209847) Homepage
    I hear of all these proprietary ways to handle non-ascii domain names and constantly fail to see why people cannot wait for the IETF IDN Working Group [ietf.org] to finish their work.
  • by Temporal ( 96070 ) on Sunday February 02, 2003 @10:16AM (#5209853) Journal
    Furthemore, an erroneous lookup results in getting a VeriSign IP, not an error message.

    So, does this mean I will be able to type in "http://shittyassregistrar.com" and get VeriSign?
  • Selling people domains that are non-standard by using a different DNS... http://alternic.org/ . They've called it "Enhanced DNS". I'm pretty sure hardly anyone actually ever used this...at least no sites of any significance. I'm guessing verisign will have a little more luck, but still not much, as it is a bad business model trying to sell things that require a plugin for the general public... I can just see businesses going out and buying domains that people can't even get to, because they don't have the plugin, and won't get it.

    The real significance of the AlterNic site is that the guy that founded it back in the 80's or so ended up in prison for a while, then when he got out, he couldn't use a computer for a signifcant number of years by court order because back when network solutions ran the whole show for domain names, he hacked there DNS to route internic.net to his site, and also hacked their DNS to include his custom top level domains such as .sex.

    As far as the license agreement giving verisign the right, but not obligation to automatically update the software without asking first...can you say spyware? Does CometCursor ring a bell?

    • No, actually, it isn't. IDN is an internet standard for transcriping international characters in DNS.

      There is nothing wrong with the standard here, the main problem is that Verisign destroys the consistency of the DNS system, just for the sake of advertising one of their plugins for one browser for one OS.

      Support for IDN should be built into DNS resolvers in applications or operating systems, not being used for messing up DNS consistency.

      Microsoft could patch MSIE to support IDNs quite quickly, and then there would be no need for Verisign's stupid dirty hack.
  • /* Begin Rant */ I'm curious.

    Who the hell actually types in domain names anymore. My first stop on the net is usually google. Why? There is no way of telling where a domain name actually goes.

    I work at the Franklin Institute. Our domain fi.edu. Our customers who type in FranklinInstitute.com get sent to one of those DNS parking sites. (We do have FranklinInstitute.org and FranklinInstitute.net.)

    Of course, there is also a Franklin Institute in Boston. Are we then supposed to be FranklinInsituteOfPhiladelpbia and they be FranklinInstituteOfBoston. (Hmm, or franklininsitute.phl.pa.us and franklinintitute.boston.ma.us.)

    And, the original name for our organization was The Franklin Institute for the Promotion of the Mechanical Arts, that exceeds 32 characters. We could use the acronmy FIPMA, but most of the folks that visit don't know the PMA part.

    Just think of WhiteHouse.com or GMSucks.com.

    Granted, it is really nice to see www.petesfamouspizza.com on the pizza joint next door. But at some point you end up writing it down. After a while it will end up being just like a damn phone number, making no sense at all.

    /* End Rant */

    • I type domain names all the time...if you have a good memory, and type at least decently fast, it's definately faster than using a search engine...
    • Blockquoth the poster:

      Who the hell actually types in domain names anymore. My first stop on the net is usually google. Why? There is no way of telling where a domain name actually goes.

      Wow. It must be interesting to cruise the Net and never return to a site you've already visited. I don't use domain names for search purposes. But once I've found slashdot.org or bn.com or thinkgeek.com, yes, indeed, I use those to jump right to the page I want without having to pass through a search engine. I like google -- which, of course, I get to by "google.com" -- but I don't need to visit them every time I want to buy a book, for example.
    • The phone number thing isn't off-base. The most important public use for typing in hostnames is as the prefix of a web-address you've gotten off of printed materials, like a billboard or advertising circular or bibliography.

      Yes, in that case, it is functioning mostly like a phone number. The addition of more length and more characters only makes it somewhat easier to remember. (Pizza stores will almost always have the "pizza" substring in their names. No analysis of a list of phone numbers can give you the slightest clue where they go, without dialing them up)
  • by axxackall ( 579006 ) on Sunday February 02, 2003 @11:27AM (#5210074) Homepage Journal
    Russian alphabyte (cyrillic) can be presented in one of ~20 charsets, 5 of them are still in active use:
    • "MSDOS" cp866;
    • "Windows" 1251;
    • "Unix" KOI8
    • "Mac" (???)
    • ISO 8859-5
    The Russian goverment offially approves only ISO 8859-5, but most of people just ignore that charset and noone (besides the govt) use it.

    All charsets are different one from each other, mainly (and in most cases) by different positioning the same russian letter in different places of the "code page". That requires to have separate font modification for each charset you want to use (yes, it's true, I have 5 areals, 5 couriers etc); alternatively it requires to decode the document on the fly from the doc's charset to the charset of currently chosen font (some programs can do it, others cannot).

    Now, when I see a domain name with some non-ascii letters, and I assume it is in Russian language, which charset should I choose in order to display it properly and to be able to read it? The domain name itslef doesn't keep such information. Does DNS keep it? I don't think so.

    Is one russian charset has been chosen over others? If so, who dare to decide it and to be critisized by users of other 4 charsets?

    Personally I think that due to such problems in some languages (Chineese also? India as well?) all non-ascii strings should be used in internet only along with some identifiers of the charset. For example, web pages and email messages use such (often - in inconsistent way). Also, XML can assign a charset per sub-tree. But how about domain names? I think non-ascii usage should be limited to documents, while all system identifiers (including domain names) must be ASCII. Period.

    • Is one russian charset has been chosen over others?

      Yes. An encoding of Unicode is used, because that can handle every language in the world and needs no language tagging.
    • Your conclusion (use ASCII and stop moaning) is correct, but your reasoning is wrong.

      The IDN system is for international domain names, not just Russian domain names, a moment's thought will reveal to you that this means it must be based on Unicode. So it is /implicit/ that they are encoded in a certain way and the IDN software sorts all this out for you just as it would with Arabic or Chinese.

      The fact that some obsolete software only works in KOI8, or whatever is irrelevant, none of that software will work with IDN without hefty modification.

      Why should we "just" use ASCII for Internet DNS?

      Actually that's the wrong question. We don't use ASCII, we use a very restricted subset of ASCII. The DNS infrastructure is quite capable of permitting domains called e.g. _;_.~ but they aren't human readable, so all but the most easily recognised ASCII characters were simply banned.

      [Yup, banned. Most Unix resolvers just fail requests for domains like this without ever going to the network]

      If we don't permit case-sensitive & don't allow wacky ASCII characters, why should we allow all sixty or so variations on the character 'a' that are recognised by Unicode? Just to make Verisign more money?

      That's what this is really about BTW, Verisign needs to invent more "variations" of coke.com that can be registered to protect them from "pirates" so that Verisign shareholders can see "growth". Ugh.
      • If we don't permit case-sensitive & don't allow wacky ASCII characters, why should we allow all sixty or so variations on the character 'a' that are recognised by Unicode?

        So that people can use names that are meaningful to them, instead of having to mangle the name of their organization into a very limited foreign character set? 0/O, and l/I/1 are allowed in ASCII (both paypal and paypai), so it's not like confusion didn't already potentially exist.
      • I have a dumb question. If domain names can be Unicode how will such characters be represented in an HTTP URL. According to RFC 2396 there is no defined way to represent anything but US-ASCII in an HTTP URL. Unless there is a way to negotiate an alternative character set escaping would have to be used like this UTF-8 escaped example http://www.c%d0%beke.com [cke.com]. Or you could UCS-2BE escape it like: http://www.c%043eke.com [c3eke.com]. What does your browser see when you mouse over these? In IE I get "http://www.cke.com" and "http://www.c3eke.com".
      • Your post gives me an idea: why not just use UTF-8 for domain names?

        This wouldn't require any bullshit approval and crap, no existing DNS systems would break because they currently reject requests with non-ascii utf-8 characters, the only implementation barrier would be waiting for any apps that want to support it to encode their URLs with a UTF-8 library.

  • by roderickm ( 6912 ) on Sunday February 02, 2003 @11:52AM (#5210154)
    Though supporting international, non-English characters in domain names is a Good Thing, Verisign makes some arrogant assumptions in their broken implementation:

    a) DNS is only used for HTTP (web). By pointing failed lookups at idnnow.com (198.41.1.35) to see the plugin website, Verisign breaks all other services' proper "not found/unresolved/connection refused" response. "Not found" is a more helpful answer than an erroneous one.

    b) The universal web platform is Internet Explorer on Windows. First, it's not just the browser that needs to be patched -- all internet hosts will need updated DNS resolvers to handle the binary, non-ASCII names. Even if (a) were true above, there are many other browsers and platforms than IE/Win. And they're using their monopoly power to leverage proprietary software into users browsers.

    c) Everybody speaks English. It's time that we as Americans realize that we are not alone in this world. Pompous assumptions like these foster hatred of the U.S. Yes, Verisign offers eight other translations of idnnow.com, but combined with (a) and (b) above, it's just another broken way that an American Megacorp tells the world How It's Gonna Be.

    d) Verisign runs the internet. Okay, so this one's almost true, because they have a stranglehold on some of the internet's most intimate infrastructure... but my big beef with Verisign is that they do not approach their responsibilities with an attitude of service. Nameless servants of the public all over the globe quietly keep the internet up and running, but Verisign's public decisions infer that theirs is the only policy that matters.

    So, can we just mod Verision as "arrogant?"

    roderickm
  • by myrashka ( 452794 ) on Sunday February 02, 2003 @12:03PM (#5210195)
    I can see it now (taking a previous post accurately pointing out that Web browsers are not the sole users of DNS):

    [on a *nix type machine]

    % telnet iwanttohackdns.com

    Welcome to the Verisign unsecured "no one ever uses telnet" root server configuration system.

    Command? Delete DNS
    Are you sure (Y/N)? Y
    DNS Purged.
    Command? Quit

    Goodbye.

    % telnet myserver.mydomain.com

    Welcome to the Verisign unsecured "no one ever uses telnet" root server configuration system.

    Command? Quit

    Goodbye.

  • This is a bad idea (Score:5, Insightful)

    by Minna Kirai ( 624281 ) on Sunday February 02, 2003 @12:29PM (#5210310)
    Not only is the implementation a painful, incomplete hack, but even if the DNS protocol were cleanly extended to handle non-ASCII names, it would still be wrong.

    DNS names are a very low level component of the internet- they layer just above IP addresses, and provide a persistent way to find an IP host. Today, with hostnames in ASCII, any person smart enough to use a computer can write down a name off a printout, and type it in later. Everybody, regardless of speaking Spanish, Korean, Russian, Chinese, Swedish, or Hindi, can basically recognize and repeat the ASCII alphabet. Not only is it the shortest, simplest character set the world has to offer, but most internet users are already getting some training in it.

    Sure, with a Russian character map it might not be completely convenient to punch in an ASCII name- but with a little effort, anyone can do it. But if DNS hostnames start to come in Kanji or Hangul, it will be inestimably worse.

    It's trivial to print the whole English alphabet on a single page, and with a rudimentary pronounciation-guide too. But Chinese contains more than 10k characters, many so rare that just 10% of the Chinese population can reproduce them. How'd you like that as the hostname that's been DNSing you? Try reading it over the phone to the upstream sysadmin, maybe?

    The system of DNS hostnames is most useful when it uses a least-common-denomintator character set which every literate human can reasonably read, input, and maybe even pronounce. It's mostly like that today, and keeping it ASCII is the way to maintain it.

    Naturally, non-English speakers will want to be able to publish server addresses in their own language. But systems to perform these lookups should be created separately from DNS- either on top of it (resolving to DNS hostnames), or alongside (resolving to IP addresses). That way, major international servers will tend to be dual-named: local language for primary users, ASCII-DNSname for everyone else.

    The system libraries that software uses to lookup names can be extended to optionally check alternative-charset nameservers before going to the DNS ones, depending on the user's i8n settings.

    That solution would be drastically more complete, and less disruptive, than what is presented in the article.
    • But Chinese contains more than 10k characters, many so rare that just 10% of the Chinese population can reproduce them.

      You're off by at least one order of magnitude on the first figure, maybe 2, and the second figure (percentage of the Chinese population who can reproduce all valid charactes in the Chinese writing system) is almost by definition 0%. Not that this undercuts your argument.

      Actually, the best thing to do would be to create a new unification system for alphabetic scripts, matching the Han unification for Chinese-based scripts, just for use with URLs. That way Cyrillic o, omicron, and Latin o would be the same DNS codepoint. Frankly, if you're going to look at a website with a Chinese URL, you're going to know Chinese anyway.

      • You're off by at least one order of magnitude on the first figure, maybe 2

        Writing 10000 instead of 13000 [ocrat.com] is not what I'd call an "order of magnitude".
        • Whoops, a better link [lechinois.com] is gives the number as between 6500 and 46964, depending on how obsessive you want to be. Still inside an OOM.

          • The actual number is more on the order of 100,000, the Kanxi is not exhausitive (as you should be able to guess from your link, given the fact that it was published in the early 18th century. Look at the Unicode FAQ at http://www.unicode.org/unicode/faq/han_cjk.html . Unicode also is not exhausitive.
      • Minna Kirai wrote: "But Chinese contains more than 10k characters, many so rare that just 10% of the Chinese population can reproduce them."

        kalidasa wrote: "the second figure (percentage of the Chinese population who can reproduce all valid charactes in the Chinese writing system) is almost by definition 0%"

        That's a completely different statement. Minna said that there exist characters that only 10% of the population can reproduce. You said no, there are very few, if any, people who can reproduce every character. Both statements could be true, since Minna has not claimed any one person is in all of those 10%s.

        You should pay a little more attention to what people are saying before claiming they are wrong.

        • I parsed it diffferently, as "many are so rare that just 10% of the Chinese population can reproduce them (meaning the set)", while you are parsing it as "many are so rare that for some of them, just 10% of the Chinese population can reproduce them (there are individual characters that only 10% of the population can reproduce). Anyway, it's probably still wrong, as there are many archaic characters that are understood only by scholars of Chinese literature, whom I would beg to suggest do not make up 10% of the population.
      • Actually, the best thing to do would be to create a new unification system for alphabetic scripts, matching the Han unification for Chinese-based scripts, just for use with URLs.

        Actually, they do use the same unification system for alphabet scripts as they do for the Chinese script.

        That way Cyrillic o, omicron, and Latin o would be the same DNS codepoint

        What about a and , or and Y? And what about the Armenian ?

      • > Frankly, if you're going to look at a website with
        > a Chinese URL, you're going to know Chinese anyway.

        Not if you're a browser developer attempting to reproduce a bug someone filed...
    • Not only is it the shortest, simplest character set the world has to offer,

      Not. 0 and 1 is shorter and simpler, as is the Latin alphabet.

      But if DNS hostnames start to come in Kanji or Hangul, it will be inestimably worse.

      In this day and age, most of us have the ability to cut and paste. Using a kanji or a hangul domain name is a sign your targeted audience has no problem with kanji or hangul.

      It's trivial to print the whole English alphabet on a single page, and with a rudimentary pronounciation-guide too.

      Not really a useful one, considering the odd digraphs and the fact that DNS names aren't necessarily English.

      How'd you like that as the hostname that's been DNSing you? Try reading it over the phone to the upstream sysadmin, maybe?

      How do you pronounce ztz01588a.xxqcji.org? That's a valid domain name. Try reading the IP address.

      every literate human can reasonably read, input, and maybe even pronounce.

      Knowledge of the English alphabet is not required for literacy.
      • Not. 0 and 1 is shorter and simpler,

        The definition of simplicity, as percieved by humans, is a complex thing. It includes not just the axis you chose (number of characters), but also the information content per-character, ease of distinguishing between characters, and most subjective of all, ease of acquiring training about the characters. The English alphabet scores high on all scales.

        More specifically, humans can easily remember series of about 8 characters. Using binary you'd only have 256 values represented. Decimal gives you 10 million. Decimal + alphabet is 300,000 million. Start adding many more characters, and you're exceeding people's abilities to tell them apart.

        How do you pronounce ztz01588a.xxqcji.org?

        Zee tee zee oh five ate ate ay dot ecks ecks que see jay eye dot oh are gee.

        It wasn't easy, but in a minute of effort anyone could do it. Now tell me what percentage of the words on this page [slashdot.jp] you can pronounce?

        Try reading the IP address.

        IP addresses change. For instance if I wanted to inform a website operator to remove my copyrighted materials, per DMCA. If there's no comprehensible hostname, my lawyers won't be able to tell one Asian warez site from another!

        The argument to "just use IP addresses" can be applied against the whole DNS system.
        • The English alphabet scores high on all scales.

          But not necessarily highest. The Russian alphabet scores higher - most case pairs in Russian look the same, unlike English, and has a few more characters, but not too many.

          IP addresses change.

          So do domain names; many domain names are linked to IP addresses. (I was once x8b4e53cd.dhcp.okstate.edu.)

          my lawyers won't be able to tell one Asian warez site from another!

          If you're sueing Asian warez sites, you better get an Asian lawyer, or he's going to have a hard time in court!
          • But not necessarily highest. The Russian alphabet scores higher

            The very-important criteria of ease of learning is composed of 2 parts: inherent simplicity, and existing skilled base. Existing skilled persons both reduces the total amount of learning needed, and provides new learners with educational resources.

            That's where the Roman alphabet really dominates. It is the primary component of the native character sets of all Americans (North & South), most Europeans, many Indians and Africans, and is recognized and used by the computer-using classes of China, Korea, Japan and Singapore.

            (Did I forget Australia? Oh well, won't bother to go search for what they use)

  • Could the idea of supporting extra characters make it a little more time consuming to block spammers at your SMTP gateway. Imagine entering many name like "ispåmedyou.com" in your anti-relay database.
  • by mattdm ( 1931 ) on Sunday February 02, 2003 @02:10PM (#5210748) Homepage
    Sure, rnicrosoft.com [rnicrosoft.com] is kinda funny, but just wait until international characters make it possible to do that or better with *any* name....
  • by Kiwi ( 5214 ) on Sunday February 02, 2003 @03:21PM (#5211057) Homepage Journal
    Verisign is doing the right thing here.

    Let me repeat that:

    Verisign is doing the right thing here.

    Of course, they are doing the right thing (IDNs) for the wrong reasons (greed), but that doesn't mean they aren't doing the right thing.

    The fact of the matter is this: People want accents in domain names. People want domain names which respect their language and their culture. We live in a world with over 6,000 languages and cultures; many of those languages have writing systems which do not have English letters.

    It is not fair to force those people to always write in English-looking web addresses because the people who designed the internet designed it in a time when computers were not capable of displaying any language besides English.

    Obviously, we are not going to see a lot of those people here on Slashdot; they don't know English well enough to comment here without getting flames from the grammer nazis here.

    First of all, the idea of doing international domain names is not proprietary. There is a [ietf.org] comittee [i-d-n.net] which is looking in to getting an IDN RFC. The problem? RFCs take far too long to get written. I have been looking at the IETF talking about getting some kind of IDN standard made, and they have been dragging their feet for years on this issue.

    Keep in mind that the IETF did not come out with RFC1034 and RFC1035 until years after DNS servers were in place and were being used.

    It is about time Verisign, Microsoft, or someone with similiar influence forced the issue. We need an IDN standard. We need an internet which respects other languages better. We need an internet which does not constantly remind people that their language is considered by some to be second fiddle to English every time they type in a URL.

    So, with this Verisign hack, maybe people will actually download an IE plugin which implements one of the IDN ideas. And maybe we will finally have an IDN standard.

    Most IDN standards use some form of ACE, so people will be able to reply to emails sent from people with IDN domains. Instead of quiero@más.com, they will type in something like quiero@bq-abw6c4y.com to reply to someone from that domain.

    I would like to applaud Verisign for having the guts to make IDN a reality.

    Now, time to figure out how this plugin works so I can have my DNS server [maradns.org] automatically change domain names with UTF-8 in them in to ACE compatible IDNs.

    - Sam

  • Which word pair is most like the following:
    VeriSign::DNS

    a) Rambus::JEDEC
    b) Qualcomm::CDMA
    c) Enron::PUC
    d) SBC::HTML
    e) SCO::UNIX
    f) Microsoft::GNU
    g) Unisys::GIF
    h) Forgent Networks:JPEG
    i) MPAA::DVD
    j) RIAA::MP3
    k) Corporate Greed::Standards

    Times up, turn your test over, put your pencils down. There will be an essay...
  • by KidSock ( 150684 ) on Sunday February 02, 2003 @06:12PM (#5211964)
    Does this mean the domain names are ISO-8859-1 or can they be Uniocde? If they are Unicode, how do you represent it in an HTTP URL? And do browsers support such a thing?
  • by infolib ( 618234 ) on Sunday February 02, 2003 @06:23PM (#5212014)
    There is a patent [delphion.com] by walid.com on substituting national characters with ASCII in DNS systems. (So ærø.dk would be looked up as aro.dk etc.) IETF tried to build a standard but were told [ietf.org] (bottom mail) that they could use the patent based on "reciprocity" meaning that companies using internationalised domain names would grant walid license to all their patents.
  • This angers me (Score:4, Insightful)

    by Todd Knarr ( 15451 ) on Sunday February 02, 2003 @06:59PM (#5212162) Homepage

    I'm sorry, but Verisign should have their status as both registrar and root nameserver operator revoked after this. We depend on being able to tell when a DNS name doesn't exist. The master nameservers for two of the biggest TLDs should never, I repeat never, lie to us about that by returning a record when no such record exists for the name queried.

    What Verisign's doing is the equivalent of the phone company responding to a 411 request for a name that isn't in the phone listings not with "I'm sorry, we don't have a listing for that name." but with "The number is .".

  • There has been quite a lot of discussion of this stuff on various W3C [w3.org] lists, especially over issues as the fact that hex encoding of UTF-8 is case insensitive and URIs are case sensitive...

    See the Internationalized Resource Identifiers (IRIs) [w3.org] page for more info.

Anyone can make an omelet with eggs. The trick is to make one with none.

Working...