|
||
|
||
I am often asked what I think of multiple root nameserver systems—sort of like the Public-Root or the Open Root Server Confederation (ORSC) pushed by others in the past years. Whenever some well meaning person asks me for multiple roots in DNS, I answer:
DNS is a distributed, coherent, autonomous, hierarchical database. It is defined to have a single root, and every one of the hundreds of millions of DNS-speaking devices worldwide has the single-root design assumptions built into it. It would theoretically be possible to design a new system that looked superficially to be a lot like DNS but which had a multiple-roots design assumption. DNS cannot be ‘upgraded in place’ to make it into such a system, however. Current thinking in the community is that if we were going to do all the work to completely replace DNS, we’d want a system that did not superficially look like DNS. Is that what you want us to work on?
And if they say “but multiple roots are working for some people!”, I respond:
A lot of things can be made to work in a lab that won’t work for the world, but this isn’t even one of those. The folks who claim to have made multiple roots work are scam artists and they’re trying to sell you the London Bridge and if you check carefully you’ll see that the tradeoffs they’re willing to make in order to get the appearance of multiple-root functionality are not going to be acceptable to anyone without their particular bridge to sell.
If they ask “but WHY can’t the existing system be upgraded in place?”, I say:
Because coherency was designed into the system as a basic assumption, it’s always correct to cache and reuse data according only to the domain name, record type, zone class, and time to live. There is no requirement to keep track of who you heard it from or what naming universe THEY think they’re in. So, there can only be one .COM, one .SEX if any, and one. (root), and if more than one party claims authority for the same domain, some hell breaks loose and you’ll see lots of extra network traffic, lots of false negative responses, and lots of junk in everybody’s syslog files.
Usually they finish by whining “but I WANT it!!!” and so, I tell them:
So what? Everybody wants something. I want a pony. Get over it.
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byCSC
Sponsored byVerisign
Sponsored byRadix
Sponsored byDNIB.com
Sponsored byWhoisXML API
A World-Renowned Source for Internet Developments. Serving Since 2002.
This article would be more convincing if it said a bit about how proponents of multiple roots expected it to work and what problem they were trying to solve. Is the problem NSIs $8/year tax? Censorship? Trademark disputes? Is the resolver going to query each root till it finds a positive response? I can’t think of any other “solution”, but maybe I am not creative enogh.
If the problem is non-coherent responses, we already have that, of course, so it is a weak argument. And, as for junk in syslog, we have that too, and it is hardly an argument - sys-admins can ask the resolver not to log the junk. The increase in time and traffic to find a positive response seems like a better argument, especially if the number of roots isn’t restricted to a very small integer.
I cannot understand why this has such a negative tone.
In my experience with Unix/Linux/BSD doing multiple roots is a simple task in a configuration file.
Maybe the frustration seething from this article comes from being locked into the monopolists operating system and way of doing things?
This was discussed quite heavily in sidebar conversations at the Domain Roundtable Conference in May, and this conversation is more than a decade old, (and great minds must think alike because I was working on an article on this topic).
This cool internet thing that the Jedi (like Master Vixie) have put in place gives a platform for innovation.
Folks wanting alternatives simply find ways to route around what they percieve to be procedural roadblocks in order to do what they think is cool or will earn themselves some coin.
Namespace collision is going to play out in interesting ways for folks who choose to use roots other than the IANA root.
There is no barrier to entry in alternative namespace; anyone, anywhere can start their own root and add names to it, and manage it within their sphere of control (their desktop or their administration ‘Dominion’ of systems or nameservers).
This lends itself towards inconsistency in the behaviour of the user experience from one ‘Dominion’ to the next.
But consistency is important so that the inter-operability that we have grown to expect from internet technology remains.
RFC 1918 identified IP address space that would be set aside for things like Network Address Translation (NAT), making it possible for folks to manage their own 10.x.x.x/8, 192.168.x.x/16, for internal numbering in TCPIP.
Prior to that, there was a big mess of numbering used within corporations who had made up their own numbering schemes for their TCPIP internetworking within their offices. I recall a couple clients who had been using IP addresses allocated to Australian universities internally, which only presented a problem once they connected to the internet.
The point is, behavior of 192.168.0.1 in one network environment is different from another, but this all works because this is expected behaviour, which has been architected to work in a predictable manner.
Applying that paradigm to domain names sort-of works, but my point is that we are in the times before some line in the sand gets drawn to identify that there is alternative namespace, and ‘here is your place to play’.
Meanwhile, we will experience a growing number of namespace collisions, where the IANA/ICANN root adds TLDs and, in essence, overrides all of the alternative namespace delegations of that TLD.
When .biz was introduced at the first round of TLD applications at the Marina Del Ray ICANN meeting in 2001, an existing .biz had been operating in the Pacific Root.
I would like to hear, from one of the larger ISPs who include alternative namespace zones, what their action plan will be when a zone gets added to the root when an alternative zone exists.
The authorative root that Paul is describing contains the following TLDs:
http://data.iana.org/TLD/tlds-alpha-by-domain.txt
An Example of additional TLDs
Example: [.xxx, .travel)
ftp://ftp.new.net/domain/bind/root-stubs.conf
Do you just yank out the alternative space? What about your customer reaction?
What about the reaction of the folks who have spent their dollars with the alternative registries?
The key thing to follow is that the user experience, the audience of the domain names needs to be consistent. This is part of the elegance of the current system.
ICANN has proclaimed that they recognize only the IANA root. This is an approach that maintains the integrity and consistency.
RFC 2606 has identified some strings to be restricted from use in the IANA root similar manner to the way RFC 1918 identifies network address space.
Of course, I don’t see alternative registries popping up around .test,.example, .invalid, or .localhost, and I am really stretching the intent of that RFC, but it does merit the question… what about the simple identification of some alternative namespace TLDs that would never be included in the IANA root in the future.
Alternative namespaces could go out there and compete, outside of ICANN’s purview.
There are other good and bad ideas floating out there, and I some great ideas that I won’t talk about outside of the walls of an employer.
I think I am beginning to understand - the apparently the proposers of multiple root systems don’t plan to coordinate, which means that example.tld might point to one customer for one root server, and another customer from another root server. However, it is hard to believe they don’t at least claim to have a coordination method.
This would differ from the existing concurrency problem, where two DNS servers may disagree, but at least the owner of the domain knows which one is out of date, and which one is correct.
I though the USA was keen on personal freedom of choice.
The user need not be affected at all by ICANN’s use of the .biz doain, but still continue to resolve using their preferred (e.g. ORSC) mapping, only using ICANN if the ORSC resolution fails.
See http://www.ntcanuck.com/ for a personal name server that’s not a scam, and has *much* better performance for the average user.
I agree that coherency is important. But you are making an unwarranted leap from “coherency” to “singularity”.
Coherency - meaning that similiar queries receive similar answers - does not require that there be only one DNS root.
The nugget of your argument seems to be this: there is a aspect of the internal mechanism of DNS - in particular the caching of DNS information - that requires that all queries descend from the same root.
I would consier that kind of aspect to be a flaw rather than a feature. In fact those who would like to bring down a system might consider it a attractive vector for an attack.
I ran a number of operational machines and nets - it certainly was not a lab situation - for many years using non-NTIA root systems, including using my own machines as their own roots. I monitored them closely for years looking for the cache-poisoning boogyman. It never happened.
I agree that it is much easier if everyone adheres to one root. However, the question is which one? Because that choice is made by individual people and individual providers it is rather innocent to believe that global internet stability requires them to all make the same choice.
If the design of DNS today depends on there being exactly one root for each hierarchy, a point that I dispute, then that design is inconsistent with the practical reality of a decentralized, end-to-end principle-based internet.
As a practical, and very real matter, the existance of operating competing systems of roots with actual clients - and no one disputes that there are such roots and such clients - has demonstrated that it has not actually harmed users of other root systems, such as the NTIA root and vice versa. Thus, as it should be, those people who believe in a single catholic root can safely worship at that DNS techno-alter. And those who have a more polytheistic view of the matter can pay homage to own their pantheon of roots.
If the DNS design actually is flawed and actually can’t handle inconsistent choices (and errors and intentional attacks) made by net users and providers then the answer is not to say “Get over it”. The answer is to change the technology so that it can accomodate the different choices (and errors and attacks) that people will inevitably make.
As for your assertion that those who operate competing root systems are scam artists - those sound like the words of some 1970-era telco executive who is hearing about the internet for the first time.
While no analogy is perfect, it seems to me that there is an analogy between the DNS and SS7. DNS is used to map URLs to IP addresses. SS7 is used to map E.164 phone numbers (which are names, not routing addresses) to routing addresses such a Q.708 SANCs or E.212 IMSIs.
While SS7 has a logical unique root, published on the ITU web site, there is no “authoritative root server”. Each of the thousands of SS7 operators around the world is responsible for negotiating an agreement with some higher-level operator, or for implementing in their system the data published by ITU (or whatever other data they consider to be more authoritative than that published by ITU).
ITU exercises no control whatsoever on the entries in the thousands of SS7 switches around the world (which enable the interconnectivity of some 2.5 billion end-user devices).
Commercial and market pressures are such that there is very little, if any, inconsistency in the data implemented in the various switches. Indeed, anybody in the world can call anybody else in the world, and it works without having a single “authoritative master” whose data is subject to some central control.
I’m not sure that I understand what the differences are between this situation and the DNS.
I’m probably missing something, and would appreciate an explanation.
Richard Hill
Counsellor, ITU-T Study Group 2
IMHO, integrity is one of most important requirement for and DB system, but this does not mean there should be no 8-bit characters in DNS which is just a distributed DB system.
On the other hand, DNS system SHOULD be able to process 8-bit records and keep the system integrity and extensible.
Someone talked about the possible security problem with multi-lingurual DNS system, to me this is a “solution” problem but NOT a architecture problem. If current solution may derive to such security problem, we should work to find a better DB encoding mechasim & DB search mechanism.
Multiple root servers is the compasation solution to current “flawsome” DNS architecture. It’s not good, but it’s caused by ICANN’s U.S. Government backgroud.
Great minds are open to change…. ‘Nuff Said
As a long time supporter of the universal namespace operated by IANA, it may come as a surprise that I have joined the Open Root Server Network project. I’ll try to explain what’s going on and what it all means. read in full
Randal asks Paul and his colleagues to participate in a discussion.
I think this is a rather open ended invitation as i would postulate that Paul has an number of colleagues that touch one or more of his apparently many and varied interests.
So, for the purposes of clarity, are you refering to the ORSN operators and the folks in that alternate root reality or the root server operators (those legacy servers on whom gt. 95% of the worlds internet users depend).
Or is it some other set of Pauls associates and colleagues that you refer to?
If I read this thread initiated by Paul Vixie correctly, the invitation should extend to Richard Hill. As it seems that the DNS users can see his phone numbers, but his phone numbers cannot see the Internet hosts. Or may be I am wrong, his phone numbers could just get a header to be used as an IPv6 address and not need the DNS. Or may be the phone numbers could be used by HIP and mapped into IPv6 addresses. Or may be each area code could be treated as a numeric TLD and be an NDN (numberic DN)? This point would certainly be of real interest to open roots.
Randal South on Feb 21, 2006, 09:22 pm PST did say:
“My invitation is to Paul Vixie and anyone else who would have information on a company called the Unified Root, based in Amsterdam. Apparently Unified Root has taken things a step futher than ORSN and the potential for the Unified Root to grow is considerable.”
Dear Randall - all you need to know about the UnifiedRoot can be found here:
http://www.cynikal.net/~baptista/P-R/
I don’t think Paul knowns much about it. But his original comments about UNIDT - the official founders of the UnifiedRoot - was that they were Pirates. I think this claim correct. But Paul later calmed down his accusations, softened his tone and edited out the offending comments from all his articles. Self censorship from Paul is a good indication the lawyers got to him on time.
At this time UnifiedRoot and the PublicRoot/INAIC/UNIDT and Xennt et. al are on their way to the courts in Den Haag to argu over the spoils of what has been a farce.
What happened was the PublicRoot was infiltrated by rogue eliments working at arms length with UNIDT - the commercial resellers of TLDs. This was a conflict of interest which resulted in the embezzlement by employees of the Public-Root and UNIDT (now the UnifiedRoot) of some 125 to 150 Euros. We still don’t know the size of the total fraud.
UNIDT/UnifiedRoot also raided Public-Root/INAIC technology. The whois on their site was stolen from the Public-Root/INAIC. Indeed as an insider we can see Pauls claims they are pirates was on the mark. Probably the first time he was right about something concerning the PublicRoots, and he retracts it.
“I think it would make an interesting technical topic. As someone who knows absolutely nothing about this company, I would like to know how it is that they could implement a system that allows them to see us, but we can’t see them.
Thats easy. We include the legacy system root answers - which is IANA/ICANN and allow our users to quickly establish top level domains in the public system. In the PublicRoot network - the top level domain holders are the designated stakeholders. UNIDT/UnifiedRoot was an experiment in commercializing the process. Unfortunately the experiment failed due to fraud between our operations and UNIDT/UnifiedRoot.
So now that we have had a year of lawyers bugging us - we may actually be able to get the PublicRoot back on it’s feet this year. The UnifiedRoots survival will be dependent on their co-operation with the PublicRoot.
“This is an enigma. These are the comments that were reported in the Wall Street Journal and perhaps they need further elaboration.”
No enigma, just bad reporting and backwards journalism. Business as usual. The press missed ICANN and the fraud there and they have missed the Pirates at the UnifiedRoot. Standard resporting practices. The only one who got this one right was Paul.
Regards
Joe Baptista
“If I won’t let Milton Mueller put words in my mouth, why would I ask Joe Baptista to do so? Never mind—rhetorical question—“I would not.’’ I always thought and still think that UNIDT/UnifiedRoot/name-of-the-week were pirates, and never intended to moderate my disgust toward them in any way, have heard from no lawyers on the matter, and would like to be left out of this whole episode of gangster-on-gangster violence. Please.”
UNIDT started up a nameserver and populated it with copies of ICANN data and then added their own fake top-level domains to it. That’s how DNS piracy has to work—anyone who doesn’t copy ICANN data can’t get any work done at all.
As to your question, it would be trivial to write software that did what you suggest, but there’s no way to ensure that every DNS user searches the same set of alternate name spaces, or searches them in the same order. Therefore any name not entered into the ICANN namespace will not be universally available no matter what software we deploy to try to make it so.
Not everyone. UNIDT, for example, does not worry about balkanization. New.Net does not worry about balkanization. If anything, they’re counting on balkanization, or at least, counting on the threat of balkanization, to make their investors happy.
Why would anybody waste a nanosecond or an electron-shell trying to make this pirate namespace more available? They’ll sell names ending in .XXX or .SEX or whatever, and other pirates like New.Net will do likewise, and whatever rubes like Schipol Airport or Earthlink they can rope into their scams will see only the local versions of those names, not the competing ones. Any effort any of us expends trying to make these pirates more available—more successful—is just helping the unjust and unworthy cause of balkanization.
Leave them alone and they’ll die off. Keep moving forward.
If you want to live in a world where the names available to an Internet user are non-universal, that’s your business. (I won’t be joining you in it.) On the technical side of things, if you want competing namespace providers then you can’t really do it under DNS—DNS presumes coherency at such a deep level that this kind of crud really doesn’t get good traction. Look into DHT based naming systems, study the market economics, try to convert the Internet to a non-universal naming system, and let us all know how it works out for you.
Let the record show that I do not like everything ICANN does, but they’re the only credible namespace on the planet as of this moment. Creating a credible alternative is so much harder than just fixing what ails ICANN, that nobody I take seriously would even give alternative namespaces a moment’s thought.
I am afraid all what Paul Vixie says sounds good, smells good, but is out of reality.
It is true that outside of ICANN there is no other warranty than in the real world, where there are 192 independant states and around 20.000 languages witout any authoritative statenameroot nor langroot (I am working on a reporting one) to decide there will be no name conflict. However for a few millenia the system does well. Richard Hill discussed the other SS7 system recently.
The question is a trust, justice and authority. ICANN is just the manager of the IANA computer and of the names/numbers entries. Up to now it claimed to have taken on RFC 920 agreement which was consensual all over the world because it was not a decision by anyone, but the result of the decription of the common state of the naming. And getting a few million of dollars out of it. That they are wasted is an other issue. The root is big businesss. By the same token, Paul’s philosophy was sound because the Internet was for everyone (Vint wrote an RFC on that). However this was only a generous (but not necessarily efficient)dream.
1. US Communications Code puts the Internet under US jurisdiction. The IETF (RFC 3935) wants to influence (not serve) the way the people “design, use, manage” the Internet along IETF core values which miss equal opportunity in these areas for all whatever the origin or language.
2. The US Congress said: the Internet belongs to the USA.
3. The Tunis Submit made 191 countries to agree and 192 to create the IGF for the next step.
4. as anounced, the NTIA is publicly testing the sale of the IANA (currently the IANA is sold for “less than $ 10.000” to ICANN). I suppose there is a rule permitting a direct sale when the amount is lower than a given amount. This means that anytime now we may learn that the “Internationalised US Internet” has been sold to a private company or consortium. Let name that consortium AmerICANNcode. I do not see any difference between AmerICANNcode and New.net, except probable anti-dominant actions all over the world. Unless there is the urgent organisation of a concerted root solution.
That concerted root inter-pares solution is very easy to set-up (a root file managed by all the people managing a TLD and accepting to respect the TLD of others). This was tried by the TLDA, but they wanted to discuss the namespace rather than just serve as a rgeistry. The next step is very easy: it consists in an IGF crash specialised meeting, with the ITU or any other acting as a secretary, creating a TLD CONROOT registry, co-accepted by most of the Governements,experts, operators, ISP, civil society, business as the users’ representatives, providers or managers/consultants.
Then it will be up to the ISPs to decide which root they want to offer to their users (or to make it a subscription option). The initial management of it is pretty easy: to just dig the TLD nameservers. By the way, this is what I do. This results in a very interesting rootfile as the current top zone is not exactly as it is said it is. In a next step, more formal authentication of the TLD Manager data may be added.
Recently Vint Cerf defined very well what is the authoritative root: the one which has the largest number of users. Right now it is the NTIA root file + pollution. Potentially it is the GSMA root file, run by NeuStar (which already supports the IETF secretariat) for mobile users. The concerted universal cross technology root (naming is not mandatorily only for the Internet) is certainly the one with the largest number of potential users. GSMA added “.gprs” for its own use. What about the ITU doing the same and adding “.tel” for all the telephone numbers?Certainly the largest user base. Is it what you want: ITU defacto replacing ICANN. It would work well, but I prefer ITU serving the community as CONROOT Secretary, that managing it.
There is a very good way to test about all this. Let the Root Severs go on strike. I tend to think the Internet would hardly notice. Some information on TV for those who do not trust their ISPs resolvers and who would be unaware. IGF would propose a meeting for all the interested parties. I tend to think the solution(or compatible solutions) would be found in less than one month (shorter period than a root update by the IANA). All what the root doom scernarii we are proposed presuppose the users are dumb stupid. This is not necessarily the case.
Paul, I agree with all of your last post except the second sentence:
The ‘pirate’ name server can lookup ICANN domains dynamically if they are not its own domains, without ‘populating’ their own server. It’s still copying the ICANN data, just as most ISPs do.
Regards,
Colin Sutton
Jefsey wants to know the diff between ICANN and New.Net - here it is:
This is domdiff looking for missing NS records. Comparing files
root-servers.domains
new-net.domains
2006-02-24 (55) 15:33:25 loc
2006-02-24 (55) 14:33:25 UTC
ADD: TRAVEL. NS A.GTLD.BIZ
ADD: TRAVEL. NS B.GTLD.BIZ
ADD: TRAVEL. NS C.GTLD.BIZ
ADD: TRAVEL. NS D.GTLD.BIZ
ADD: TRAVEL. NS E.GTLD.BIZ
ADD: TRAVEL. NS F.GTLD.BIZ
ADD: TRAVEL. NS G.GTLD.BIZ
ADD: TRAVEL. NS H.GTLD.BIZ
DELETE: TRAVEL. NS TLD1.NEWDOTNET.NET
DELETE: TRAVEL. NS TLD2.NEWDOTNET.NET
This is hostdiff looking for missing A records. Comparing files
root-servers.hosts
new-net.hosts
2006-02-24 (55) 15:33:27 loc
2006-02-24 (55) 14:33:27 UTC
ADD: J.ROOT-SERVERS.NET A 192.58.128.30
ADD: CON1.NIPR.MIL A 207.132.116.25
Status New.Net SOA
soa(”.”,“2006021901”,“NS1.NEWDOTNET.NET”,“206.132.100.43”).
soa(”.”,“2006021901”,“NS2.NEWDOTNET.NET”,“64.211.63.138”).
Root-Servers SOA records
soa(”.”,“2006022301”,“a.root-servers.net”,“198.41.0.4”).
soa(”.”,“2006022301”,“b.root-servers.net”,“192.228.79.201”).
soa(”.”,“2006022301”,“c.root-servers.net”,“192.33.4.12”).
soa(”.”,“2006022301”,“d.root-servers.net”,“128.8.10.90”).
soa(”.”,“2006022301”,“e.root-servers.net”,“192.203.230.10”).
soa(”.”,“2006022301”,“f.root-servers.net”,“192.5.5.241”).
soa(”.”,“2006022301”,“g.root-servers.net”,“192.112.36.4”).
soa(”.”,“2006022301”,“h.root-servers.net”,“128.63.2.53”).
soa(”.”,“2006022301”,“i.root-servers.net”,“192.36.148.17”).
soa(”.”,“2006022301”,“j.root-servers.net”,“192.58.128.30”).
soa(”.”,“2006022301”,“k.root-servers.net”,“193.0.14.129”).
soa(”.”,“2006022301”,“l.root-servers.net”,“198.32.64.12”).
soa(”.”,“2006022301”,“m.root-servers.net”,“202.12.27.33”).
That is the only diff I can see between the two “pirates”
D’accord, I could run the compare the other direction. It would show some more domains ...
I guess that does not matter for the discussion
By the way I am supporting the “balkans” Cesidian-Root, OpenNic and Public-Root with daily reports because I think that is the only way to teach ICANN the diff between “to talk” and “to dictate”
Regards
Peter and Karin Dambier