and you run which TLD?

el

I think a big chunk of it is that when you are doing a job you don’t think to write down what you actually do in that job. Just getting on with it is enough.

I will ask about, see if the root server operators are willing to compile this – even if the information can’t be released until a future date.

Kieren

Write them down in a well thought through document that stands up to review.

The place for development of Internet standards of this type is through the Internet Engineering Task Force (http://www.ietf.org.)

A blog page is definitely not the place for documenting such things.

There are two relevant working groups at the IETF:

In the “Internet” area there is DNS extensions

http://www.ietf.org/html.charters/dnsext-charter.html

In the “Operations and Management” area there is DNS operations:

http://www.ietf.org/html.charters/dnsop-charter.html

I look forward to reading the drafts when they are written.

I for one also look forward to seeing more people contributing. Remember that well thought out and documented solutions tend to get the most traction.

This is of historical importance and should be documented

Thanx

Hackers likely have little chance of taking down the global telephone system (although as it moves to IP over time, you never know). But, global satellites, sending out signed 20 KB burts every few hours — probably orders of magnitude harder to take down (unless the Chinese use their latest gizmos to knock down all the satellites, but if they did we’d have bigger things to worry about, like global thermonuclear war). Shortwave radio would be another alternative (whatever’s most cost-effective).

By the way, was it wise for ICANN to explain in so much detail (i.e. the large packet sizes that were dropped) how the attack was blocked? Why not just publish a hacker’s guide, “Yes, guys, please use random smaller packet sizes next time, to make filtering less trivial.” Security by obscurity isn’t great either, but perhaps be a little less giving until all the anycast systems are rolled out.

Against this kind of attack Anycast is clearly very useful.

Had the attackers attacked say the Anycast routing protocol in some way rather than the root DNS servers, the result may have been quite different, and I’d now be arguing with should keep Anycast server because they are useful against DDoS attacks.

It is like concluding that because aircraft won the Battle of Britain, Britain no longer needs a Navy. Not having Anycast for some root servers is a diversity issue. This attack didn’t suggest that diversity is bad. That will come when someone compromises one of the root servers

I still believe that the root-server model is basically flawed. Root zone is a 20KB file compressed. If every caching name server were to grab a copy of this file from the root servers, a whole compressed copy every 2 days, and if there were 4 billion recursive name servers, then the total traffic would be similar in magnitude to this attack (4Gbps). Of course we have protocols that allow us to send only what has changed (ixfr, or rsync spring to mind), when it has changed. With that, and realistic figures for the number of recursive servers, one could retire most of the current root servers With a digitally signed root zone file, we don’t even care how it gets to the recursive servers, ICANN could get away with a copy of GNUPG, and a selection of dial-up accounts (in case one is down or attacked), and a peer to peer file transfer system, would be sufficient to fulfill the technical requirement of distributing the root zone file.

Slaving the root zone on recursive name servers is a performance win, and could be a security win if ICANN put a digitally signed copy of the zone somewhere accessible, since then people wouldn’t have to rely on the integrity of the many root server operators, their servers, staff etc. Just the integrity of ICANN, their zone file, and their ability to keep the privates keys private, and strong cryptography. Much of which we have to rely on anyway for them to correctly update the existing root zone.

The reason we have the the multiple servers and the anycast scenarios is exactly to prevent this scenario.

There is a theory that a signed zone (dnssec) may make local copies much more practical, although still the issue of ensuring that up to date data is used is still critical.

If there is a well published alternative mechanism, that will be just as subject to attack as the servers themselves and likely less easy to harden,

The good news from the recent attack is that even though gigabytes of extra requests were being sent to the servers the anycast solutions put into place by many of the operators were effective.

If you believe there is a better protocol/method for improving resilliency then I would suggest taking the time to write them in a document and publishing them through the RFC process.

My point was that you took a straight piece about the DNS attack and the root server systems to somehow launch into a wild and barely connected future conspiracy — extrapolation on acid.

I should apologise here – you ran foul of our spam removal software by writing too many comments in too short a period of time. This is classic spamming behaviour and the software, once it recognises an offender, then works retrospectively and removes other comments from that IP address.

So you triggered something and the software killed your comments but I’ve been through it manually and they should all now be back up.

Kieren

John: I didn’t claim that the root zone changes once a month — I was doing a hypothetical, i.e. if the root zone had last changed X days ago, but one’s cache was recently updated Y days ago, and Y was less than X, then the results from using the cached copy would be 100% identical as the “live” copy, even if we weren’t within the actual TTL specified by the zone file. Sorry if I confused anyone by using made up numbers, instead of “X” and “Y”.

I don’t get paid to compile zone file diffs (if some researcher or staffer has the time, be my guest), but it should be fairly evident that most major TLD operators would not be changing their nameservers each and every 12 hours…..if they are, they shouldn’t be running that TLD. One can use domaintools.com to see how often nameserver changes are done by corporate websites (I already gave examples for icann.org and verisign.com — as a third, http://whois.domaintools.com/godaddy.com reveals that GoDaddy had 2 unique nameservers in the past 3 years), i.e. 2nd level, below the TLDs, and I’m confident the 1st level (i.e. the TLDs themselves, that appear in the root zone file) change even less. It would be an odd network indeed if things changed more frequently as we moved UP the hierarchical DNS tree — that’s the opposite of stability. The most frequent changes will be at the bottom levels, not the top.

I’m glad we agree on caching. Of course if one root server is operating, the cached data can be updated. But, suppose they’re all down? Is it the end of the world? Probably not, since if the stale cache was used (i.e. like using a 2004 phonebook, instead of a 2007 phonebook), the odds are pretty good that you’ll likely still reach the person at the published number.

If BitTorrent, RSS, FTP, or other technologies are used, one could make the system even more resilient. e.g. one can imaging a version of bind or similar software that is caching the root that has pseudocode like:

“if all root servers are down, try to get fresher copy via FTP; if FTP fails, try HTTP; if HTTP fails, try BitTorrent, if BitTorrent fails (then the internet is probably really messed up!), try dialing the secret phone number to a hypothetical dialup system, given only to big ISPs; if the dialup fails, keep trying and notify administrator). Indeed, if the diffs were small enough, one could even publish them in newspapers (like the WSJ).