Lead Scientist Responds to Questions on Root Server Queries

cidtoday writes "A CircleID interview with the lead scientist whose study recently revealed that 98% of a main root server queries are unnecessary, reveals that spam has little to do with the issue. In fact, he provides two reasons why anti-spam tools cause more unnecessary queries to the root servers than spam emails. Many other questions previously raised by Slashdot readers on the study are also answered."

Comments

Spam E-mail with broken links...

[$$$$$exyGal]

spam emails floating around in people's inboxes, many of which contain broken links that cause bad DNS lookups

Here's a link that lists how some spammers attempt to hide their real identities. This isn't necessarily exactly what the root server query guy was talking about, or maybe it is? Either way, it is very enlightening. Some slashdotters even occasionally try to hide a goatse link this way.

--sex

Never mind the roots...

[bourne]

It's BB&N... er, GTEI... er, Genuity that's getting pounded. They provide caching DNS servers to the entire Internet at 4.2.2.1 (.2, ...) and because they're so easily memorizable, I've never met a sysadmin who didn't put them in a hosts' configuration in a pinch.

Re:Never mind the roots...

[zerocool^]

Heh - anyone remember what the lookups to those used to be?

ns:root> host 4.2.2.1
1.2.2.4.in-addr.arpa domain name pointer vnsc-pri.sys.gtei.net.
ns:root> host 4.2.2.2
2.2.2.4.in-addr.arpa domain name pointer vnsc-bak.sys.gtei.net.
ns:root> host 4.2.2.3
3.2.2.4.in-addr.arpa domain name pointer vnsc-lc.sys.gtei.net.
ns:root> host 4.2.2.4
4.2.2.4.in-addr.arpa domain name pointer vnsc-pri-dsl.genuity.net.

4.2.2.4 used to be i.will.not.steal.dns.sys.gtei.net.

Now, that was an internet-wide easter egg!

Why are they not blocking queries from the abusers

[Jailbrekr]

If they can identify and quantify eplicit networks or IP addresses causing the 'abuse', then why don't they send a warning and then block them? They'll fix the problem real quick.....

How many can they actually handle.

[mestoph]

With all the talk that floats around, about every household electronic appliance having its own IP. And this also leading to companies adding everything as some kind of named host within in a home network i.e yourhomeaddress.personal.ps2.sony or yourhomeaddress.personal.microwave.bosh. What can root servers actually handle. I'd hate to see someone bring down a root server with a microwave oven, well without actually putting it in one :)

Re:This is amazing

[BeBoxer]

Our results showed that 50% of the root server traffic comes from only 220 IP addresses.

List, please? Hey Bush, forget about Iraq, let's take these bastards out. [grabs ak-47]

Remember that some of those are perfectly legitimate. Huge ISP's like AOL should be funneling all of their customers queries from a small number of IP addresses. That's the whole point. On the other hand, some of these are probably losers who are doing dictionary searches on domain names. You are likely to get blacklisted from the Whois servers if you try that. You won't get blacklisted from the DNS servers, it appears. But it should be easy to tell the difference between legitimate query streams and illegitimate ones.

So what?

[Jordy]

I don't understand why this is news or why it required any level of study.

The root servers handling zone '.' such as F.ROOT-SERVERS.NET put refresh periods of 48 hours on most every query. That means that at most once every 48 hours every name server on the planet should re-ask the root servers where to get answers for each of the gtlds, com, net, org, arpa, etc.

What they should receive the most queries for are domains that don't exist because everything else is cached for such a long period of time. That is the point of the root servers.

If the root servers are having trouble handling the query load then they should be upgraded for goodness sake. These are root servers after all and I think the global internet community could spare a few dollars to add some spare capacity if it is required.

To improve on this, BIND could up the maximum negative RR cache default time to live. Right now I believe it is set to 3 hours and the root servers use a 1 day SOA.MINIMUM instead, so BIND is always lowering it by default.

Of course, other nameservers are different. Some older versions of BIND by default only stored negative RR for 10 minutes.

Using ISP DNS servers is the right approach

[billstewart]

The root DNS servers shouldn't be bearing the bulk of the DNS load - the DNS servers at the Tier 1 ISPs (and also smaller ISPs, but especially Tier 1) should, and they should take care of many of the common queries, such as in-addr.arpa for the 192.168.*.*, 172.stuff.*.*, and 10.*.*.* domains, zone-transfer caching "." and ".com" so that those lookups don't need to hit the roots, etc. Also, while the Root Name Servers have a policy against accepting zone transfers from randoms, they really ought to have at least one server that either accepts zone transfers or at least some variant on FTP from registered addresses at the Tier 1 ISPs (The top ~25)and maybe at Tier 2 ISPs.

Also, the name servers get a surprising number of queries FROM RFC1918 addresses (10.x, 192.168.x, etc.), and while it may be more efficient to use root server CPU (on big fast computers) than router CPU to dispose of these queries, ISPs have ENTIRELY no business accepting IP packets FROM these addresses, and they should be killing them at the incoming edges of their networks, not carrying them and passing them on to other people.

Enhancing DNS protocols to offload servers?

[billstewart]

Most DNS queries get handled out of some kind of cache. While it's definitely important to be able to query your favorite root or alternate-root-like server when you really need to, you don't usually need to. If you ask your local vaguely-correctly-configured server for something, then ask it again before the expiration date, the first time it sees it it'l cache it, so the second time it can get it out of cache (unless the cache entry expired or the cache overflowed.) But if the entry's nonexistent, it's not likely to stick around the cache. So there's a need for a standard way to respond to well-known non-existent names, so the cache has something to keep for popular bogus queries. Obviously "localhost" is "127.0.0.1", and "example.com" can be just about anything not in use but might as well be 127.0.0.1, but it'd be nice if there were some other standard value to use. Maybe 127.0.0.0 or 127.255.255.255 (e.g. yell at yourself :-) ?