There are a lot of bad, but smart, people out there on the net.
They are quick to find and capitalize on vulnerabilities, particularly those vulnerabilities in mass market software.
These bad folks are quite creative when it comes to making it hard to locate and shutdown the computers involved.
For example, a virus that takes over a victim's computer might communicate with its control point, or send its captured/stolen information, by looking up a domain name. Normally domain names are somewhat static - the addresses they map to don't change very frequently - typically changes occur over periods measured in months or longer.
What the bad folks are doing is to change the meaning of those domain names very rapidly, from minute to minute, thus shifting the control point. They rapidly change the contents of DNS records in the authoritative servers for that domain. They couple this with low TTL (time-to-live) values on DNS information, thus preventing cached information from surviving very long and thus erasing one source of audit trails and covering their tracks.
To restate this perhaps more clearly - the bad people are not changing the domain name itself but rather they are rapidly changing the address information that the domain name represents.
The bad folks go even further by using the same technique to jump the name servers used for the domain. This makes it even harder to get a handle on the attack and suppress it.
So what we may hear being proposed soon is the need for a domain name based circuit breaker for the internet. This is not my idea; it comes from others who are on the front lines fighting against the increasing number of distributed network viruses and botnets.
This circuit breaker would be an emergency removal of a domain name, such as example.com, from the top level zone file. In the case of example.com this would mean that "example" would be removed from the .com zone.
This would prevent this rapid shifting of A and NS records. In fact it would make the domain not resolvable at all (except via cached information, which would rapidly fade out of view because of the short TTL values.
The circuit breaker would be triggered when a second level domain name, e.g. example.com, is found that is being manipulated in this pathological way in support of a net attack and when no responsible party can be found who would take control of that domain and make the appropriate repairs.
The mechanism of the circuit breaker would be for the registry for the top level domain involved to pull the name from its zone file, essentially putting that domain offline.
Because the delegation records from a TLD to a second level domain typically have relatively long TTLs, it might take a while, several days, for the delegation to entirely fade out of view. However, because typical TLD contents are rather large, it is unlikely that more than a small percentage of resolver caches will continue to believe that the revoked domain name is still there until their cached records time out. So, even though the circuit breaker would be imperfect, it would still act as a very strong supressant.
Revoking a name, even if only on a temporary basis, is a significant act that is not only capable of causing a lot of harm to innocent internet bystanders, but it is also a mechanism, like the stop cord on a train, that could be used as a denial-of-service mechanism. Consequently the handle on this circuit breaker would, much like the button that launches nuclear missiles, need to be extremely well protected against accidental, mistaken, or unilateral use.
It seems to me that it would be useful for our internet DNS infrastructure to have such a mechanism. This is the kind of thing that squarely falls into ICANN's job of protecting internet stability. And it is the kind of thing that ICANN could deploy via its contractual relationships with the top level domain registries.
I've been chatting with others about ICANN current and future legal structure over on Susan Crawford's blog .
Clearly I am not in Lisbon at YAIM - Yet Another ICANN Meeting.
Instead I am sitting (or rather, I was sitting a few hours ago) on a California beach, at the mouth of the Big Sur River, doing nothing at all. Very, very nice.
It would be nice if ICANN were to hold a meeting in the place where it chose to have its legal existance.
The "whois" system for domain names is the single greatest violation of privacy rights on the internet.
A reasonable cure has been put forth that would require only that domain name registrants designate a contact, who could be an agent, to receive communications pertaining to the technical operation of the domain. This is not unlike the way that corporations keep much of their structure private by designating an agent for the receipt of legal notices. ICANN and Verisign both do this.
The industry that protects intellectual property (not to be confused with the industry that creates intellectual property) does not like this proposal; they would prefer that every person go naked on the internet, with their names and numbers tattooed to their chests, and live in glass houses.
The trademark industry wants domain name registrants to reveal their information, and that of their families and children, to the anonymous predators of the world on a 24x7 basis.
The trademark industry will allow but one exception - if a person claims sanctuary on the basis of "special circumstance". What this means is that a few shelters for bettered women might be allowed to refrain from publishing their contact information.
This "special circumstances" proposal is contrary to one of the most fundamental tenets of modern society, that a person is presumed innocent until proven guilty. The "special circumstances" proposal is nothing short of a systematic conclusion that you and I and every other domain name registrant is to be presumed to be a thief and unworthy of privacy. The burden is placed not only on us to rebut that presumption but to do so in advance even of an accusation.
We are being told in no uncertain terms that our privacy, and that of our families and children, is worth less than a trademark.
The "special circumstances" shoe should be put on the other foot. If a trademark owner wants to penetrate the privacy of the Whois data that owner should be obligated to make a specific accusation, saying on a permanent public record, what rights of that owner are being violated by the accused domain name owner and what facts exist to support that accusation.
In other words, the trademark owner should be required to demonstate, with concrete accusations backed by concrete facts, that special circumstances exist that are sufficient to violate a person's right to privacy.
We have seen how the music and movie vigilantes, the RIAA and MPOA, have run amok making groundless accusations against thousands of innocent people. These are the law-firm office mates of the trademark people who want to violate our privacy in our domain names. There is much reason to be skeptical of their intentions.
Have you noticed that ICANN's logo is confusingly similar to that of the San Jose International Airport?
Dazed and confused travellers must arrive daily at ICANN in Marina del Rey thinking that they are at the San Jose Airport.
In order to prevent this trademark travesty ICANN ought to change its logo.
I suggest that ICANN adopt a sketch of the Laocoon, a very famous classical sculpture housed in the Vatican museum in Rome.
The sculpture depicts Laocoon, who is famous for warning the Trojans to beware of the Trojan Horse, and his two sons being squeezed and strangeled by a pair of serpents sent by Poseidon who, favoring the Greeks over the Trojans, was angered that his side's secret plan was being endangered.
In ICANN's case, the primary figure represents Imagination and the two sons would be Innovation and Enterprise. The two serpents represent ICANN's primary beneficiaries: the domain name registries and the intellectual property protection (as opposed to the intellectual property creation) industry.
I have long been intrigued by the question of how do we turn the internet into a lifeline grade infrastructure. (See, for example my presentation From Barnstorming to Boeing - Transforming the Internet Into a Lifeline Utility (powerpoint) [with speakers notes - Adobe Acrobat format].)
My hope that this will occur soon or even within decades is diminishing.
Most of us observe, almost daily, how even well established infrastructures tend to crumble when stressed, even slightly. For example, even something as small and foreseeable as a typo in someone's name or SSN number during a medical visit can generate months of grief when dealing with insurance companies.
I was at the O'Reilly Etel conference last week. The content was impressive and the people there were frequently the primary actors in the creation and deployment of VOIP. However, not once during the three days did I hear a serious discussion by a speaker or in the hallways about how this evolving system would be managed, monitored, diagnosed, or repaired.
My mailbox is being filled with IETF announcements for the upcoming meeting in Prague. I see internet draft after internet draft making proposals that are going to cause implementation errors, security holes, and ultimately service outages.
Take for example the prime candidate protocol for VOIP - SIP.
I've spoken to many people who have implemented SIP components. There is a common theme - that SIP is far too complex. Even the basic encoding method is a mess - apparently the SIP working group could not agree among alternatives, so like most committees, they comprised by allowing all alternatives. The result is that the SIP implementer has to write code to handle many different representations of exactly the same information. That means that there will probably be code paths that are insufficiently, or never, tested. It also means that SIP systems will probably be susceptible to failure or misbehavior when introduced, perhaps years after initial instillation, to new SIP devices based on different SIP engines.
And to top that off, many of the new proposals for SIP use completely different encoding methods (the darling of the moment is XML) from the textual ASCII/UTF8 form used in the core parts of SIP. Implementers are going to go gray from the stress of trying to make this mish-mosh work. And people who have to maintain and troubleshoot VOIP will go bleary eyed and take hours longer to resolve outages than they would had there been a consistent and uniform design.
There is a lot of talk about the benefits of network effects, but few people talk about how those same network effects lock-in the work of the past and make it difficult, perhaps impossible, to evolve to new and improved mechanisms.
History often survives and reaches out through very long periods of time. It has been said that the size of modern day airplanes are derived from the width of the Roman horse: The width of the horse dictated the spacing of wheels on Roman carts. Those carts created standardized ruts that coerced other carts to conform through the ages. Early railroads, adopting carts, spaced the rails one-rut-pair width apart. That width dictated cargo load size. The need to carry those cargos has affected airplane design.
Consider how long it has taken to deploy IPv6 - a technology that celebrated its 10th anniversary a few years ago. And IPv6 has the luxury of being an alternative to IPv4 rather than a transparently compatible upgrade. Consider how much longer it will take to deploy VOIP protocol redesigns when the old protocol is embedded in telephones around the world?
We have to admire old Ma Bell for building a reliable and maintainable system. Yes, it took a 100 years of work - and modern telco phones, particularly on the local loop, use a lot of technology created in the late 1800's.
You would have thought that in this internet age that we might have learned that clarity of internet protocol design is a great virtue and that management, diagnostics, and security are not afterthoughts but primary design goals.
There is a lot of noise out there about internet stability. And a lot of people and businesses are risking their actual and economic well being on the net, and the applications layered on it, really being stable and reliable.
But I have great concern that our approach to the internet resembles a high pillar of round stones piled on top of other round stones - we should not be surprised when it begins to wobble and then falls to the ground.
I am beginning to foresee a future internet in which people involved in management, troubleshooting, and repair are engaged in a Sisyphean effort to provide service in the face of increasingly non-unified design of internet protocols. And in that future, users will have to learn to expect outages and become accustomed to dealing with service provider customer service "associates" whose main job is to buy time to keep customers from rioting while the technical repair team tries to figure out what happened, where it happened, and what to do about it.
It is good that ICANN has prepared a "fact sheet" about the recent attacks on DNS root servers. Personally I would have preferred something with a lot more technical substance and less of a tutorial, but this is a lot better than nothing.
However, there are a couple of points to note.
First, and most importantly, by publishing this document ICANN is implicitly making a statement that ICANN has something to do with the technical stability and robustness of the primary system of DNS roots. Much as many at ICANN might want to believe that such is the case, in reality ICANN has divorced itself from such matters and they have fallen, by default, to the independent root server operators.
In other words, when it comes to the actual operational technical reliability and security of root layer DNS, ICANN is a mere observer not a principal.
Second is that the credit for deploying anycast technology goes to the root server operators, not to ICANN.
(When I was on ICANN's board (which was pre-anycast of DNS roots) I tried to raise the question of whether ICANN should encourage experiments with this technology. I was met with an institutional yawn.)
