|
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.
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byCSC
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byDNIB.com
The potential for abuse or mismanagement of this could be huge, just like the baffling decisions made on an almost daily basis by automated spam blackhole submissions.
Who makes the decision that my company’s domain should be yanked from the Internet? RegisterFly? Was Gator a legit business or scourge of the earth (and who gets to decide)? What happens the first time an Akamai client does something weird and the akadns.net domain comes under scrutiny?
If the market wants this, then services like SiteFinder or OpenDNS (not that I’m equating the two) or some third party reputation service should flourish. But building human judgement of this kind into a public infrastructure seems like a recipe for disaster. That’s my 2 cents anyway.
Alternate solution: Have the roots only allow registrars to make domain changes twice every 24 hours. The roots should be proactive rather than reactive. The 24/2 time period would allow ample time for security teams to communicate and react to bad behavior.
While you touch on cache issues, you don’t mention that cache issues are why things like this have been proposed before and failed. In the current scheme of things, the bad folks will be motivated to 0wn resolvers or do what they are already doing and point 0wned machines to their preferred resolvers. Adding ineffective layers of ongoing O&M is a job for ATM-heads and their ilk, not packet-heads.
I remain unconvinced that rapid-registration was ever nescessary or desirable. I opposed it from the start and to date have seen no good come from it. I’d be glad to be proved wrong.
After reading the comments above as well as the long thread(s) on Nanog, I’m pretty well convinced that this circuit breaker idea is really full of sharp edges and dangerous corners.
But the question still remains in my mind: Do we need mechanisms such as this that can be invoked should something really catastrophic happen? (I agree that the definition of “catastrophic” is itself far too vague for comfort.)
Right now individual packet carriers can null route things without asking any permission. Is there a place for something similar in DNS and other deep-infrastructure components of the net? My own sense is that the answer is “yes, maybe” but that the difficulty is how to safely control who uses it and when.
As for the mechanisms through which a domain name owner can update their name server information or have a new name installed within a few (10?) minutes:
As for myself, I know that on a few occassions during the last couple of decades I have needed to update my NS records really fast - it was usually something that was accompanied by the smell of burning electronics from a machine that had seriously gone south.
So I sense that there is an operational need for quick NS updates (modulo the fact that TTLs probably won’t be tuned down before the mess happens.)
As for quick registrations of new names: I have seen the discussion over on Nanog about having a 24 hour waiting period in which somebody, somehow, under some criteria, and with some unknwon source covering the cost, evaluates the registration for bogosity.
Even if such an evaluation were feasible I’m not sure whether this would be too much of a step backwards to be accepted by those in the business of selling DNS names.
As for the tasters and their 5-day free use: I agree that this is a source of difficulty, if only because that load appears to be the vastly dominant burden on the registration systems. But I’m not sure that the “tasters” would be bothered if they had to wait 24 hours before pasting up their advertisement laden web pages as long as that 24 hours did not cut into their 5 day free trial period. (Personally I think the free 5-day trial periods are repugnant and would be happy to see ‘em disappear altoghether.)
The things required to fix the problem, such as it is, are a) improved credit card verification processes and b) more efficient business processes. In fact, those -are- the problem (the issues you discuss in the article are merely symptoms).
In terms of domain suspension, it seems to me that if there’s a need for it, this function plus a lot of other useful functions would be served by registrars either participating in existing mitigation communities or forming their own and sharing information with those other mitigation communities.
It seems that the suggestion here is to insert a DNS “circuit breaker” to solve a problem that exists completely outside the DNS. The problem with DNS, if anything, is that it provides too good a service, and bad people are using that good service to facilitate bad deeds.
In general, I think it’s inappropriate to react to this abuse by degrading the good service. Literal circuit breakers exist to prevent the service itself—a system of current-carrying electric conductors—from overheating, catching fire, and burning down the surrounding infrastructure. As far as I can tell, it’s not the DNS infrastructure that’s in danger of burning down here, and thus the circuit breaker seems misplaced.
Granted, the DNS is providing some of the “current” that’s causing the rest of the system to go up in flames. The bad people are using the DNS to facilitate their bad actions—that’s why a DNS circuit breaker was suggested at all—but anticipate what happens if you put a perfectly effective DNS circuit breaker in place: the bad people shift from using DNS to using some other method that’s even harder to counteract, such as a peer to peer system. We’re then left with the same old problem, and a perfectly unnecessary DNS circuit breaker.
Can the bad guys do this? Sure. They have the financial motivation to do so, and there is a pool of sufficiently capable programmers who are willing to sell out at the right price. Would they do it? Hell yeah. I think it’s obvious by now that the bot-herders, spammers and phishers of this world won’t give up that easily.
So the problem with a DNS circuit breaker is that it will be rendered useless shortly after installation. Whatever unpleasant side-effects it has will continue to linger, however. No doubt it will have “false positives”. All in all, the world will be a worse place. Actually, come to think of it, the DNS circuit breaker idea reminds me of a certain “no fly list” response to terrorism. I wonder how the David Nelsons of the world are coping with air travel in or to the USA these days.