Welcome:
Login
|
Sign Up
|
About CircleID
Follow:
|
|
|
|
||
|
||
One of the consistent chants we’ve always heard from ICANN is that there has to be a single DNS root, so everyone sees the same set of names on the net, a sentiment with which I agree. Unfortunately, I discovered at this week’s ICANN meeting that due to ICANN’s inaction, it’s already too late.
Among the topics that ICANN has been grinding away at is Internationalized Domain Names (IDNs) that contain characters outside the traditional English ASCII character set. The technical issues were settled a while ago in the IETF, with a scheme called punycode that encodes Unicode characters as ASCII strings stat start with xn—. ICANN has tied itself with the issue of homographs, different characters that look the same or mean the same thing. Once people noticed that IDNs let you register different names that look the same, the intellectual property crowd that has always had a mysteriously great influence on ICANN went into a tizzy and they went into lengthy discussions on what to do about them. Unfortunately, there is no technical way to make homographs go away, because there is no agreement on what ‘‘the same’’ means. ICANN came up with a draft recommendation on IDN policy which nobody implemented, and is now about to come up with a second draft which nobody seems likely to implement, either.
While ICANN dithered, groups in China and in Arabic speaking countries went ahead with experiments in IDNs for Chinese and Arabic, and set up experimental parallel root zones with names in the local character sets. These experiments worked (no surprise, Unicode and punycode are technically sound) and now those roots are the roots that everyone in those countries use.
A friend who traveled to Arabic countries reported that ISPs simply reroute traffic for the public routes to their own root servers, and most people are none the wiser except that Arabic domain names work. He only realized what was going on when he tried to reach the Red Cross web site and kept getting the local Red Crescent instead, and tracked it down to the DNS returning different answers from what he’d expected to get from the usual DNS.
Furthermore, at least one large ISP in Europe is doing the same thing, redirecting root server traffic to their own servers. In their case the goal more likely is to deal with users with misconfigured DNS clients by catching traffic to any name server, not just the roots, but it also offers the opportunity to make additions and deletions without the knowledge or consent of either the real domains or the users.
Now that the split root genie is out of the bottle, is there any way to get it back in? Not that I can see. Let’s hope that users in China and other countries with their own private roots figure out that there’s more to the net than their DNS shows them.
Sponsored byIPv4.Global
Sponsored byCSC
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byVerisign
Sponsored byRadix
Sponsored byWhoisXML API
A World-Renowned Source for Internet Developments. Serving Since 2002.
This is a verbatim re-post of an old article (December 2005).
Yes, it’s mirrored from my blog where the entry’s date was accidentally reset when I restored it from a backup. It’s still as true now as it was then, though.
There is too much focus on the multiplicity of root systems.
The real issue is not whether there is one single root but rather that those roots that are out are consistent with one another.
There are differing views about what it means for two root systems to be consistent. The conservative point of view is that consitency means a near-mirror of the ICANN/NTIA/Verisign root with only those changes neccessary in the root zone SOA records.
A more liberal point of view is that consistency means that for those TLDs that the two roots have in common that the information about those roots (mainly the delegation records) is identical. In this more liberal interpretation, two roots would still be consistent if they have TLDs that are not in common. (I use the phrase “boutique TLDs” to describe these TLDs of limited deployment.)
I think pretty much all of us agree that the really bad sitution occurs when there are two roots that contain TLDs, whether or not those are TLDs found in the ICANN/Verisign/NTIA root zone, that contain *different* contents. But we do have trademark laws already on the books that allow the competing claiments to duke it out in the courts; we don’t need to invent new mechanisms to deal with this.
(By-the-way, have you notice that Brett and I seem to do tag-team comments? It’s not orchestrated, I promise. <insert smiley emoticon of your choice>)
Karl’s viewpoint is quite reasonable. Other people have noted that it’s somewhat common for ISPs to FTP copies of the IANA root zone and run their own local root servers, which works fine.
Assuming that ICANN ever unties its IDN knots, the fun will start when they approve a TLD that means China in Chinese. I believe the Chinese alternate root already has one of those, so the least bad outcome would be for the Chinese government to push something through the GAC saying that the new TLD goes to them so they can make it their existing TLD. But it’s someone optimistic to hope ICANN will be that sensible.
I agree. ICANN ought to create a mechanism to distribute a root zone file to anyone who asks.
Best,
Martin
John,
Thanks for the pointer to the IANA root zone file ftp site. I nearly forgot about that since out of sight, out of mind, with respect to Internic. You may know that the internic.net domain was transitioned to ICANN some time ago so ultimately it is ICANN that is operating that infrstructure.
Here’s what I saw:
Looks like it’s updated regularly as well.
Best,
Martin
Redirecting traffic sent to one machine (say A.root-servers.net) to another (say A.my-root.net) without user’s informed consent is hijacking, pure and simple. I would never used an ISP which does that. And I strongly suspects that all the countries that do so are dictatorships. And they don’t give a damn to IDN, they just want more control over their own citizens.
You said that “one large european ISP” do so, I would be glad to know the name.
(Tiscali uses an alternate root, which is not the same since, AFAIK, they do not redirect traffic sent to the real root name servers, so the users still can opt-out.)
It’s not hijacking. Networks are private entities. They can control their traffic how they see fit. If that wasn’t the case, network operators would be hijacking other types of traffic as well through RBL’s and blackhole routing. They aren’t.
The key is maintaing a single, unified view. At least until something better comes along. Who operates or returns the answer for that view is irrelevant.
-M<
By Stephane Bortzmeyer | Apr 10, 2007, 02:37 am PDT
What matters is not that my packets get to a certain machine, but that I get satisfactory responses and consequences. An accurate answer from an ISP cache is as good as crossing the Internet for the same answer from the “real” source.
By Martin Hannigan | Apr 10, 2007, 07:50 am PDT
My issue with not having a unfied root is that sometimes I want to know about what’s known inside some other realm of interest. It’s a two way street, people inside a local realm may want global reach and that’s well publicized. But sometimes there is a desire to reach globally into a local realm. I may want to access ??.?? to find when games are scheduled in ??, even though I am neither currently in China nor in a Chinese-speaking land. That’s why I think that it is important to have a single root - or be able to (or so that I can) find the root I want.
It’s a virtual root presenting a unified view that is not physically organized in the manner that it is now. Root operators already do this by anycasting instances from multiple locations.
The change that folks like Stephane are concerned with is “who” operates them. Organizations run all types of special applications without a special class of operators all day long. Why not root?
Best,
-M<
I can understand the concerns of Stephane and Edward.
First with Edward’s comment:
In the more broad definition of “consistency” it is possible that the root that one uses at home contains boutique TLDs that are not found in the root that one might use when travelling.
Some might consider that to be a problem; other’s, such as myself, might consider that to be a sign of growth and experimentation at the edges. In non-network life I have seen local brands of products grow from local offerings available only here in Santa Cruz into national products. What’s wrong with that for TLDs?
Sure, it can be a nuisance if you want the boutique TLD that you are used to from home, but it was the choice of the person who picked that TLD, a person who, presumably knew of and accepted the limited visibility.
Regarding Stephane’s point - I don’t feel the same concern about “hijacking” (which is not to say that the concern is not a valid one.) However, there is a different basis for concern should there be a non-consentual shift of roots: different roots may do more than simply deliver answers.
Today there are no constraints on the main body of roots, or on any other roots, to refrain from data mining of the query stream and selling the resulting information. Nor are there any restraints that prevent biased responses or even intentional pollution.
Take an extreme case, the main root servers run by the US military. It would be surprising indeed if those servers are not today feeding the query stream they receive into the data analysis engines of the US intelligence agencies.
In other words, if a person is using a root system there are indeed reasons to be concerned if shifted, without consent, to another system even if that other system is consistent.
My answer to that issue is not to deny existance to consistent root systems but to suggest that we need to develop, or the operators to publish, clear statements of their service policies and what they do to protect privacy.
As far as I can tell, there are few, if any, root server operators offering any sort of privacy policy.
In the context of this discussion, for all intents and purposes, it would be a copy of the DoC root zone.
There’s already speculation by some that a company has been formed to enter into this market commercially and provide extensions to root level DNS. My understanding is that some sort of P2P based root zone delivery system is being developed and that a commercial entity will open a project on sourceforge to create a sort of “open root” solution to facilitate exactly what this discussion is detailing.
-M<
Given the value of the marketing data that can be mined from a root server, assuming that it gets a statistically useful amount and distribution of query traffic, I am surprised that no one has built a system of roots and tried to pay users and ISP’s to send their queries there.
Google’s AdSense advertising program, through which websites can obtain revenue by posting Google’s ads, has brought major changes to the web. It is not unreasonable to believe a share-the-revenue version of DNS might also be a viable business that could have far reaching implications.
I must have problems with English since apparently noone understood
what I wrote.
There are several services sold by an ISP. The most basic one is IP
connectivity. Unlike what Edward Lewis wrote (“What matters is not
that my packets get to a certain machine”) the *entire* purpose of
this service is to deliver packets to the destination machine *I*
choose (not to another one).
If I send a packet to 192.5.5.241, port 53, the ISP *must* deliver it
to 192.5.5.241. Silently proxying it to another machine *is* hijacking
(unless I consented to this redirection).
There are other services, a typical one is DNS recursive service,
which is used by most users. In that case, the ISP may use the real
root behind, or another one, or tricks such as DNS wildcards. It is of
questionable benefit but it is not hijacking, as long as there is a
way to opt out. A typical solution is to run my own DNS resolver and
this is why I *need* IP connectivity to the root name servers.
Otherwise, it is not an *Internet* access provider, it is a closed
service like AOL or Compuserve in the old times.
How does a user choose which instance of a root server that they desire to use? I argue that they don’t even know that there is such a concept and it’s completely irrelevant except to those of us in the business itself.
Stephane, where do root servers keep their privacy policys? They don’t seem to be easily reachable, at least publicly.
Best,
-M<
> How does a user choose which instance of a root server that > they desire to use?
This is becoming ridiculous and I regret that this discussion is in
English, language where I’m embarrassed by my lack of fluency.
I never suggested that an user (even a geeky user) wants to use a
specific root name server. I do not care if A-root or B-root or C-root
is choosen, BIND does it for me.
What I *do* care is that the *set* of name servers I choose in my
resolver is the one actually used. If I choose ORSN, I want to use
ORSN. If I choose ICANN, I want ICANN, *not* any “alternative root” or
a so-called “national root”.
It is not to the ISP to decide on behalf of the user what root the
user will use (except indirectly through the recursive DNS service
provided by the ISP, service where opting out *must* be possible).
You consent to that sort of thing when you sign up for a typical domestic broadband service (under the heading “terms and conditions”). I have no idea what ports my ISP “hijacks” from time to time, although I’m pretty sure that port 80 incoming is blocked, and port 80 outgoing is hijacked through a transparent proxy. I suspect that something similar happens with port 25. As far as I know they aren’t doing anything sneaky with port 53 traffic at this time, since all their customers have DNS configured through DHCP anyhow.
You might not want this kind of interference—in fact it might really get up your nose from time to time—but you don’t usually get a lot of choice when it comes to domestic Internet service. That’s one of the reasons I don’t rely entirely on my domestic broadband connection for all purposes: I also have at least one virtual private server which is specifically raw and unfiltered.
I think we’re on the same page discussion wise, with only a little lost in translation.
My main point remains that it doe not matter who operates a root server, as long as the answer coming back is consistent with community expectations. We should be encouraging operators and others to run their own local root servers.
The “who” can operate seems to be the roadblock, more so than the “how”.
Best,
-M<
Sorry but I think this article is a bit of FUD.
China does not have an alternate root. Many Chinese PCs have a browser plugin that changes some IDN URLs to add something.cn onto the end. It might look like an alternate root but it isn’t one.
The European ISP is presumably Tiscali who have been users of ORSN for years. Last year they also started to sell alternate TLDs but they have been resolving them for years. This is not a sign that things are falling apart.
I’d love to know what the Arabic country with the supposed alternate root is. Let us know and I will ask them.
Here is a link (an old one at that) to a report that clearly states that China has not created an alternate root:
http://english.people.com.cn/200603/03/eng20060303_247684.html
With regard to whether competing roots have been established by China:
It depends with whom you are talking whether Taiwan is part of China or not, but when I was on the ICANN board I discovered that Taiwan had established its own root system. (It was done in a very strange way - the list of NS records in the NTIA/ICANN/Verisign root zone pointed to some servers in Taiwan, but those provided a set of NS records that pointed to a different set of servers. A separate set of root servers, used by some folks in Taiwan, pointed to those latter servers.) It turned out that it was a leftover fragment of an experiment and was subsequently returned to the normal mode of operation.
As for China proper, I saw that People’s Daily article denying it but my “dig” queries indicated that something was going on. I was getting valid, authoritative responses (from the servers that also handle .cn) to queries for names in an IDN encoded TLD. That only directly means that there was an additional TLD loaded into those servers, it does not directly mean that there was a new root zone that contained that TLD. But it does suggest it or hints of preparation to do so.
It may be that China and other countries do not have competing roots - yet - but there is plenty of evidence that there has been experimentation, perhaps so that they can have a plan B with regard to ICANN.
Ms. Bortzmeyer, your English is exemplary.
You are hereby invited to my house for dinner. However, we do not provide a menu, and you will eat what we are serving. That’s because anyone who eats at my table is served what is cooked in my kitchen.
You may dine elsewhere if you like.
Re: China breaking free from the root.
I read this recently in a Village Voice article: “Already, foreign country-code operators are balking at U.S. control and the hefty fees ICANN has attempted to impose; China recently bolted the ICANN root and set up its own root system using Chinese characters; it can be accessed through PacificRoot.”
Published date: 4 April 2001. Six years ago. And the root, it seems, has continued to survive.
The article was about Paul Garrin and his name.space problems. New.net was represented as the newcomer that had marketing power and posed a real threat to ICANN.
http://www.villagevoice.com/news/0114,ferguson,23569,1.html
Now we have another set of new gTLDs coming up - are we doomed to repeat another circle of history, or does anyone fancy working with ICANN to get it moving this time?
Kieren