Slashdot Mirror
98% of DNS Queries at the Root Level are Unnecessary
LEPP writes "Scientists at the San Diego Supercomputer Centerfound that 98% of the DNS queries at the root level are unnecessary. This doesn't even take into account the 99.9% of web pages suck or are unnecessary anyways. This means that the remaining 2% of necessary DNS queries are probably not necessary either."
Just my 2p/2 worth.
Matt Thompson - Actuality - Insert product here.
is it that hard to configure a firewall to explicitly allow outgoing traffic rather than allow all? It seems that everyone thinks that the only bad traffic is the stuff coming in from the outside...
This doesn't even take into account the 99.9% of web pages suck or are unnecessary anyways.
What standard is this based on? My website wite sucks and is only necessary for my own amusement but it is similar to my favorite kind of sites on the web. I would use the web a lot less if it wasn't for those 99.9% of web sites. Most blogs, for instance, suck and are unnecessary but at the same time the total of all the blogs is having a big impact on news outlets and the media.
FoundNews.com - get paid to blog.,
I see this kind of thing all the time on /.--completely unedited, barely literate, rant-style submissions. Why don't the /. editors tone down or eliminate the rhetoric from submissions about otherwise worthy topics, or at least fix the grammar and typos?
I know, I'm going to get blasted for saying this, but I'm convinced it's one of those "little things" that makes /. look to the rest of the world more like a bunch of know-nothing kids typing at each other than a group of technically literate activists with something of value to contribute.
I now return you to your regularly scheduled rant...
Should be, yes. How about the implementation? If you think dealing with poisoned DNS is bad now, wait until something like P2P DNS is in widespread use. Then again it'd be amusing to see the Microsoft's website addresses being redirected to pr0n sites on a daily basis.
No, I assume the researchers are not that stupid.
They mean that some software, designed to take a fully qualified domain name as input, *always* looks up the input by DNS, even if someone has typed in an IP rather than a hostname - making the lookup unnecessary.
If it was a reverse lookup it wouldn't just contain an ip (e.g. "1.2.3.4"), it would be "4.3.2.1.in-addr.arpa", that's how reverse lookup works.
>> 99% of slashdot posts are unnecessary.
:P
> 74.4% of all statistics are made up on the spot.
That's right! A complete study would probably have shown that first number to be much higher than 99%.
Heck, we're 3 for 3 so far
2. The amount of time it takes to set up DNS correctly and effeciently with the existing products, especially BIND, is a lot more than it takes to just get them functioning.
3. The research would have been more interesting if they had gone and looked at say 1000 random requestors who where doing things screwed up and find out why and how they were screwed up.
4. It would be nice if the local DNS servers had a list of valid top level domains so that it would kill requests to non-existant ones.
THAT would be stuff that matters!
Finally someone who makes a relevant comment. Though I wonder how the 'search from address bar'-feature has affected the number of non-existent queries.
The fact that DNS, a 20 year old design, still works after being scaled several magnitudes beyond its original environment is proof that DNS doesn't need to be redesigned. The initial design is nothing short of genius. The extensions to the initial design (dynamic updates) build upon already solid technology.
I run a DNS server, I've looked at DNS packets, and every time I ask the Internet to tell me who the heck slashdot.org is and it comes back with an IP address I'm amazed. My network asks strangers for help and those strangers say: Hey, try here. Bam! Slashdot.org pops up in my browser.
You cannot "combine" DNS, DHCP, and Routing all into a single protocol. Hell, get three network engineers together sometime and try to get them to agree upon the best Internal Gateway Routing protocol sometime... EIGRP, OSPF, RIP.
Routing information is extremely different from domain name information. The two have nothing in common other than IP Addresses. You have to include not only information about who your neighbors are, but also what type of links are between you and your neighbors, and how congested those links are. Now, what about your neighbor's neighbors? Oh, we'll track that to, and also keep a set of tables that show us the next two best reconfigurations should any of the links stop working. Unless you're just talking about RIP for routing.
DHCP on the other hand is about getting clients configured for a network. They can then use DDNS to update their DNS record in a local DNS server. DHCP can do much more than just say: Here's your IP. It can also tell a client: here's where you should get your operating system from, and here's the voice over IP gateway, and here's the server where you should send your management info to, and here's the best local printer to use. Most people don't have clients that can handle that type of information, however.
It's not just "if it's not broke, don't fix it" this is a case of "it frelling works great, keep your hands off of it or I'll kick you in the jimmy."
That makes no sense...
.com. So if I lower the ttl on my domain, that increases the traffic to the server that handles .com and not the server that handles "."
.coms
We're talking about the root nameserver here, not the server that handles
Basically, me lowering my ttl on my domain doesn't cause DNS servers to forget which machine is authoritative for all
Repetitive queries from the same nameserver in rapid succession, full-blown email addresses, search engine queries -- those are unnecessary, illegitimate queries that indicate not only bad nameserver configuration, but also bad application software. How many assorted DNS query permutation tricks have the various versions of Netscape Navigator tried over the years?
I believe that reverse lookups are identified by an "inverse" status flag in the request header. One can only assume that the authors were not counting this sort of valid query, and were only focusing on the "standard" queries that contained IP addresses. Those certainly would, I think, be rather pointless.
Ummm, no. "inverse" does not in any way shape or forme identify a request for the hostname associated with an IP address.
And the lookups being described are not reverse loops, either. A 'reverse lookup' for 1.2.3.4 is a query for the PTR RR associated with 4.3.2.1.in-addr.arpa. The queries being described are for the A RR associated with the FQDN 1.2.3.4. There is no such TLD as '4.'
Well, I was more speaking of the guys who cobbled together their own firewall using 2 NIC's and their OS and software of choice. That's what I did, and I easily could have screwed up an iptables command or a default rule and blocked incoming DNS.
With a purchased firewall, especially if you can't edit it yourself, I would have to assume (uh oh) that the manufacturer got the basics right, at least. I really don't know of a way to check those. You could try an online port scan like sygate.com offers. But your firewall is probably using a "statefull" method, which would allow DNS to come back if you initiated the request, but it would block a NEW request that originated outside. So it will probably say your port 53 is blocked.
There are 01 kinds of cars in the world. The General Lee, and everything else.
This is probably a cyclic argument.
As an ISP, why not respect a TTL? Because many DNS zones set their TTL values too small (5 mins), when 24 hours, would accomplish the same thing (except in rare circumstances -- if you're planning on moving, set it low a week before, do the move, reset to high ttl).
As a DNS administrator, it's a pain to keep changing your TTL and the ISPs don't respect it anyway.
It's useless to have a low TTL because the ISPs generally don't respect it because it's generally set too low because the ISPs don't generally respect it because....
S
I'll bet a large percent of the queries, especially for bogus top-level domains, are due to lookups by MTAs when receiving SPAM. Think of the numbers!
This doesn't mean that even these queries shouldn't be handled better -- just that SPAM lookups cause a bunch of 'em.
Well, apparently, you only have to fool the majority of people for a little while.
Penalties are needed.
The people who run the root servers should penalize any system that fails to implement basic practices like what you mentioned. Networks that abuse the root servers would quickly find themselves unable to do anything.
The net is quickly headed this way for other services as it is. If you don't do something a certain way, some people won't talk to you. Whether it's running open relays, open proxies, not populating your chunk of IN-ADDR.ARPA properly, and so on.
Prediction: eventually you will see a scheme where network operators can say "we implement such and such policy". Other networks will check some kind of 'policy registry' before exchanging traffic with them. This will happen automatically some day.