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

33 of 202 comments (clear)

  1. Adverts. by Big+Mark · · Score: 4, Insightful
    " 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
    1. Re:Adverts. by Ed+Avis · · Score: 4, Funny

      Q. What do you call an error message which contains no useful information?

      A. An advertisement.

      --
      -- Ed Avis ed@membled.com
    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:Adverts. by gmuslera · · Score: 4, Insightful

      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"

    4. Re:Adverts. by Zeinfeld · · Score: 4, Informative
      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.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
  2. The start of .... by josh+crawley · · Score: 3, Interesting

    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.

  3. Oh, but that's ok by KDan · · Score: 5, Funny

    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

    --
    Carpe Diem
  4. On News at 11, Small town in turmoil by cyberlotnet · · Score: 5, Interesting

    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.

  5. God what a clusterfsck by Spazzz · · Score: 4, Insightful

    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.

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

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

  7. Big assumption by deepchasm · · Score: 5, Insightful

    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.

    1. Re:Big assumption by The+Smith · · Score: 4, Insightful
      How the heck do you mistype an ASCII URL so you get non-ASCII characters? Do you have some kind of funky keyboard that produces non-ASCII characters? I'd love to see such a fucked up keyboard. Geez, if you want to use non-standard keyboard setups or weird ass keyboards then deal with it. For those of us with standard ASCII keyboards there IS NO PROBLEM. You'd have to go out of your way to type these characters.
      £
    2. Re:Big assumption by Phroggy · · Score: 3, Insightful

      How the heck do you mistype an ASCII URL so you get non-ASCII characters? Do you have some kind of funky keyboard that produces non-ASCII characters? I'd love to see such a fucked up keyboard. Geez, if you want to use non-standard keyboard setups or weird ass keyboards then deal with it. For those of us with standard ASCII keyboards there IS NO PROBLEM. You'd have to go out of your way to type these characters.

      That's because you've never used a computer in a non-English-speaking country. On a Spanish keyboard, the Ñ key is right next to the L key. On a French keyboard, the Ù key is right next to the M key (which is next to the L key, which seems pretty strange to me, along with A and Q being reversed from what we're used to). So yes, it's easy to make these typos if you use a non-US keyboard layout.

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    3. Re:Big assumption by wsapplegate · · Score: 4, Insightful

      > How the heck do you mistype an ASCII URL so you get non-ASCII characters? Do you have some kind of funky keyboard that produces non-ASCII characters? I'd love to see such a fucked up keyboard.

      Just come by my place, then. You will then witness lots of AZERTY French keyboards, featuring such non-(7bit)-ASCII characters such as è, ç, à, ù, and of course the now-ubiquitous ''. I'm waiting for you.

      > For those of us with standard ASCII keyboards there IS NO PROBLEM. You'd have to go out of your way to type these characters.

      I think you're affected by the 'My-Country-Is-Alone-In-The-World' syndrom, which, curiously, seems to affect lots of Americans, even when the topic of the discussion is *internationalized* domain names (!). Something must be very wrong, here...

      --
      Xenu brings order!
  8. Great.. not really by k98sven · · Score: 4, Interesting

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

    1. Re:Great.. not really by k98sven · · Score: 3, Insightful

      Usually the problem is that, as in your case, the name contains characters that are not native to other languages.. well.. get rid of the accents! That should fix everything. Use BOTH. (Of course, if such a thing were allowed.)

      Of course, that's the obvious solution.
      OTOH, the problem with this is that translitteration isn't easy, or consistent.

      Swedish characters like å, ä, ö, for example:
      English-speakers usually "brush the dirt off" and write a and o instead. But the correct translitteration is aa, ae and oe, respectively.
      (With japanese it gets even worse..)

      Not to mention names like München (Munich)..
      Should the have www.münchen.de or www.munchen.de or www.muenchen.de or www.munich.de or all of them?

      (Actually they do have all of these except the first, ironically..)

  9. More erroneous behaviour on the part of Verisign.. by Neophytus · · Score: 4, Informative

    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.

  10. IETF IDN Working Group by jazdc · · Score: 3, Interesting

    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 to finish their work.

  11. Does this mean...? by Temporal · · Score: 4, Funny

    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?

  12. Who the hell types domain name anymore? by EvilTwinSkippy · · Score: 4, Insightful
    /* 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 */

    --
    "Learning is not compulsory... neither is survival."
    --Dr.W.Edwards Deming
  13. Re:And before anyone complains.. by yggdrazil · · Score: 5, Insightful

    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.

  14. Email fails by billstewart · · Score: 4, Insightful

    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.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  15. what about charsets? by axxackall · · Score: 4, Insightful
    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.

    --

    Less is more !
  16. There are standards for those things. by billstewart · · Score: 3, Interesting
    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.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  17. How to type non-English characters by Anonymous Coward · · Score: 3, Informative

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

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

    1. Re:Mixing layers by pslam · · Score: 3, Insightful
      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...

  19. Can we mod Verisign as "arrogant?" by roderickm · · Score: 5, Insightful

    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

  20. ah the insecurity by myrashka · · Score: 3, Funny

    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.

  21. This is a bad idea by Minna+Kirai · · Score: 5, Insightful

    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.

  22. This angers me by Todd+Knarr · · Score: 3, Insightful

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