Might as well link directly to the tool instead of through some third party site.

My servers hosted by servermatrix/theplanet were open to this by default. A simple change to /etc/named.conf followed by a restart to bind and I'm fine now.

Isn't the problem with the Cache Poisoning that you mention to do with ISP DNS caching and that being poisoned, rather than the individual website DNS servers?

At least, that's what I understood the articles to mean and it makes logical sense to me.

If that is the case, while it may well be laudable for people to tighten up their site DNS for other reasons that you mention, it is not going to have the slightest effect on Cache Poisoning exploits for their own sites, since the poisoning exploits are taking place on third-party ISP servers like "Podunk Internet Providers".

Or am I missing something here?

how to poison a few competitors, but every site I checked passed.

Unless of course the bulk of your traffic is coming from a network that does allow DNS recursion. Oh-oh, didn't think about that, did ya?

Actually, I did think about it and it was the point of my previous post, but you seem to have a failure in comprehension.

The valid point about correcting DNS recursion doesn't benefit from your misleading arguments about DNS cache poisoning.

Q. If you make the changes you recommend, can visitors to your domain (for example, hosted at Pair) still be hijacked in the cache of another ISP (for example, for all customers of Podunk Internet Services)?
A. Yes

So yes, making the change you recommend is "a good thing"; yes, if we all did it it would be "a better thing"; and no, it has no practical short-term effect on what you are talking about.

Read one of the sources you recommend:

In this scenario, an attacker tries to intercept secure communication between two parties. For example, Xavier wants to make an online purchase at Yuri's website. The attacker poisons the cache at Xavier's ISP, pointing traffic to Yuri's site to Zamfir's system. Zamfir accepts the incoming SSL connection, decrypts it, reads all the traffic, and makes the same request via SSL to Yuri's site. Replies from Yuri are read by Zamfir then sent back to Xavier over the same encrypted session. Zamfir now has Xavier's credit card number and all other details needed to make illicit use of it.

(nods to stever and pageoneresults)

I ignored the first thread on WMW, but clicked on the second one in the early hours looking for something to read. Had to come out of lurk mode over there and try to clear some things up.

the reply went like this:

As I understand it, the premise of this thread is that:

the dns for a domain is subject to highjack if the authoritative name servers for the domain permit recursion.

I think this is untrue and here is why:

the domain dns highjacking actually occurs at, is targetted at, the dns servers of consumer isp's. for example, the AOL dns servers responding to the dns requests originating from AOL subscribers. the goal of the poisoning is cause these AOL dns servers to *bypass* the authoritative name server for a domain. thus, poisoning of the authoritative name server, that is, *your* name server is a non-issue, or at least a separate issue. in fact, an authoritative name server does no upstream lookups when replying for it's own zones. the links posted earlier to the various informational articles are quite clear on this if read carefully.

the only thing that is going to happen if the cache of *your* authoritative dns server gets poisoned is that outgoing email might be misdirected, or if you are in the habit of using them from your workstation as client dns settings, then your browser or ftp client might get highjacked. in other words, at the most, you risk trying to ftp proprietary source code to the wrong box.

i realise that i am posting at the very tail end of the thread, but i hope it gets read by those who have become worried by the alarms that have been raised.

the bottomline is that if your authoritative dns is working well, then there is no reason to change it. the problem is downstream from you. i am quite surprised that the tech staff of various hosting companies have not pointed this out.

The last thing I posted there was:

But, but, but ...

the scope in the context of the audience here ought to be:

what *can* and *should* the webmaster do directly that affects
the outcome with regards to recursion and cache poisoning

this does not automatically preclude permitting recursion on your dns server.

thus for dns servers *under our own control*, we have:

1. ensure that the proper dns records are in place
2. prevent unauthorised modification of same

cache poisoning can still affect your visitors, but it outside of your *direct* control.

It *is* really that simple.

beyond this, you really have to look to dns servers under someone else's control.

Oh, about Microsoft Knowledgebase Article Q241352, it only applies to pre Windows 2000 SP3 and NT4. Even so, it is an available fix that only involves registry settings. Unlike some other dns software where a complete replacement is required. No need to keep on pointing the finger only at Microsoft products.

Anyways, I wrote a more detailed piece which can be found at:

