Perhaps this example, involving "www.nasa.gov", will make the dependences more clear. It is true that parent servers cache and forward IP addresses, in so called "glue records." But the glue does expire occasionally and the parents need to perform occasional lookups. These are the periods of vulnerability that an attacker would take advantage of to propagate bad bindings.
As we point out in the paper, the vulnerabilities all depend on the shape of the dependence graph. You keep pointing out that high fanout improves security. In practice, DNS dependence graphs tend to be long and narrow, with small cuts. An attacker that owns a cut can hijack a domain. The paper has the details on the size of typical graph cuts.
I'm the speaker that the article is talking about. I head a research group at Cornell looking at building more resilient Internet infrastructure. Let me say a few words about this study and our recent IMC paper:
This survey was a lot of fun. It's sort of like a "how to 0wn the Internet via DNS" survey. In fact, that was the subtitle of my talk and was the most fun academic paper I ever wrote. It's all based on public information, by the way. The findings were quite surprising, at least to us.
First, the average DNS name depends on a large number of nameservers. Not just the two or three nameservers that you designate when you register the name, but also the nameservers those servers are served by, and so on. This set includes a few dozen hosts for the average.COM domain. If you are in the Ukraine, Malaysia, Poland, or Italy, this set includes more than 400 hosts! In contrast, Japan (.jp) is run very well, and names in.jp depend on very few hosts.
Second, some names are incredibly vulnerable. The most vulnerable name in our survey, the Roman Catholic Church web site in the Ukraine, depends on servers in
Berkeley, NYU, UCLA, Russia, Poland, Sweden, Norway, Germany, Austria, France , England, Canada, Israel, and Australia. It's possible to take over that Ukrainian website (and announce a new pope, perhaps?) by compromising a host in Monash, Australia. DNS makes a small world after all.
Typically, you can find some compromised hosts in the dependence graph, DoS the non-vulnerable hosts for a very short time when DNS glue is about to expire, and poison caches. Repeat and rinse until you have hijacked the name of your choice.
Finally, some nameservers are very valuable, they control a large percentage of names. Some of these valuable nameservers are in educational institutions, which have no fiduciary responsibility to the names they serve. In fact, folks at NYU may not be aware that they can control the entire namespace for Baltic countries under the right circumstances.
Interestingly, the FBI.GOV site was vulnerable. We reported this to the DHS and someone upgraded the nameserver involved. We suspect the vulnerability we found was a real one, though we did not attempt to take advantage of it so we can't tell for sure.
Our website has an active webserver where you can type in your favorite sitename, see its dependencies and vulnerabilities. The data is a snapshot we took when we performed this study; do not be surprised if it does not reflect changes you made in the last few months.
The takeaway from this study is that the conventional wisdom about DNS servers, which says "the more DNS servers you have, the merrier as you increase fault tolerance" is wrong. You increase fault tolerance at the cost of increasing your trusted computing base. If you don't pay attention, someone from Monash Australia can hijack your site, and you might not even notice.
Slashdot Mirror
Perhaps this example, involving "www.nasa.gov", will make the dependences more clear. It is true that parent servers cache and forward IP addresses, in so called "glue records." But the glue does expire occasionally and the parents need to perform occasional lookups. These are the periods of vulnerability that an attacker would take advantage of to propagate bad bindings.
As we point out in the paper, the vulnerabilities all depend on the shape of the dependence graph. You keep pointing out that high fanout improves security. In practice, DNS dependence graphs tend to be long and narrow, with small cuts. An attacker that owns a cut can hijack a domain. The paper has the details on the size of typical graph cuts.
This survey was a lot of fun. It's sort of like a "how to 0wn the Internet via DNS" survey. In fact, that was the subtitle of my talk and was the most fun academic paper I ever wrote. It's all based on public information, by the way. The findings were quite surprising, at least to us.
First, the average DNS name depends on a large number of nameservers. Not just the two or three nameservers that you designate when you register the name, but also the nameservers those servers are served by, and so on. This set includes a few dozen hosts for the average .COM domain. If you are in the Ukraine, Malaysia, Poland, or Italy, this set includes more than 400 hosts! In contrast, Japan (.jp) is run very well, and names in .jp depend on very few hosts.
Second, some names are incredibly vulnerable. The most vulnerable name in our survey, the Roman Catholic Church web site in the Ukraine, depends on servers in Berkeley, NYU, UCLA, Russia, Poland, Sweden, Norway, Germany, Austria, France , England, Canada, Israel, and Australia. It's possible to take over that Ukrainian website (and announce a new pope, perhaps?) by compromising a host in Monash, Australia. DNS makes a small world after all.
Typically, you can find some compromised hosts in the dependence graph, DoS the non-vulnerable hosts for a very short time when DNS glue is about to expire, and poison caches. Repeat and rinse until you have hijacked the name of your choice.
Finally, some nameservers are very valuable, they control a large percentage of names. Some of these valuable nameservers are in educational institutions, which have no fiduciary responsibility to the names they serve. In fact, folks at NYU may not be aware that they can control the entire namespace for Baltic countries under the right circumstances.
Interestingly, the FBI.GOV site was vulnerable. We reported this to the DHS and someone upgraded the nameserver involved. We suspect the vulnerability we found was a real one, though we did not attempt to take advantage of it so we can't tell for sure.
Our website has an active webserver where you can type in your favorite sitename, see its dependencies and vulnerabilities. The data is a snapshot we took when we performed this study; do not be surprised if it does not reflect changes you made in the last few months.
The takeaway from this study is that the conventional wisdom about DNS servers, which says "the more DNS servers you have, the merrier as you increase fault tolerance" is wrong. You increase fault tolerance at the cost of increasing your trusted computing base. If you don't pay attention, someone from Monash Australia can hijack your site, and you might not even notice.
My research group generally looks at how to build more resilient infrastructure services. We built a safety net for DNS, a system for monitoring updates on the web, and a system for avoiding SPAM on P2P filesharing networks. Check them out if you are interested in new distributed services for the Internet.