Fort N.O.C.'s Security in Obscurity

penciling_in writes "Brock N. Meeks of MSNBC reports on his recent visit to VeriSign's secret location: 'The unassuming building that houses the "A" root sits in a cluster of three others; the architecture looks as if it were lifted directly from a free clip art library. No signs or markers give a hint that the Internet's most precious computer is inside humming happily away in a hermetically sealed room. This building complex could be any of a 100,000 mini office parks littering middle class America.' The report goes on to say: 'Access to the Network Operations Center, the "NORAD" of the Internet's traffic monitoring, requires the electronic badge and then a double biometric hand print scan.' And here are Karl Auerbach and Robert Alberti offering their interesting analysis of this report on CircleID."

Comments

Re:How much physical security is necessary?

[cmowire]

In Australia in the past year or two, some folks dressed up as maintenence workers and drove off with an allegedly important government server.

So it does happen.

I still have to test every 5-pin simplex lock for important rooms to make sure that it's not a simple combination, because when I had access to a datacenter, it was a damn simple lock.

Re:sigh

[Zeinfeld]

No it doesn't. It talks about 3 "A" servers being available and predicts the death of the net if those three fail. In reality, it's got 12 other friends with the creative names B,C, ..., M, which are also serving the root-zone for the whole world.

In theory the B..M roots are fed from the A root so if they loose their update for 24 hours or so they could start shutting down. In practice the admins would soon clue up and they would just republish the last good update file they had received.

The problem comes with a bunch of pathological issues to do with what deployed DNS servers do if they cannot see root. It is not at all pretty.

Re:Why one place?

[karl.auerbach]

Many of the root server operators have deployed mirrors of their machines using "anycast".

Anycast is a way of using routing information so that a single IP address appears at many locations on the net. Packets flowing to an anycast IP address tend to go to the nearest instance of such an address.

Physical security isn't the risk that the roots face - the issue is damaged connectivity to those 13 addresses on which those root machines are to be found.

As I mentioned in my note on Circle-ID, the biggest risk isn't to root servers but rather to the set of servers that deliver .com, .net, .org, and .in-addr.arpa. The roots are heavily cached and easily replicated. It isn't quite so easy to handle a loss of connectivity to the big top level domain servers.

I've suggested a "DNS on a CDROM" (which I guess should be updated to "DNS on a DVD") in which all the stuff needed to get a local but limited DNS running in cases when a community has been cut off from the main body of DNS services.

Not exactly a dupe....

[stoolpigeon]

but here is the /. thread on this facility from March, 2002. http://slashdot.org/article.pl?sid=02/03/29/144922 8&mode=thread&tid=95

To be honest it is kind of embarassing that I immediately thought- "I just saw something just like this on slashdot not long ago" to find out it was almost 2 years ago. I didn't look at the new article close enough to see if there were any big differences over the years. To be honest the articles are spooky similar. Hmmmmm.

Wrong Architecture = More Fragile

[billstewart]

Anycast is a good approach for some kinds of problems, but fundamentally the A Root and the other rootservers are a more fragile environment than they should be because they're not using the hierarchichal nature of the DNS system appropriately. Last year's DDoS attack on them demonstrated some of this vulnerability. The Root Servers have three main jobs:

• Distributing the database to major servers (at least one machine from each of the 13 often-virtual root servers, plus the master DNS servers at the Tier 1 ISPs, the CCTLD servers, and some small number of other sites
• Answering DNS queries from the major servers
• Answering DNS queries from any random machine on the Internet

The system becomes performance-critical to lots of people because too many machines send queries to the root servers (or the .com and .net servers) instead of querying their ISP's DNS server, and too many small ISPs are also querying the root servers instead of their upstream's DNS server. DNS scales well because most information can live near the bottom of the net, and almost all queries can be resolved locally or nearby without have to go ask Jon Postel's ghost for the authoritative answer.

The root zone itself is probably under 10KB of data that doesn't change every day - if you provide a separate server for zone transfers and let 1000 other DNS servers have access to it (firewalled to prevent any other IP traffic), that's about half an hour on a 56kbps modem. Remember that all it's doing is answering good questions like "Where are .com's name servers?" "Where are .za's name servers", bad questions like "Where are .example,com's name servers?", "Where is 10.in-addr.arpa?" and ugly questions like "Where is Ping of Death?". Let the major servers handle most of the work, absorb the ugly packets and do some queries for bad packets, and let the general public query those anycast machines - they should be querying their ISPs' servers, or their upstreams', which cache the real information, and even when their queries aren't bogus, they shouldn't be blocking the internet-stability-critical traffic.

The .net, .com, and .org domains are a similar problem, except of course they aren't served by the root servers. The zones are much bigger, a few gigabytes size, but probably only 10% of it changes in any given month, or 99.9999% of the existing domains, which ought to be enough to call the Internet stable, using about 1 Mbps (10GB * 1%/day * 8 bits/byte / 24*60*60 ), and again, keep the public query traffic separate from the zone transfer traffic, and maybe offer a third set of DNS servers to answer queries from the big ISPs to handle things like newly created domain names. The reason to keep that kind of query traffic separate is to avoid attacks like "query bogus00001.com" "query bogus00002.com" ... etc.

Obvious flame-attracting discussion points:

• What about the Alternate Roots? They argued that there's no excuse for ICANN/versign/etc. to own the TLD space and PROFIT from selling names like *.sex. Fine - they can use my ideas for free :-)
• DJB likes rsync+ssh better. He might be right, but I'm trying to look at the small incremental change approach.
• This makes nic.big-ISP.net a much bigger target! It's already a target. They can apply the same approach recursively, plus their users can still query the roots, and they probably have a somewhat distributed architecture already.
• But the Internet is supposed to be any-to-any and this sounds like hierarchical corporate hegemony! Alas, too late for that, and if a 56kbps line can handle 1000 root zone transfers in half an hour, a T1 line should be able to handle 50,000 ok. Meanwhile, even covering the top 100 ISPs covers most of the Internet's users for stability.

98% of Root Server Queries are Unnecessary

[billstewart]

According to an October 2002 study, 98% of queries to the F Root Server (and therefore probably to the other root servers) are unnecessary. Either they're duplicates (75%) or they're for bogus TLDs (.localhost, .elvis, .corp, etc.) or they're in-addr.arpa queries for RFC1918 addresses, or they're some other bogus query, and they should have been served out of cache or handled by some ISP's DNS instead of bothering the roots. Maybe the A Root has some important functions, but they aren't what it spends its time on. And 50% of the queries come from about 220 servers - they should either be caching responses, or be shuffled off to some server that handles them (I guess anycast will help with this...) as well as cleaning up their act if they're broken, which some of them are.