dns cache poisoning

It emphasises that there are lots of ways to screw up on authoritative
dns name servers. Cache poisoning is not one of them. Hopefully, this
will come as a relief to those webmasters who have come to believe
otherwise ... and the poor overworked tech staff at their hosting
companies.

It needs a little link love :)

DNS poisoning, but too often we feel secure about our ISP/hosting security when we shouldn't.

http://www.pcworld.com/news/article/0,aid,125263,00.asp

that it wasnt DNS poisoning, but just sloppy security. The DNS issue, where it exists, is basically just sloppiness, is it not?

That PDF is about social engineering, key-logging and proxies.

>>having experienced them

Nope. Sorry. If they've experienced the attacks then the server is either open to poisoning or not correct? Then servers vulnerable to those types of attacks should FAIL, not simply receive a warning.

We're still left with less than 1% of servers being open to DNS poisoning and *I* used *their* numbers to find the percentage.

What am I missing here?

follow the money

This is my first rule of thumb when considering the worthiness of warnings issued on the internet.

What axe is the writer grinding? What value is there for the writer in gaining exposure?

For example, a security company issuing security warnings has a vested interest in the sky falling as long as it provides a related service or product. Case in point, Netcraft covers all kinds of outages. They also offer pen testing services, server monitoring services and so on. And Netcraft is relatively responsible and factual in their reporting. Still, their coverage and reputation have an impact on their bottomline.

Even industry organisations fall into this trap. Increased exposure means validation of their mandate. Job security anyone?

Finally, for industry commentators, sensational falling sky reports are much more interesting as topics to report on, given the need to maintain and boost readership.

As far as antiphishing.org goes, I have not found on the site any mention of a sponsoring group, founding members, or current membership. The whois and a single press release on the site tie the owner to tumbleweed who operate commercially in internet security products.

No, the headline at isc.sans.org is actually "Internet Storm Center Returning to Green" from the isc handlers diary on April 08/2005.

http://isc.sans.org/diary.php?date=2005-04-08

Similarly, posadis.org summarised it pretty nicely:

http://www.posadis.org/dns/news/20050202-bright-ip-spoofing

The solution here is simple: just upgrade to a recent version of basically any DNS server: recent versionf of BIND and MS-DNS, and all versions of other software such as Posadis, MaraDNS and DjbDNS do not have this (pretty stupid) problem.

Even the usually hyperactive crowd at slashdot were yawning last year:

http://it.slashdot.org/article.pl?sid=05/04/08/1528213&from=rss

I'm not enough of a techie to understand this stuff easily, but I got curious and checked some domains with the link P1R provided earlier, http://www.dnsreport.com/

Two out of eleven sites got a bright red FAIL message for having open DNS servers. (Fortunately neither was one of mine!)

"ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn't happen). This can cause an excessive load on your DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the bad guys could use your DNS server as part of an attack, by forging their IP address. Problem record(s) are ...."

http://www.dnsreport.com/tools/dnsreport.ch?domain=linkshare.com

(That makes three out of twelve, BTW.)

Technically your correct as having a open dns server could be a problem but what I have is a open resolver, not open server

i.e. anyone can if they wish use ns.xxxxx.co.uk to resolve names into numbers but they can't update the contents of the a domain name zone

Maybe, before you ask what you describe as "experts" (but who are in fact just people who know a bit about DNS) for input to your comments, would you have the politeness to respond to a few points that have been raised here:

For example:

i) what security issues, if any, are there in other levels and types of internet protocol? What is ARP? What is ICMP? What security implications do wireless networks introduce into any equation? (OK, sorry, that one hadn't been raised before!)
ii) what are common security holes related to sites using various types of shared hosting on a single server and/or IP address? How would you rate the gravity of these holes to DNS cache poisoning on one's own DNS server?
iii) what potential problems can occur when recursion is turned off on a DNS server and what issues should a site owner in control of their own DNS be aware of before doing so?

I've not had time to look at this for a while. But, I promised Pageone that I'd pop by one of the threads once I got the time to take a look at it, so here's an attempt at least to make this a bit more understandable.

These are very technical matters, so I understand the confusion. I'm not saying that this post is the be-all-and-end-all of a cache poisoning FAQ but I will try to answer some of the questions to the best of my knowledge.

