Our blog on the L root server received quite a few comments, both at our site and others (e.g, Slashdot, CircleID, CircleID, and various DNS newsgroups). Negative responses tended to follow a “no harm, no foul” line of reasoning, which sadly completely misses the point. So we’ll restate the central issue here again and talk about safeguards you can take today if you operate a DNS server or BGP-enabled router.
While there is no evidence of foul play with regard to the bogus L root servers, the duration of this event, the potential for mayhem, and the complete absence of any controls whatsoever should give us all reason for concern. Just think for a minute about what you could do with a root name server if you had evil intent. How about …
- Provide a new list of all root name servers when asked
- Provide new NS records for any or all TLDs
- Set TTL = 0 for all answers
- Perform recursion by default
- Log everything
- Censor or misdirect as desired
It shouldn’t be too hard to see that you could end up answering every DNS query from an organization that came to you for an updated list of root name servers. Every one. And you might end up doing this for a very long time, especially if your answers were largely correct. An attack like this would have no resemblance to the YouTube hijack, where the entire planet gets a blank page and it’s immediately apparent that something isn’t right. Obvious events like this will continue to occur, and we’ll continue to resolve them relatively quickly. But as this incident demonstrates, DNS hijacks are far less obvious and potentially far more harmful.
On a positive note, here is a quick list of things you can do today to try to guard against such problems. The operative word here is try. A miscreant could get around everything suggested here, but it is at least a start and we welcome more suggestions.
- Check the ICANN web site at least twice a year for root server changes.
- Check your cached root server IPs at least daily, automating a comparison to a known good list. Alert on any changes.
- Filter root name server prefixes by only allowing the appropriate originations and not allowing more-specifics. See the table below for the details.
- Globally monitor root name server announcements or encourage someone responsible to do so for you.
- Encourage someone (ICANN?) to publish a signed root name server registry. Use this registry to filter by authorized origins and upstreams,
instead of the table below.
I thought it would be easy to find an up-to-date list of originating ASes for the root name servers, but I came up empty. On the IANA site, I did find a reference to an authoritative hints file. And root-servers.org has a list of originations, but it is incomplete and out-of-date. If there is an authoritative list of root name server prefix announcements and originations, I couldn’t find it. So we used Renesys data to construct our own, which you’ll find below.
Here is how we constructed this table. We started by looking at each root server IP in turn, expressed as a /32, and then scanned a year’s worth of historical Renesys routing data from 28 May 2007 — 2008. For each /32, we looked for all less-specifics, up to a /8, that had been announced during the year and for the corresponding originating AS. Happily, the originating AS was typically invariant over the course of the year (although not always) and the typical announcement was a /24. A notable exception is D, which is announced only as a /16. F, I and K are also announced as /23s. For fun, we also added up the current total number of upstreams we see for each originating AS, providing those totals in the last column of the table. From these values, the anycast root servers are readily apparent (the ones with a large number of upstreams).
We’ll conclude by looking at some of the differences we observed over the past year from the values in the table. First, consider the announcements. Generally, for each /32, the only less-specifics that we saw during the entire year are given in the table. A, D, H, K, L and M were announced only as shown above, up to but not including the covering /8s. B, C, E, F, G, I and J saw very occasional and irrelevant covering prefixes such as 184.108.40.206/14, 220.127.116.11/11, 18.104.22.168/10 and 22.214.171.124/10. Only F saw a more-specific of their typical /24 announcement, namely, 126.96.36.199/25, but that was seen from the correct AS 3557, and only observed by a tiny fraction of our peers.
As for originations, A, C, D, E, J, K and L (the new one) had only those originations listed in the table over the past 12 months. Toward the end of last year, both F-root prefixes were announced for a time from AS 1280, which is also registered to ISC. On 19 March 2008, the I-root /24 stopped being announced from AS 29216 and started being announced from 8674. Then quite curiously, on 19 April 2008, we saw the I-root /24 announced from AS 2611, AS 8674, and AS 29216. AS 2611 is registered to Belnet in Belgium and their announcement of the I-root was seen worldwide for about 30 minutes. On 20 May 2007, the M-root /24 was briefly announced from AS 2500, which is also registered to the WIDE Project in Japan.
In conclusion, there has been a lot of discussion over the years about securing our DNS and BGP infrastructure via forklift upgrades to the planet. DNSsec, soBGP and sBGP should be familiar terms to many of you. Ten years on, we are still talking about it. How about starting with something more modest: an authoritative list of 13 critical IP addresses and their allowed origins and upstreams? It might not look like much, but it’s a start, and it could be put to immediate use by ISPs and DNS operators concerned about the integrity of the root name servers.