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

Re:Lead Scientist

[JPriest]

Why is this +5 Funny, how lame.

Eh??!

[FyRE666]

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...

So Spam has little to do with extra traffic, but the wealth of tools fighting against spam are adding to the load, right? But then since spam is the reason anti-spam tools exist, it's fair to say spam is the root cause of the problem!

Re:Eh??!

[BeBoxer]

Actually, most War On (Some)Drugs supporters could tell you that with a straight face and not bat an eyelash. Most of them could then go on and tell you that any innocent Iraqi's killed by American bombs are actually Hussein's responsibility, and conclude by explaining that victims of spouse abuse are responsible for their plight because a good beating was the only response to their poor behavior.

Re:Why are they not blocking queries from the abus

[boots@work]

Hello Troll,

On what grounds would they win in court? Seems to me they don't have a contract (express or implied) with the root server operators, and therefore no standing to sue.

You can't just randomly block abusers.

"Just watch me."

Either you have to offer DS services to everyone, or no one, or you have to start charging per lookup.

Not at all. "Management reserves the right to refuse service."

I agree that blocking them is probably too simplistic to be useful, but you're wrong about there being anything legally wrong with it.

That's a worse idea

[billstewart]

Yes, definitely, set your DHCP servers to tell clients about your company's DNS servers, and do a good job of maintaining your DNS serves so they work well. But sometimes people want to ask other servers what's going on, especially if they're trying to track down detailed authoritative information about a name from the real name servers for that name - or it they're spam hunting.

Anti-spam causing problems?

[blowdart]

Many anti-spam tools verify "From" addresses and perhaps other fields. If the From address has an invalid hostname, such as "spam.my.domain," the root servers will see more requests, because the top level domain does not exist.

DNS lookups on the sender address was common before there was a major spam problem. It makes sense, why would you want to take email from somewhere you cannot reply to? So I don't think you can blame anti-spam tools for this.

Anti-spam tools also make various checks on the IP address of the connecting client -- for example, the various "realtime blackhole lists" and basic in-addr.arpa checks.

in-addr.arpa checks has been a standard practice in networking software, not just email, since it was available. Some FTP servers do it, some web servers do it, your web log analyzer does it, IRC does it. You can't put that one onto anti-spam tools either.

The use of dnsBL lists will, of course, create extra load, when you look up the name servers for the list(s) you are using. But in all likelihood the NS and A records are cached at your local server. You're not hitting the root server with every lookup.

This guy seems full of bull. Note that he is not a LEAD scientist for the root servers, he's a lead scientist for the company that produced the report.

DNS load from anti-spam systems is avoidable

[bigberk]

I really think that one of the very nice things happening in anti-spam these days is the increasing use of local, independent processing power rather than centralized network queries (like realtime blacklists).

A growing number of projects are implementing Bayesian filtering techniques for example. I personally love spamprobe, but there are many others. Some, like spamprobe go server side and others are even client-side. They work equally well by filtering spam based examples you train it with. In the 4 months I've been using it, I've achieved 97.6% accuracy. And no DNS queries, no load to any other site but my disk & CPU.

Anyway, the advantage of this sort of filtering is that you do all the decision making locally, and no data flies across the internet. Remember, what we have in abundance is processing power. But network resources should be conserved.

Re:even better idea

[ftobin]

Yes, let's destroy more of the fundamental end-to-end principles of the net.

</sarcasm>

Man, I can't wait for ubiquitous host-to-host IPsec, so these content-based filters are thwarted.

Re:Using ISP DNS servers is the right approach

[versus]

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.

I really doubt root servers get queries FROM RFC1918 adresses. Every sane ISP blocks all such packets(not only DNS queries) on its border routers - ore else there will be much more spoofed packets around here. I work at ISP and usually all that NAT'ed machines that use our DNS are quering us about x.x.168.192.in-addr.arpa