The US Dep't Of Commerce, via its NTIA (Nat'l Telecommunications and Information Administration) has published a request for information titled Internet Assigned Numbers Authority
What I wonder is this: ICANN performs "the IANA function" in response to a contractual-like agreement with the National Atmosperic and Oceanic Administration (!). ICANN, via it's performance of IANA, operates the L root server - l.root-servers.net. If the IANA function is moved to a new home, does the L root server go with it?
I'm quickly reading through the transcripts from last week's IGF (Internet Governance Forum) Consultation meeting.
I thought it might be useful if there were a glossary of phrases used in these meetings.
At the risk of failing utterly and entirely, it might be fun to follow the style of Ambrose Bierce in his Devil's Dictionary.
I hope that this will evolve and expand; suggested contributions are welcome.
IGF à la Bierce:
ALAC, n. A Potomkin Village established by ICANN to create the impression that individual users of the internet are actually represented in ICANN. See "stakeholder".
CAPACITY-BUILDING, v. The knowledgeable (and rich) undertake to train the less educated (and poor.)
COORDINATION AND MANAGEMENT, n. Regulation.
CRITICAL INTERNET RESOURCES, n. Any thing that has nothing to do with the actual reliable availability of the internet but which can serve as an excuse to impose a desired form of regulation. Usage as established by ICANN: no matter that actually pertains to the continuous, accurate, or efficient provision of internet services is a critical internet resource.
DEMOCRACY, n. Neither this word nor this concept exists in the lexicon of internet governance.
IETF, n. A chimera, The IETF, as perceived in the lexicon in internet governance is a mythical body that efficiently advances the technological arts of the internet. The IETF, as perceived by others, is something else.
INDIVIDUAL USER OF THE INTERNET, n. Neither this word nor the concept of individual humans who might be affected by-, or who might have a voice in-, internet governance exists in the lexicon of internet governance.
INTERNATIONAL CONNECTION COSTS, n. Money spent on international telecommunication assets the cost of which is to be apportioned on the basis of the national wealth of the countries on either end.
MULTISTAKEHOLDER, adj. Anything that excludes the people who actually use, pay for, or who are affected by the internet.
NONDUPLICATIVE, adj. A quality of self-imposed blindness in which ICANN is to be preserved no matter its faults and no matter its non-existent role vis-à-vis the actual technical reliability of the internet.
OPEN AND INCLUSIVE DIALOGUE, n. 1) A discussion about a strictly defined question that occurs within a rigid framework imposed by national governments in which the only voices given weight are those of national governments. 2) A discussion characterized by a nearly total lack of comprehension of the internet technology underlying the dialogue.
OPEN, TRANSPARENT, OR ACCOUNTABLE, adj. Empty filler; meaningless terms. Usage established by ICANN: Open means closed, transparent means secret, and accountable means arbitrary choices made on the basis of unknown criteria by unknown people using unknown materials.
STAKEHOLDER, n. Any organization or entity that makes money from the internet or any combination that lobbies on their behalf; any national government or intergovernmental organization; or any civil society organization. Individual users of the internet are never considered stakeholders.
People are asking whether it is time to replace ICANN.
Apropos of that thought here is something I said back in 2002 in my testimony before a US Senate committee:
What Would Happen To The Internet If ICANN Were To Vanish?
Much of the debate over ICANN is colored by the fear of what might occur were there to be no ICANN.
ICANN does not have its hands on any of the technical knobs or levers that control the Internet. Those are firmly in the hands of ISPs, Network Solutions/Verisign, and those who operate the root DNS servers.
Were ICANN to vanish the Internet would continue to run. Few would notice the absence.
Were there no ICANN the DNS registration businesses would continue to accept money and register names. With the passage of time the already low standards of this business might erode further.
The UDRP (Uniform Dispute Resolution Policy) system runs largely by itself. The Federal ACPA (Anti Cybersquatting Consumer Protection Act) would remain in place.
ICANN has already established a glacial pace for the introduction of new top-level domains. ICANN's absence will not cause perceptible additional delay in the creation of new top-level domains.
ICANN has already abrogated the making of IP address allocation policy to the regional IP address registries; those registries will continue to do what they have always done with or without ICANN.
ICANN has no agreements with the root server operators; the root servers will continue to be operated as an ad hoc confederation, as has been the case for many years.
The only function that would be immediately affected would be the IANA function. IANA is an important clerical job, particularly with regard to the country-code top-level domains (ccTLDs.) IANA is not a big job, nor does it have real-time impact on the Internet. (In fact there is a credible body of evidence to suggest that ICANN delays certain clerical tasks on behalf of ccTLDs for months on end in an effort to coerce ccTLDs to sign contracts with ICANN.)
There are those who will try to divert outside reforms of ICANN by asserting that touching ICANN will cause the Internet to collapse or otherwise be damaged. The truth is quite the reverse - ICANN's ties to the technical and operational stability of the Internet are tenuous at best. A full inquiry into ICANN, a full reform of ICANN, or a complete rebid of the agreements under which ICANN operates would not damage the Internet.
Sung to the old traditional sailor's tune:
Way hay, an' up she rises; way hay an' up she rises;
Way hay, an' up she rises; ear-lye in the morning.
What could you do with your own root server? What could you do with your own root server?
What could you do with your own root server? Ear-lye in the morning?
etc, etc.
Since I can't sing a note I'd better stop now.
But the question lingers: What could you do with your own root server? And I mean by this, suppose you had one of the [A-M].root-servers.org addresses?
What could you do? - Probably a lot more than you think.
You could make a lot of people angry; you could make a smaller number people very angry; and you could really hose a number of selected targets.
Please read this note with a bit of humor - it is not intended to be a deep study, perfect in all details. Rather, it is merely the result of a bit of conjecture (while enduring a flu and fever) about what might be possible. So if some of this has the nature of coming from an overheated brain, let me assure you, it really is.
This note is entirely hypothetical. But it is neither completely fanciful nor impossible. Some of the thoughts below are conjectural - but that is not to say that they aren't real. Many, but not all, of these thoughts would, if implemented, be very obvious to the cognoscenti. Some of these thoughts might simply be impractical. But I am certain that many are feasible given adequate ill-will and incentive, particularly if the ill-doer isn't looking for total coverage but is willing to do only partial data mining or cause partial, or short-lived, disruption.
I have not even begun to think of how this list is affected, or prevented, by full or partial deployment of DNSSEC. Remember, I am not writing about the harm that could be caused by some random machine that claims to be a root server. Rather, I'm writing about what could come about through the purposeful manipulation of a machine (or cluster of anycast machines) that is part and parcel of the legacy system of DSN root servers. In fact, because the concerns I raise here come from "the inside", they may be aggravated rather than diminished by the presence of DNSSEC.
The domain name system is organized much like a feudal hierarchy - root servers are the kings; TLD servers are the Dukes; third level servers, the ones that you and I run, or have run on our behalf, are the knights at the bottom. At each layer of DNS, as in feudal systems, the superior node has authority over its inferior nodes. In particular, any node of DNS has the ability to withdraw or modify the delegations of authority to its inferiors, and by virtue of the way DNS works, the superior node is also in a position to partially supersede the work of the its inferiors or even replace them. From this arcane beginning comes enormous power, for good or ill, in the domain name system.
Today we are protected against malevolent DNS not by institutions but by people. Today all that protects us is the good will of the people who have their hands on the buttons of the top (root) and intermediary (TLD) DNS servers. Those groups who, through historical chance, run one of the 13 root servers, are, for the time being, honorable and public-minded.
But times change, people change. And sometimes people, or organizations are coerced to depart from past behavior. One of the great failures of internet governance under the hand of the US Department of Commerce and it's unacknowledged offspring, ICANN, is that the root servers are answerable only to themselves.
A root server could be a very useful tool for information warfare were it to be operated by an institution that has a greater obligation to protect its country than to protect the internet. Three such institutions are worth noting: the United States Department of Defense (g.root-servers.net), the United States National Aeronautics and Space Administration (e.root-servers.net), or the United States Army Research Lab (h.root-servers.net). The United States has recently indicated that it considers the internet to be a weapon, so it would be surprising indeed if the US did not have a rather more complete study of the issues I raise here.
Moreover we have seen, particularly in the United States, that governments are not beyond secret collaboration and secret coercion of private actors. Since the recent revelations about AT&T's and the US Government with regard to the latter's domestic and warrant-less surveillance efforts, one must wonder whether ICANN (l.root-servers.net) is any more immune from USG pressures than AT&T?
No nation is invulnerable to the effects of a rogue root, or large TLD (e.g. .com), server.
Just as nations outside the US are rightfully concerned about the dangers of US hegemony over DNS, the US itself might consider how its own national security might be affected by ill or malicious behavior of root servers outside of its national borders.
Getting down to brass tacks - what exactly could one do if one happened to have a root server? (And remember, anything that a root server can do to the internet in total, a TLD server can do to its own sub-hierarchy.)
Before answering that I'd like to mention some aspects of root servers:
First is that each root servers only see a small portion of all DNS queries. Root queries are spread among 13 servers (or more accurately, 13 groups of servers) - thus there is about a 7.7% chance that any given query will land on any given root server. In addition the DNS contains a lot of intermediate caching of previous results. In my own measurements a continuously-running intermediate resolver typically makes only a few hundred root queries per month. However, when a root server does see a query it usually sees the entire domain name that is being resolved.
It is this fact of the entire requested name that is important. The fact that queries are spread among different root servers and that many queries are handled by caches in intermediate resolvers only means that any data mining, manipulation, or attack must rely on probabilities and statistics. However, as will be mentioned later on, by "going recursive" and manipulating the TTL fields of responses, a root server can arrange for a greater portion of a target's queries to hit the roots. In addition, by becoming even more devious, a root server could, with the help of some cooperative name servers, capture an entire sub-tree of the DNS, for example, example.com, and usurp virtually all of the queries for a given sub-tree of the DNS. This latter aspect, while not very subtle and highly visible, does make root servers fairly powerful weapons of internet warfare.
Second is that during the startup phase of an intermediate DNS resolver there is an opportunity to misdirect that intermediate resolver to use a different suite of root servers. When an intermediate resolver uses its "hints" to discover a suite of root servers it will usually accept the answer from the first "hint" server that is willing to provide a purportedly authoritative list of purported root servers. This means that if you own a root server and you catch an intermediate resolver looking for the root (something not all that hard to recognize), with a little cooperation from other machines you control, you can mislead a victim resolver into believing that a bogus list of machines that you provide is a full and complete set of honest root servers.
Third is that DNS works in this way: In the absence of cached information, a user computer, or a resolver acting on its behalf, sends a query containing the full target domain name to a root server. Root servers are usually configured to answer only the TLD delegation portion of the query. In other words, root servers are usually configured to answer only that part of the query that pertains to items in the root zone itself. The phrase for this in DNS terminology is that the root servers are configured to be "non-recursive". Thus the root servers leave the job of walking through the hierarchy of DNS servers to the user's computer or a resolver acting on behalf of the user's computer. This is the usual mode of operation, but it is not mandatory - root servers could be configured to work through a full or partial sequence of pieces ("labels") of a DNS query. Most user computers or resolvers acting on their behalf would be happy to have the root servers give fully recursed answers. However, because of Verisign's Sitefinder, some DNS software has been modified to be suspicious of root or TLD servers that give out what seems to be too much information beyond that which was actually asked for.
We should not underestimate the degree of control that this kind of DNS manipulation makes possible. Through the mechanism of giving fully or partially recursed replies a root server could mislead user computers. In fact, with some careful staging of DNS responses in coordination with some cooperative servers and proxies, actual data traffic - web, VOIP, file transfers, etc. - could be redirected through proxies that examine, and perhaps even modify, the traffic.
So given these restrictions, which amount to a small peephole through which one can view and affect DNS queries and a somewhat thin reed of control, what kinds of things are possible?
Traffic Analysis/Data Mining
Want to know what's hot and what's not on the internet? Simply look at the number of DNS queries - hot websites (or hot VOIP phones) will be the subject of more queries than the those that are passé.
Root servers (and of course, TLD servers) are in a marvelous position to watch DNS queries and do relatively simple statistical data reduction to know, in a very short period of time, who is interested in what. The hardest part of the task would be to come up with a quantitative expression to compensate for the effects of DNS caching.
In the cyber-warfare context, I'm sure that the worthies over at national spook agencies would find it revealing to know what domain names "the enemy" is uttering.
Is there any wonder why Verisign is so hot to have a data mining provision in in the proposed ICANN-Versign agreement over .com? Imagine how much more interesting information one could obtain if he/she happened to have the ability to data-mine queries seen by a DNS root server? (By-the-way, Verisign runs two root servers [a.root-servers.net and j.root-servers.net]. I wonder whether the originator of SiteFinder might be predisposed to do some commercially lucrative data mining at the root level?)
Most people will immediately say - but the root servers don't seem very many queries. That's true. That's what statistics is all about, drawing broad conclusions from samples. But there's more - a server, be it a root or TLD server, can drive more traffic to itself by giving out small time-to-live (TTL) values. This will cause the caches in intermediary and end-user resolvers to time out more frequently and thus, more often, visit one of the root servers.
Differential Service
There's been a lot of talk recently about how telco providers want to impose differential grades of internet service. Rather than saying that they will make X go slow, they usually say that they will make Y go faster. But no matter the spin, it's still differential service.
DNS roots could easily give differential grades of service. Say, for example, that a root server operator is compelled by a government to give slow replies to queries coming from an disfavored region, or even to shut off service altogether during a period. As has been discussed in the IETF, any slowness in DNS is amplified many-fold by the time it reaches users and the applications they use: even small increases in DNS response time can accumulate, making the web web and other internet services sluggish.
I wonder whether the US considered this option during the cyber-warfare exercises it concluded this week?
Sewing Discord
Beyond differential service, a root server could give differential answers in an attempt to sew discord - it could send correct answers to friendlies and wrong answers to unfriendlies. These answers could occur as a result of the root server "going recursive" and handing back a completely wrong answer, or the answer could be more subtly altered, such as giving partially or fully incorrect delegation information, or exceedingly short TTLS (and thus inducing query thrashing) or exceeding long TTLs (and thus making it difficult for the domain name owner to propagate changes in its DNS records.)
(A very nasty thing to do would be for A or AAAA records in answers to contain loopback, broadcast, or multicast addresses. I used to do this to spammers via my least-preferred MX record.)
Or it could be even more subtle - a root server might cause DNS replies to be fragmented, or might set strange IP options, or might set the DNS "Truncation" bit, thus pushing intermediary resolvers to engage in far less efficient (TCP based) modes for making DNS queries. And if resolvers are pushed to use TCP rather than UDP for DNS queries, the root server might be slow about its TCP handshakes and slow to tear-down connections. Yes this would burn up protocol resources on the root, but it would also burn up resources on the victim resolver, which is likely to be unprepared to cope.
Active Misdirection
As I mentioned above, if a malevolent root server can catch an intermediate resolver during its boot-up sequence when it is roaming through its "hints" file trying to learn the servers that form a root, then that malevolent root could mislead that resolver into accepting an entirely divergent set of root servers. Suppose, for example, that we wanted to mislead much of the countries of Olliestan and Fredonia. The malevolent root server could then watch for queries of a form that suggest that a resolver is searching its hints and, in response, feed back a suite of records that define an entirely distinct set of root servers. As I've said before, this would be fairly obvious to those who are looking deeply into DNS, but if the faux-root provided reasonable answers for most things then many users would never notice. Suppose, for example, that the idea was to attack the VOIP/ENUM system of the target countries - the A records used by web and email might be left alone, but interference with the delegations for the enum tree, or "going recursive" and giving misleading answers for NAPTR and SRV records, could wreak havoc on voice calls.
A more subtle approach is to give wrong answers to specific queries. Foe example, if I knew that a particular query was the result of of a SIP INVITE leading to a VOIP phone call, the malevolent root could go recursive and give back an A record pointing to a proxy for the purpose of monitoring the phone call. Again, this could be difficult to arrange - it's hard to know the purpose of any particular DNS query for an A or AAAA record - but if some ancillary information were available to help distinguish the gold from the dross than a government might find this a useful surveillance technique.
Summary
Much of what I've just written may be hooey - but if I'm only half right, or even a quarter right, or even 10% right, then there is reason to be concerned that root (and TLD) servers be operated without manipulation.
And any country ought to be wondering whether root servers operated by governments of other countries are being manipulated in the interests of "national security".
Would any government unquestioningly accept the disclaimer of another government that the latter is not meddling with DNS root servers within it borders?
It seems to me that there is little that can be done to dispel suspicions of such activity, especially given the increasing dissonance between what governments (especially my own national government) say and what they do. Such concerns could easily drive the creation of national systems of roots - at least that would give each country some immunity, but certainly not total immunity, from threats arising from manipulation of foreign root servers.
The domain name industry has become a cesspool. One of the sewers is ICANN's "Add Grace" policy.
Under this policy people, generally very sleazy people, can buy a name, have it go live, and if they don't like what happens, they can relinquish the name and get some or all of their money back.
This has created a business in which domain vultures snap up deleted or un-renewed domain names, slap up an advertisement-filled web page to see whether there is a worthwhile amount of residual traffic. If not they take advantage of Add Grace and get their money back.
It's ICANN's way of subsidizing domain name churn and the underworld of people who want to make a buck off dead domain names.
Add Grace adds useless expense and complexity to the domain name registration systems - the sewer rats get away not paying, leaving the rest of us who buy names normally to pick up the costs. And the net ends up littered with advertising-covered domain name zombies.
Add Grace is a useless wart. Add Grace should be eliminated.
ICANN put it there, ICANN can remove it.
The new .com agreement, an agreement that is not yet approved, contains Add Grace. ICANN can start by removing Add Grace from the proposed .com agreement.
I'm not sure when this bit of legerdemain crept out of RFC3519 into ICANN's agreements - I know that when we on the board were talking about grace periods we were only talking about a grace period to help folks who forgot to get their renewals in on time.
Somebody's been mining the whois database, again - and who is it this time? Yahoo! Search Marketing.
How do I know? Because today a bit of junk snail-mail arrived from "Yahoo! Search Marketing" addressed to "Aggie Figueroa, Owner Cave Bear" .. at my home address.
So - Yahoo is mining the whois database. That's awful, and according to ICANN's rules, it is improper. But we all know that one of the unspoken reasons driving the industrial groups that support whois open access and deprecate privacy is to facilitate data mining.
But what makes this all the more ironic is that this bit of junk mail is from "Yahoo! Search Marketing" - their lack of competence shines through like the sun on a hot summer's day - their search and marketing capacity is apparently so feeble that they can't even get my name right when they mine the whois records. Who is Aggie Figueroa?
Do you think that I'd want to buy their services when they can't even properly address their junk mail?
I tend to read Bret Fausett's blog rather than listening to his podcasts - my six minute commute between home and my office is usually spent listening to the worlds best radio station, KPIG.
But back to what Bret wrote. I generally agree with him. But not always. And this is one of those times.
Recently he has had a conversation going about the creation of new Top Level Domains - in Bret's case he tends to qualify them as 'g' for general or generic - "gTLDs". I don't agree that that little 'g' is a meaningful distinction.
While I'll agree that some early internet choices caused the creation of TLDs related to countries and that there are a couple of TLDs that serve internet technical functions (e.g. in-addr.arpa), I find the whole idea that we have to know what a TLD is "for" or what it "means" to be deeply wrong.
In old days corporations used to have charters that said what they were to do. This caused a great deal of trouble (e.g. Credit Mobilier) or arbitrarily limited corporate activity (and thus forcing the creation of "trusts" a la Standard Oil under Rockefeller). Eventually we learned that corporate charters are silly; today corporations are allowed to engage in whatever businesses they like as long as they don't violate any laws and their shareholders not object.
But the whole TLD thing is based on this notion of charters and semantics, or rather the whole system of TLD regulation, which is what ICANN is all about, is based on some notion that ICANN must manage and control the charters and semantics of those who want to run a TLD or engage in the business of selling, and reselling, and re-re...selling names in those TLDs.
From where I sit the whole conception that we have a regulatory system, ICANN, that requires entrepreneurs to submit their domain name plans to ICANN for approval according to some arbitrary ICANN standard of domain name beauty and semantics is not merely wrong, it borders on the illegal - restraint of trade.
It is up to the entrepreneur, not ICANN the regulatory body, to create domain name brands and give (and change) the meaning of those brands.
Yet Bret and others seem to presume that it is appropriate for the internet regulator, ICANN, to manage the creation and meaning of internet TLD brands.
The internet does not need top-down or bottom-up or side-in regulation of TLD semantics and business plans.
Instead the internet needs the absence of regulation of TLD semantics and business plans.
ICANN ought to be blind to TLD names and semantics. The meaning or purpose of a TLD is no more of ICANN's business than flight attendant uniform styles are a matter for the Federal Aviation Administration (FAA).
I don't care, and neither should the ICANN regulatory system care, whether .com means commercial, comic, communist, or commotion. Nor should the ICANN regulatory system care whether my TLD, .ewe, or any other TLD, is going to be used by its customers for auctions, religious proselytization, or time travel.
All this talk about semantics and purposes of TLDs and domain names is a waste of time and an impediment to innovation - it's just the internet era's revival of centralized planning in the style of the old USSR's Five Year Plans.
ICANN, the e-Soviet.
ICANN should simply get out of the way and let the internet innovate.
The only thing that ICANN should review and evaluate when granting new TLD slots is whether the operator has sufficient skills to know how to abide by internet technical standards. ICANN should stop trying being a Guild of Internet Names; ICANN should stop trying to make the internet conform to its own image of what the internet should be.
It is not right to admit or deny TLD applicants their chance to succeed or fail based on ICANN, the internet regulator's, perception of gTLD name semantics.
(By-the-way, I don't agree that "presumptive renew" is the bit issue in the ICANN-Verisign contract. Rather I believe it is one of the big issues, but certainly not the only one. I find the permission to do data mining to be equally bad.)
I'm kinda foxed by the some of the discussion going on about "Net Neutrality".
The internet was designed from the outset not to be content neutral.
Even before there was an IP protocol there were precedence flags in the NCP packet headers.
And the IP (the Internet Protocol) has always had 8 bits that are there for the sole purpose of marking the precedence and type-of-service of each packet.
It has been well known since the 1970's that certain classes of traffic - particularly voice (and yes, there was voice on the internet even during the 1970's) - need special handling.
Voice-over-IP (VOIP) requires that networks not be neutral; if tiny VOIP packets have to fight against large HTTP packets for bandwidth and space in router/switch queues then conversational VOIP quality will be very poor and we may as well concede the voice game to the incumbent telcos.
Maybe the heat comes from the question of who gets to mark traffic as having precedence - the user or some provider?
But how can we trust users not to mark all their traffic as being of overriding high priority? But we begin to have the scent of provider-based priority marking if we don't trust the users and begin policing and admission control at the edges where the user's packets enter the internet.
Provider discrimination has already existed for a long time, often for purposes of self-protection or to induce better sharing of network resources. For example providers often disfavor and rate limit ICMP echo requests and replies. And router vendors offer things like "fair queuing" (a means to more equally distribute resources among flows) and "Random Early Drop" (RED) (a mechanism that actually throws away perfectly good packets in order to penalize over-aggressive flows and coerce them to perform socially acceptable TCP congestive back off.)
The RSVP and Integrated Services approach to end-to-end quality-of-service faded away in the face of provider resistance and the kind of inter-provider jealousy that is natural when providers compete with one another. And I haven't seen much reason to believe that end-to-end Diff-Serve packet markings actually survive end-to-end.
(Just before we were acquired by Cisco, I implemented a full functioned IP multicast based RSVP client. Woof! That was one seriously complicated protocol!)
What I'm getting at here is this: The internet was born with an element of discriminatory treatment of traffic, and there are good technical reasons why such discrimination is valuable, particularly for VOIP. So it would be plain wrong to say that the internet must be perfectly fair to all traffic. What we need is a line, a fuzzy line, that tells us when such discrimination moves out of the category of being useful and into the category of predatory.
My own sense is that this fuzzy line needs to be based on the idea that it is OK if done with the actual or implicit consent of the user (or users) and servers to improve whatever it is that they are using the internet for. But if it is done by providers for reasons divorced from self-protection (such as ICMP rate limiting) or to squeeze more dollars out of users or coerce their choice of providers, then the traffic discrimination is wrong.
Our guide in this should be the end-to-end principle and my own First Law of the Internet.