Perhaps I'll be wrong one or two places, so kick me.. or better yet, correct me :-)

Stever + P1 - I'll skip Q1 + Q2 as those are not strictly about cache poisoning.

------------------------------------------
------------------------------------------

Okay, recursion... This means that a server.. no, wait...

When a client (eg. "browser") asks a DNS server for an IP adress for some domain, that server will either be authoritative for that domain or not. Say, somebody asks me what my phone number is, and I can respond to them accurately because it's mine. I'm authoritative for my own phone number, but not for my neighbours. Had they asked me about my neighbours phone number I might not have known, but then I could just walk over, knock on the door, and ask. That is recursion.

Recursion is the process where one DNS server will ask another server for information, automatically. That server may delegate the requests from the asking server to a third server that the first assumes to be more accurate relative to the specific query, ... and so on.

Assume that I'm in Denmark, ie. the "dot.dk" area. I need to find the URL "my.example.co.uk", so I type that into my browser of course. Here's what happens:

First my browser will attempt to contact a DNS server at my ISP, say "nameserver-dot-DK", asking "hey dude, what's the number for this co-dot-UK fella?"

The "nameserver-dot-DK" -- being recursive -- will say "honestly dear, I don't know and I don't give a damn, but I'll ask this guy for you anyway". Here, "this guy" is "nameserver-dot-UK", as the DK server knows that the UK server may know the information better than the DK server does.

So, the DK-server asks the UK-server, then asks the "co.uk" server, then asks the "example.co.uk" server until it finds an authoritative answer. Then the browser goes there. So, "recursive" means that we have a chain of servers asking servers.

If my ISP's server is not recursive, what will happen is this:

1) Browser sends a request for "my.example.co.uk" to ISP server
2a) Server responds "No such guy here, go home and weep", OR
2b) Server responds "Last time I checked his phone # was 1-800-ACME"

In case 3 "last time" is the cache. That may be old, and it may not be accurate information.

So, if you disable recursion you disable the possibility for your server to ask other servers when it is asked about information that it is not authoritative for.

Meaning that requests to that server -- for other domains than the authoritative ones -- will end up at (2a) or (2b).

----
The above is the non-technical version (without jargon) - it may lack accuracy in a few minor technical details but -- afaik, imho, fwiw -- it is not in any way wrong to explain it like this.
----

So, recursion is good, basically. It allows the "dot-something" name server to only stay updated about the stuff that it is authoritative for in stead of having to cache the yellow pages of the whole world - figuratively speaking.

What happens with cache poisoning is that somewhere along that automatic chain of requests described above, a server will send false input into the system. The server sending false input is the "poisoned" server.

So, that server will tell your server that say, "paypal.com" is at 127.0.0.1 in stead of their right IP. So, you end up there and you have no way to tell that you are in a wrong place, except if it looks wrong.

As that whole request line is 100% automated nobody will tell anybody of something suspicious is going on, because nobody will know, and nobody will even know how to know (those "nobodies" being servers along the chain).

Now, turning off recursion equals saying - "I can no longer safely trust the upstream servers - at least there's a chance that some of them may be giving me bogus information, and me (being a stoopid server) have no way to tell which are right and which are wrong, so... I'll just do that domain name lookup thing myself without asking anyone."

As for (IV) no, it's not wrong. It's basically saying that the information you'll get at that server may not be accurate, as that will be cached information, and not a recursive request. So it may be old information, or even faked. It might be all-OK as well, of course.

As for (V) mick_g probably has no problems, as I'd venture a guess that his web host is responsible and updates the cache as needed without inputting bogus information into it.

As for (VI) they are warning because this is a real and serious problem. Imagine if you can you being able to decide where a name such as "paypal.com" should point, for some subset of the internet population, without them being able to tell in any way...

As for (VII) people make sites for all kinds of reasons... Or, see (VI). I guess it's because they feel it's important. Honestly I wouldn't know.

As for (VIII) - all the requests sent to that server will be answered by that same server. Depending on the state of the cache on that box the answers will be accurate or not.

I hope this helps a bit. Feel free to correct errors and omissions.

some dns servers need to be open....

Forgive my lask of understanding, but don't the latest versions of BIND protect you against this, even on an open dns server?