DNS Cache Poisoning Update

dhammabum writes "Todays SANS internet storm handler has put up an excellent update of the DNS poisoning vulnerability currently doing the rounds. The main points are that only Windows DNS servers are vulnerable (degrees of vulnerability depending on patch level), provided you are not running an ancient version of bind. Also bind4 and bind8 do not clean poisoned caches if they receive them from a poisoned Windows DNS server but bind9 does."

Comments

Informative Links:

[TripMaster Monkey]

In the interest of promoting discussion, there is a good definition of DNS poisoning here, and a longer explanation/rant regarding DNS poisoning here.

Re:Informative Links:

[TripMaster Monkey]

Hmm...the # sign in the second link doesn't seem to work...sorry...try this link instead.

Re:Informative Links:

[Anonymous Coward]

Yes, what DJB is actually pointing out there are *bugs* in most DNS implementations, that do not exist in his djbdns package.

djbdns is, and always has been, immune to cache poisoning.

It is also simpler, much easier to use and maintain, and so much more reliable than BIND or Windows DNS. It also has never had a buffer overflow or other security problem.

If you're running another DNS package, and *especially* BIND, go to the nearest mirror and ask yourself "Why am I putting my users at risk? Why am I using badly-written software voluntarily?"

My DNS server, which I set up a while back with FreeBSD and djbdns, has never been rebooted, patched, or upgraded. It has never had a problem, and in fact dnscache has never even been *restarted* except once to increase the size of the cache. (And note that when you tell dnscache to use N bytes, that's exactly what it uses).

If you're a DNS admin, don't waste your time with bugs from the 1990's. Install djbdns and get on with life.

Re:Informative Links:

[ThosLives]

This is great at explaining what this is, but why could this happen?

Is this a poor implementation of the DNS spec, or is the DNS spec itself to blame for allowing such "poisoning" to occur?

In my experience, software issues occur for one of two reasons:

1. "Broken" code: The code doesn't do what you think it should- for instance, a function is supposed to return the sum of two numbers but it returns the difference. These errors are actually not that common in my experience (probably because it is easy to test against).
2. Bad communication / misuse of code: there's a function that is designed to add two numbers, but you think it returns the difference, and you use the results incorrectly. Also included in this category are the "The software does X, but we really wanted it to do Y even though we told you something else," and "We changed the interface with that, but [didn't tell anyone] or [you didn't read the documentation]" type of errors, as well as poor specification processes: for instance, a spec that says "write a function that averages numbers" but doesn't tell how to handle overflows is a "communications" bug in that information is left out. These are the nasty errors, because it is not feasible to reliably test that "people are communicating properly." Note: I'd also include "malicious misuse of code" in this section, becuase it's basically people lying about what the software does.

Re:Informative Links:

[foobsr]

The second link already seems to show white, so not exactly a replacement but perhaps an addendum.

CC.

Re:Informative Links:

[tedgyz]

Thanks for the info, but, to coin a phrase, "Where's the beef?" I went to the wiki page hoping to get a clearer understanding, but was left feeling like I had just read a Microsoft help page.

To sum up...

DNS Cache Poisoning: DNS Cache Poisoning is the process by which a DNS Server's cache is poisoned.

I'm not trying to flame. Are there more in depth explanations? Don't worry, I'm not planning on writing a DNS poison worm. :-)

Re:Informative Links:

[bigberk]

Unfortunately djbdns is a bit awkward to install because of djb's insistence on the daemontools manager. There's nothing wrong with it, but the technique for installation is a bit awkward and certainly unlike other Unix-based server software.

Re:Informative Links:

[nothings]

Reposting from the previous slashdot thread, responding to a djbdns user; note specifically that djb admits the forgery resistance is "quantitative, not qualitative".

While I don't think I'm in the clear because of this, I feel better protected from the (unwashed ;)) internet.

That seems fairly reasonable. I don't think you're really protected from poisoning, unless "poisoning" only applies to certain kinds of DNS spoofing. Specifically, first note the exceptions to the djbdns security guarantee (emphasis mine):

• Bugs outside of djbdns, such as OS bugs or browser bugs. (People could seize control of BIND 9.1 through an OpenSSL buffer overflow, but that was a bug in OpenSSL, not in BIND.)
• The vulnerability of DNS to forgery. (BIND's port reuse makes blind forgery much less expensive, but this is a quantitative difference, not a qualitative difference. The DNS architecture needs cryptographic protection.)
• Denial-of-service attacks. (BIND 9's fragility makes denial of service completely trivial; but an attacker can easily take down the Domain Name System without using any of BIND's bugs. The DNS architecture needs to be decentralized.)

Specifically, his forgery page points out that a spoofing attack based on the birthday paradox can still work... although probably tens of millions of packets are required. This page, which I think I got off slashdot before, uses the TCP sequence-number guessing tools to try to attack it. It's probably not quite as secure as djb estimates, but probably still in the millions. They don't seem to have actually run numbers for the randomized-port plus randomized-id, so it's unclear whether they actually attacked that thoroughly.

Re:Informative Links:

[ldspartan]

apt-get install runit djbdns-installer
build-djbdns
dnscache-conf-fhs nobody nobody /etc/dnscache 127.0.0.1
ln -s /etc/dnscache /var/service/

Granted, not super-simple, but certainly not hard.

Re:Informative Links:

[carpe_noctem]

DJB is going to turn into the next RMS if he doesn't stop spouting at the mouth with how inferior all of his competitor's software is. Even his documentation is arrogant, for chrissakes.

And I'm sorry, but bind9 isn't that complicated. I found djbdns to be much clunkier and difficult to set up. Like all of DJB's software, it relies on retarded configuration files and bizarre notation.

Don't get me wrong here; I'm a qmail admin myself and I love it, but I dislike it when people talk about his software like it was written by Moses and God and given to mankind for all of eternity. It may be pretty stable and secure, but it lacks common usability and many features of other, traditional DNS software.

Re:Informative Links:

[Just Some Guy]

First, djbdns isn't Free Software, which means that a lot of us won't touch it with a ten-foot pole. See the recent BitKeeper debacle for reasons why that's the pragmatic rationale and not just an ideological decision.

so much more reliable than BIND

I have never, not once, ever had BIND fail. I doubt I'm the best DNS admin anywhere, so I imagine it works well for a lot of other people as well.

Why am I putting my users at risk?

Because my secondary DNS servers, provided by my registrar, are out of my control. I can't install rsync on them to support the functionality that Dan left out of djbdns.

If you're a DNS admin, don't waste your time with bugs from the 1990's.

I'll agree with that. Upgrade to the most recent version of BIND and get on with life. OpenBSD's support of that policy is a pretty strong endorsement.

Re:Informative Links:

[Just Some Guy]

Well, Gentoo is pretty easy to install if you know the right commands. In either case, though, the instructions are completely opaque to anyone who doesn't already know that system inside and out.

built-djbdns? Oh, that's right - it's not Free Software so Debian can't package it.

Something about configuring DNS. Maybe to run as "nobody", I presume. I guess we're setting up a cache directory in /etc? Something or another about localhost.

/var/what?

I'm not trying to slag on you, but those aren't exactly the most transparent instructions I've seen.

Re:Informative Links:

[Electrum]

First, djbdns isn't Free Software, which means that a lot of us won't touch it with a ten-foot pole. See the recent BitKeeper debacle for reasons why that's the pragmatic rationale and not just an ideological decision.

There is a HUGE difference between BitKeeper and DJB's copyrighted software. DJB's software is distributed as source code without any "license". This means that you will always have the option of using, modifying and distributing patches for any released version. He can't suddenly take the software away from you.

I can't install rsync on them to support the functionality that Dan left out of djbdns.

djbdns includes an AXFR server.

Re:Informative Links:

[MindStalker]

I'm not trying to flame. Are there more in depth explanations? Don't worry, I'm not planning on writing a DNS poison worm. :-) For the love of all things holy, I'd seriously hope your not trying to write a DNS poison worm without years of prior experience with the DNS architecture. No telling what would happen :)

Re:Informative Links:

[Anonymous Coward]

If that DJB bloke weren't so damn arrogant, many admins would have much less of a problem with using his software.

Re:Informative Links:

[Just Some Guy]

DJB's software is distributed as source code without any "license".

Which also means that you can't distribute anything but patches even if you wanted to. Forget about making it part of an OS base distribution, or using any his the proclaimed "better" code to improve any other projects. Basically, it's a proprietary product that happens to ship with source.

Put another way, I could theoretically provide instructions for replacing Windows' HTML renderer with Gecko, but that doesn't mean that it's a Free (or even Open Source) system.

I understand your point, truly, but I just don't agree with it.

djbdns includes an AXFR server.

That doesn't do much for those who need IXFR.

Re:Informative Links:

[Effugas]

Bailiwicks -- the idea that a given query can only trust names returned under that query -- weren't really part of the early DNS design process, and aren't at all implied by the underlying structure of the protocol. For example, to any query, you can return a CNAME -- a "canonical name" that should have been looked up. But, for efficiency's sake, you're required to *also* return the address for that canonical name. So I might look up "foo.com", get told "you should have looked up google.com, and oh, by the way Google's IP address is 1.2.3.4". You wouldn't just go to foo.com at 1.2.3.4, you'd cache Google at 1.2.3.4 as well.

What's supposed to happen, nowadays, is that the additional record is still mandatory -- but, it's not to be trusted; a second lookup for google.com (which doesn't match *foo.com) is called for.

What happened here is that someone thought that forwarding meant you trusted someone else implicitly anyway, so why run the bailiwick process? Well, some upstream daemons forward too much from the outside world, that's why. Never trust the network more than you have to.

--Dan

Re:Informative Links:

[operagost]

How about this: I run OpenVMS.

Let me know when DJB gets around to porting it.

Re:Informative Links:

[tedgyz]

You are implying that most worm (virus, etc.) writers are industry veterans with years of experience. Hmmmm. And all this time I thought it was those pimply-faced, teenage n00bs. :-)

The funny thing about worms, viruses, etc. is that they don't have to be perfect and the measure of success is all in the eye of the beholder.

Also, most variants of viruses are just simple text changes performed by some poser who knows how to work a hex editor. Which reminds me of my early days with 'puters... It was a PDP/11 running RSTS/E, which had a built-in BASIC interpreter. We hacked the BASIC binary to change the 'Ready' prompt to 'F**k You' (no stars). Harmless fun for some teenage haxx0rs. Fortunately, I did not follow the Dark Side.

Re:Informative Links:

[Anonymous Coward]

I'm not trying to slag on you, but those aren't exactly the most transparent instructions I've seen.

Right. Why can't djbdns be as simple and transparent to deploy as BIND? [rolls eyes]

Seriously, if you can't follow the installation instructions for djbdns, then you're probably not competent enough to be providing DNS services to the internet in the first place.

Re:Informative Links:

[ThosLives]

I'm not that familiar with how DNS works (other than, "hey DNS server, give me the address for xyz.com" and it spits back either an address or "I've never heard of that"), but it appears you're saying that if I try to get an IP address for "foo.com" some DNS server will tell me I really wanted "google.com"? I don't understand how that's possible.

Or, do you mean that I send on some information like "I want foo.com and I once got it at 1.2.3.4 - is this right?" and the DNS responds with "well, I think 1.2.3.4 belongs to google.com and foo.com is at 10.9.8.7"? At that point, the way I see it, it becomes really difficult to tell what name goes with what address without some physical mechanism. And that, of course, is the whole issue of "remote security".

Re:Informative Links:

[Anonymous Coward]

Sorry, but DJB is not always right. For example, DJB things DNS-over-TCP is evil, since DJB is too lazy to implement DNS-over-TCP correctly, even though DNS-over-TCP can improve security.

It is possible to connect to a BIND server via TCP and have the BIND server respond via TCP to a recurisve query. It is not possible to do this with DjbDNS. DjbDNS, as a result, is more vulnerable to some DNS attacks.

Also, DJB and his cronies try to ignore the fact that BIND 9 is not BIND 4/8. It is a complete rewrite. There has been no remote compromise of BIND published ever.

I would like to see DJB cronies stop spreading FUD and start spreading fact. But that it probably too hard for DJB fanboys to do.

Re:Informative Links:

[Anonymous Coward]

I am curious why it is you need IXFR. What kind of network do you have the is unable to send or receive entire zones via AXFR? How come your zone files are so big, and how come you network is too slow to transfer entire zone files?

(If you mean you need DNS notify to immediately transfer any changes, that's a different ball of wax, and not IXFR)

Re:Informative Links:

[sgtrock]

The thing that is most galling for his detractors is that he always turns out to be right.

Umm, no he doesn't always turn out to be right. My immediate experience with his stuff is daemontools. Nice package in a lot of ways, but the toolset forces far too many default choices that deviate away from common practice.

I found two big hangups that pushed me away from daemontools and over to start-stop-daemon. The first was that assigning logfiles by default deep within the daemontools subdirectory instead of within /var/log. The second was that I found that it really didn't do such a great job of recovering some of the server daemons that failed in odd ways.

Start-stop-daemon uses sane default behavior for logfiles, which makes it much easier to work with out of the box. It has also done a much better job of recovering daemons.

Don't get me wrong, I think that DJB is a very smart programmer. It's just that he thinks that if something is not done his way, it's automatically wrong. That's simply not true. No one is that good, for one. And doing something different just for the sake of doing it is truly A Bad Thing (tm) for system admins.

Re:Informative Links:

[cmacb]

In my experience, software issues occur for one of two reasons:
(1) "Broken" code:.....

(2) Bad communication / misuse of code:....

You left one out:

(0) Bad Design: The code does everything you intended it to do and the users are using it properly, but you didn't think of all the possible states in which the code could find itself and decide what to do about them.

This is often lumped in with (1), but shouldn't be IMHO. It's one reason I think that comments in code are valuable (as are formal design documents) since it forces the person, or people doing the design and coding to restate their intentions in at least a couple of different ways.

I have written and worked with well written specs and they tend to reduce the number of pure coding errors by leaving less to the imagination of the coder. Well written specs can still fail to account for all possibilities however and that's a good reason to have meaningful design discussions (rather than the formally mandated ones that people attend these days in body but not mind).

There are many people today who think of themselves as ace coders. The world would do well to have more people who are design experts who don't practice coding at all. The two disciplines complement one another well.

Re:Informative Links:

[Just Some Guy]

I am curious why it is you need IXFR. What kind of network do you have the is unable to send or receive entire zones via AXFR?

Two words: dynamic DNS.

There are a lot of little single-entry updates to some of our zones, and IXFR transmits only the changed entries to the slaves.

How come your zone files are so big, and how come you network is too slow to transfer entire zone files?

Reverse that: even though our zone files aren't terribly big, why would we want to transfer the whole thing each time? It's the difference between sending a patch file instead source tarball for every update. Isn't efficiency supposed to be a good thing, even when it's not absolutely necessary?

Re:Informative Links:

[Anonymous Coward]

OK, just checking. Just to let you know, the reason why DJB is so against IXFR is because it is not trivial to redesign his data structures to support it. This is why he says "Just use rsync"; it saves him a hell of a lot of code rewrite.

Granted, he is too arrogant to admit that he just doesn't have the time/energy to do this, but keep in mind that he isn't getting paid to write his code.

I agree that IXFR is a useful feature, but it's one that not everyone uses, and one that requires a rewrite (or at least, serious surgery) of a non-IXFR DNS server to implment.

My big issue with DJB isn't his arrogance, but is unwillingness to open-source his code.

Re:Informative Links:

[Anonymous Coward]

We got a debian snob here... What version does it get 0.1?

Oh wait I run debian also... Never mind, nothing to see here.

Re:Informative Links:

[chrisnewbie]

cld (could) -u (you) b (be) mre (more) +clr (clear)

Re:Informative Links:

[ThosLives]

Yes, I could see how you'd call that out separately instead of lumping it in with (1). Strictly speaking, it is (1) because there are situations where the code doesn't do what it was designed to do. Oddly enough, your (0) also incorporates stuff that I cite in (2).

However, I'd posit that a spec cannot be "well written" if it does not account for all possibilities. (I'm picky like that).

I agree with your statement that most people don't understand the purpose of a design discussion, as well as the (lack of) separation between design and code. Simply stated, people often forget that there is an important but subtle distinction among requirements, design, and implementation. If you mess those up, you get worlds of hurt...

Re:Informative Links:

[David Off]

> DNS Cache Poisoning: DNS Cache Poisoning is the process by which a DNS Server's cache is poisoned.

The problem with some of those wiki guys is they guard their entries like savage poodles. If you add anything useful it gets deleted within 24 hours.

Re:Informative Links:

[gnu-generation-one]

"DJB is going to turn into the next RMS if he doesn't stop spouting at the mouth"

Excellent... we need some more software which will still be working in 30 years' time. Anyone else wants to become more like RMS, I'm all for it...

Re:Informative Links:

[mlyle]

He's talking about a CNAME; a CNAME is like a symbolic link for DNS. That is, if you try and look up www.foo.com, it can contain a CNAME saying that www.foo.com is an alias for www.google.com. This can be really nice, because if you have many services running on one server, you can CNAME (e.g. you could have one big host, bigserver, and CNAME www.whatever.com for multiple domains to bigserver; if bigserver's address gets changed, you only need to modify one zone file).

If a DNS server returns a CNAME record, it's supposed to return an address record for the destination server if it can; e.g. it says

www.foo.com. IN CNAME www.google.com.
www.google.com. IN A 64.233.187.99

Bad things happen if the server that hosts DNS for foo.com is malicious and returns an invalid address for www.google.com; because naïve DNS implementations would then trust foo.com's address for google.com.

Re:Informative Links:

[greed]

To give the explanation of DNS poisoning in a slightly different way (based on what I know of BIND, DNS and from the SANS pages from earlier)....

I'll assume everyone's up on how a cache works. DNS poisoning is possible on DNS caches which aren't suitably paranoid about how data gets into the cache.

Basically, a server that is trying to poison a cache sends additional records with its answer, and those records are unrelated to the question.

So, you ask "What is the address of bogusserver.badguy.com?". In the answer you get back, it says something like this:

bogusserver.badguy.com. IN A 192.168.12.12
com. IN NS 192.168.12.12

(For those that don't know, a DNS name ending with '.' is considered an absolute name; the "root" of the DNS is noted with a single '.'.)

That answer above gives the host address of bogusserver.badguy.com (the "A" record) and a nameserver address for all of "com" (the "NS" record). (These examples are IPv4 only, that's effectively what the "IN" means.)

So, a poison-resistant DNS will reject all the parts of the answer that do not match the question. "What, com.? I asked about bogusserver.badguy.com.! Forget this bit about com.!"

One that is susceptible to poisoning will accept the updated record for "com." also, and enter it into the cache. Since it didn't need to know about the nameserver for com., the only part that matters is that it is caching the wrong nameserver address. Now, anyone who asks that DNS cache for the name server address for ALL of "com." gets the address injected by the nameserver for bogusserver.badguy.com. At that point, that nameserver can tell your client whatever it wants. All future lookups for "com.", until the cache expires (usually 2-7 days), will use the malicious server.

Some servers make this worse by invalidating all entries for a domain when the nameserver entry is updated for that domain--forcing a query of the malicious server for sites that are used often (and hence are in the cache).

This attack DOES require that someone requests a name that will trigger a query of a malicious nameserver. This is pretty easy, though; send mail that will bounce with an envelope-from address in the malicious domain.

Re:Informative Links:

[Anonymous Coward]

Forget about making it part of an OS base distribution, or using any his the proclaimed "better" code to improve any other projects.

False. DJB has placed portions of his code into the public domain to be used for whatever purpose you so choose.

Re:Informative Links:

[Anonymous Coward]

Not false. The amount of DNS code that DJB has made public domain is only a small part of the entire DjbDNS suite.

I really wish DJB fanboys would spread facts, not myths and FUD.

Re:Informative Links:

[Anonymous Coward]

Here! Here! Well said.

Re:Informative Links:

[Zeinfeld]

It is also simpler, much easier to use and maintain, and so much more reliable than BIND or Windows DNS. It also has never had a buffer overflow or other security problem.

This is absolutely correct, slashdot got this one wrong, DJBDNS has always been very secure, Windows NT DNS was insecure until SP4 went out and then they made the mistake of not making the security checks on by default.

A major security flaw was found in BIND as recently as 2002, if you are still using BIND 8.4.3 you are at risk and need to upgrade to BIND 9 now. Unfortunately a lot of people have not done that because there are some infrastructure issues.

BIND was cleaned up to a major degree by Paul Vixie, but the history absolutely does not justify folk using BIND to go throwing stones. What Microsoft has been doing is reminding people to turn on the security mechanism in a version of Windows that is generally considered obsolete in response to recent attacks.

Its like Red Hat issuing an urgent advisory for version 5.3

The main issue with DJBDNS is whether it will support the final DNSSEC spec. DJB is somewhat pissed with the DNSEXT working group (and with justification).

Re:Informative Links:

[SleepyHappyDoc]

Put another way, I could theoretically provide instructions for replacing Windows' HTML renderer with Gecko, but that doesn't mean that it's a Free (or even Open Source) system.

Please, please, please do this! I would love to use a non-Microsoft HTML renderer in IE and see how the sites deal with that configuration.

Re:Informative Links:

[Anonymous Coward]

Tell me, Mr. Anonymous Idiot, why it is that you never replied to the two follow-ups to this posting? Perhaps because they were right and you are wrong. I thought so.

There's a reason you got modded down.

1) You're an idiot.
2) You're wrong.
2) You walked away when people pointed out why you're wrong.

Re:Informative Links:

[Anonymous Coward]

DJB isn't going to support the final DNSSEC spec. In fact, I would be surprised if DJB ever releases an updated version of DjbDNS with ipv6 support or any other modern feature.

Re:Informative Links:

[tricorn]

Well, what's worse is when you have the badguy.com nameserver respond:

badguy.com IN NS a.gtld-servers.net.

and then in the additional records, you inform them that:

a.gtld-servers.net. IN A 1.2.3.4

Now, the additional A record is not exactly unexpected, it's letting you know where that nameserver can be found - otherwise, you might have to keep chasing it around through multiple levels of queries, or even get into a loop which can't be resolved. However, the real problem is that a.gtld-servers.net is one of the DNS for .com and others, so the next time you do a lookup on some other .com, if you cached that address, you'll look it up from 1.2.3.4 (i.e. the bad guy's server), which of course will lie to you about where to find whatever you're looking up.

The correct thing to do is not cache the "glue" records at all - only cache records from the authoritative nameserver, starting with the root nameservers. If they send you addresses for the nameservers mentioned, don't cache them. To be extra paranoid, don't even follow them unless they are sub-domains of the domain the server is authoritative for, but that can end up in extreme or infinite levels of recursion. Then there's lame delegation...

Re:Informative Links:

[Anonymous Coward]

Here! Here!

"Hear, hear!".

Re:Informative Links:

[Anonymous Coward]

DJB things

"thinks", or, better, "thinks that"..

Re:Informative Links:

[Anonymous Coward]

Dan? Is that you?

Re:Informative Links:

[chinakow]

Ok, I will buy all of this reasoning, but what I want to know is, how much of a bad idea would it be to just point your DNS to the root servers? would they just die under the sudden load of every Tom, Dick, and Harry pointing there personal DNS at it? or would they just not accept the connection from a small fish?

Re:Informative Links:

[Just Some Guy]

how much of a bad idea would it be to just point your DNS to the root servers?

Terrible. Since the root nameservers don't answer recursive queries, you wouldn't be able to resolve anything.

Examples:

$ dig -t any www.google.com @M.ROOT-SERVERS.NET
com. 172800 IN NS A.GTLD-SERVERS.NET.

$ dig -t any www.google.net @M.ROOT-SERVERS.NET
net. 172800 IN NS A.GTLD-SERVERS.net.

$ dig -t any www.google.cx @M.ROOT-SERVERS.NET
cx. 172800 IN NS ESTIA.ICS.FORTH.GR.

Note that in each case, querying a root nameserver for a hostname returns only the address of another nameserver - one that should be capable of pointing you at yet another nameserver that holds the information you're looking for.

Same article, 2010.

[Silverlancer]

The InfoCon is currently set at psychadelic purple-green in response to the realization that Windows is still insecure, even now that Longhorn has been out for nearly 3 years, and has reached service pack 23. We originally went to psychadelic purple-green because we were uncertain of the mechanisms that allowed seemingly "secure" systems to be vulnerable to this issue. Now, however, we know of the mechanisms--Microsoft still makes shitty products, and Windows is still buggy and vulnerable.

In other news, water is wet.

Re:Same article, 2010.

[Anonymous Coward]

more like sp1 m i rite?

Re:Same article, 2010.

[Silverlancer]

more like sp1 m i rite?

Holy shit, I think my head just exploded.

Re:Same article, 2010.

[I_Heat_Sexylaid]

Verily, if thine head explodeth, thou shouldst not think, think thee not?

Re:Same article, 2010.

[Anonymous Coward]

Unfortunately 86% of Windows users have not installed the 2.67TB service pack 23 as it is still downloading.

Re:Same article, 2010.

[tedgyz]

In other news, water is wet.

Holy S*** Dude! You should warn people of possibly harmful humor. My chest still hurts from laughing.

Re:Same article, 2010.

[Math, The Ancient]

Been chatting lately?

Re:Same article, 2010.

[Anonymous Coward]

In other news, water is wet

In other news, people (vendors in particular) are still climbing over each other to put yet more enterprise applications on bathgatesOS, and shove them directly up the customer's patootie, despite the established fact that bathgatesOS continues to thoroughly unsuitable for the job - this after how many trillion dollars have been thrown at it (not by bgInc. but by many of the same aformentioned vendors, assisting the bill gates monopoly to proliferate at their own expense).

Update on the Update

[Hulkster]

That SAN's report actually came out yesterday, the 7th, probably when the article was submitted ... and ISC uses UTC time for their postings. There's an update the next day (today as I write this) where ISC returns the status to Green because they understand the DNS Poisoning problem and have recommendations for people to protect themselves - although it's still an issue.

Ironically, that same update describes Comcast's nationwide problems that started last night (US Time) and says it was caused by an equipment upgrade and not related to the DNS Cache poisoning. BUT, the problem was not network connectivity, but the DHCP's DNS Servers became unavailable. Read more at DSLReports and (from first hand experience), the work-around was fairly easy which was to manually specify the DNS server, rather than use the DHCP'd one. Comcast says it was resolved about two hours ago - scroll down to the bottom of the page.

Re:Update on the Update

[HeelToe]

Thanks for the information on ComCast.

I saw DNS failures clicking on an apple.slashdot.org link yesterday evening. It too me all of 2 minutes to switch my local dhcp-provided dns information over to an already-running djbdns dnscache sitting on my fileserver. I just recently switched away from using dnscache, hoping to simplify the home network, of course, as soon as I do it, my ISP hoses their DNS.

Re:Update on the Update

[tmasssey]

I had no idea that there was a problem.

Of course, I use a Bering Leaf Firewall which uses DNSCache (from DJB DNS) already...

:)

Re:Update on the Update

[HeelToe]

Interesting - thanks for the reference.

I can't find a ton of easily accessible information on the sf site. Does it only run on x86?

I use a WRT54GS for a firewall/router (lower power consumption). From the looks of things this does not run on that hardware?

Thanks.

Re:Update on the Update

[Anonymous Coward]

http://leaf.sourceforge.net/

Re:Update on the Update

[tmasssey]

Corrected link: Bering LEAF Firewall. For the record, Bering uClibc is a newer version of Bering: check out that one.

Bering is, AFAIK, x86-only. Of course, it is completely open source, and you could recompile for different targets. However, I do not believe that there are any binary packages for MIPS. I use it with Mini-ITX systems with no moving parts. That's quite a bit more expensive than the Linksys router! :)

Wow!

[Anonymous Coward]

Thanks for the update there, Zonk! MS DNS, BIND4 BIND8 are insecure.

Who knew? Truly, "stuff that matters".

How did I KNOW??!!

[Sensible Clod]

Somehow, I just knew Windows was at the root of the whole thing...

Re:How did I KNOW??!!

[Anonymous Coward]

Somehow, I just knew Windows was at the root of the whole thing...

Windows doesn't have root, it has "Administrator". Therefore, Windows was at the Administrator of the whole thing.

Re:How did I KNOW??!!

[PornMaster]

Well, actually, the root of the whole thing, ".", is handled by UNIX servers.

dnsmasq is vulnerable too

[Ktistec Machine]

...at least, according to this link from the lwn.net security page.

Re:dnsmasq is vulnerable too

[stratjakt]

Used as a simple cache/proxy/dhcp server on a properly firewalled private LAN, which is how I use it, is dnsmasq a threat?

I mean, an attacker would actually have to be able to hit it from the outside, right?

Also, if say my upstream DNS servers were "poisoned", could my caching DNS proxy/server detect this, and thus protect all the boxes on my LAN from evildoers?

Y'know, people keep telling me

[Anonymous Coward]

"If you don't like windows don't use it"

Or then telling me, when they find out I don't use it, that I've somehow forfeited the right to complain about it anymore; or trying to hold Microsoft blameless for their security holes because the people who run Microsoft software do so by "choice" so its the users own fault, and they are just hurting themselves.

But then I keep finding that despite not using Microsoft software, I get negatively impacted by it anyway. Because the Code Red slaves on the network are bombarding me with a constant light DOS looking for that index server or whatever. Because I get bombarded with email viruses and spam from zombie PCs which, while harmless to me, make my email account less useful. Because my DNS server is running Windows.

Lovely.

So, look at this. I am being materially negatively impacted by a company whose products I don't even buy. How, exactly, is the invisible hand of the market going to help with this?

Re:Y'know, people keep telling me

[Anonymous Coward]

It appears that the invisible hand is currently giving you a bitch slap upside the head. Don' worry though, when Longhorn is released in 2025 you will not have to worry about security because it will be the shiznet. You will laugh at how insecure your linux system running kernel 2.99.2 and KDE114 is.

Re:Y'know, people keep telling me

[djmurdoch]

So, look at this. I am being materially negatively impacted by a company whose products I don't even buy. How, exactly, is the invisible hand of the market going to help with this?

You need to use a visible hand to get the invisible hand to work. Put together and win a class action suit, cost them lots of money. Then the price of Windows will go up, and fewer people will use it.

Re:Y'know, people keep telling me

[InVinoVeritas]

Quit yer bitchin' dude... XP has some awefully cool icons don't it?

Re:Y'know, people keep telling me

[Anonymous Coward]

"So, look at this. I am being materially negatively impacted by a company whose products I don't even buy. How, exactly, is the invisible hand of the market going to help with this? "

I believe that the invisible hand of the market is giving you the finger...

Re:Y'know, people keep telling me

[Anonymous Coward]

How could people who are not Microsoft customers possibly take part in a class action suit?

Re:Y'know, people keep telling me

[MSFanBoi]

Did you bother to read the SANS report? Windows 2000 Sp3+ and Windows Server 2003 DNS servers are NOT affected by this attack. YOu ain't running a 4 year old version of Linux, Unix or MacOS X are you?

Re:Y'know, people keep telling me

[pinkfalcon]

Actually I am:

- Uptime for myrouter.home.ericzeller.com -
Now : 91 day(s), 13:18:11 running Linux 2.2.19pre13
One : 413 day(s), 06:14:44 running Linux 2.2.19pre13, ended Wed Jan 5 21:32:40 2005
Two : 377 day(s), 00:26:56 running Linux 2.2.19pre13, ended Sat Dec 14 13:26:46 2002
Three: 117 day(s), 04:39:46 running Linux 2.2.19pre13, ended Thu Oct 2 17:42:38 2003

Re:Y'know, people keep telling me

[wren337]

The invisible hand of the market has never been any good at managing companies who damage their environment, wether it be pollution, overfishing, or zombie PCs spewing out packets. That's why we balance capitalism with rules and regulations.

Re:Y'know, people keep telling me

[Anonymous Coward]

> XP has some awefully cool icons

Yes, but I don't recognise them because they are not the same as previous versions.

Windows was 'easy to use' originally, once it had been learnt, because pictures can be recognised rather than 'understood'. A simple scan of the screen and my brain would trigger when the eyes saw what I wanted.

With XP MS completely stuffed that up. They changed all the icons and the way that, say, control panel worked so as to make it 'cool'. But they made it _useless_ for me, and a retraining cost for users of previous versions. I look at an XP screen and it means nothing.

Re:Y'know, people keep telling me

[TheCabal]

Let's not pretend that Windows is the only OS out there that has problems. I can pull up last night's firewall logs and see Slapper hits. What say you about that?

Re:Y'know, people keep telling me

[SpaceLifeForm]

That's why we balance capitalism with rules and regulations.

Used to. Now the rules and regs are used to help the greedy capitalists.

Re:Y'know, people keep telling me

[Anonymous Coward]

You didn't bother to read the report either - the MS servers ARE vulnerable if the master is vulnerable, irrespective of the patch level or security settings.

So, your fully patched MS server is ONLY secure, if your ISP use a BIND 9 server - RTFA!

Re:Y'know, people keep telling me

[Anonymous Coward]

Nice, you blame microsoft for the actions of a dumb admin, you linux fatties are really grasping at straws.

Re:Y'know, people keep telling me

[nycbicyclist]

Coming from a legal background, I've often wondered why Microsoft isn't being sued over this. Granted, the big companies that still rely on Windows probably wouldn't want to piss off the MS hegemony. But why not a class-action lawsuit on behalf of unix-only companies and network administrators? There seems to be some hostility to lawsuits here on Slashdot (some justified, but not always, in my opinion). There's one answer I see here that I don't really think explains much -- that Microsoft has too much money to be challenged. But it's precisely Microsoft's pile of cash that would motivate many class-action lawyers to take on such a case and even front the costs. Think of the lawyers who took on the tobacco industry.

Comcast Issues?

[Bonzor]

I wonder if this is the reason Comcast's DNS servers all took a gigantic shit yesterday.

Re:Comcast Issues?

[c0bw3b]

Yes.

Re:Comcast Issues?

[MarcQuadra]

It almost certainly is, but Comcast is saying that equipment upgrades were the cause. I don't believe it AT ALL, since I run a caching DNS proxy on my LAN which is on Comcast cable.

Last night I was able to browse perfectly fine to all the sites in the server's cache, but I couldn't resolve new sites until I added a non-comcast DNS server to my server's resolv.conf file.

Thank god DNS is as open as it is, I just added a uri.edu DNS server from some old documentation from an old job and things started working again. I needed the 'net last night to test some things, and I'd be damned if I was going to let Comcast get in the way.

On a sidenote, it wouldn't surprise me if the 'equipment upgrade' was actually Comcast replacing their Windows DNS with BSD boxen. I'm hesitant to run nmap against the DNS servers for fear of hacking accusations.

Re:Comcast Issues?

[billmustdie]

Me too. I hadda revert to true IP addresses yesterday. I'm not a truely skillfull network admin, but I decided to get bind (9-10?) up and runing as a back-up.

I had full-speed contact with the 'net, but no DNS at all. Type in http:....", screwed.

Re:Comcast Issues?

[Doppler00]

I experienced this too yesterday. I almost thought it had something to do with them upgrading their users from 3Mbps to 4Mbps recently but that doesn't make sense. I noticed that Winamp could play audo streams just fine, but that I had a 1 in 10 chance of getting to a URL address in a web browser.

Last night...

[bhsx]

Last night I couldn't reach google, comcast.net (my GF's email[although I warn her everyday about relying on ISP-based email{lock-in and all that...}]), yahoo, and a number of other sites. Strangely, Happypenguin, slashdot and sourceforge all worked just fine. I figured it must have been dns issues and kind of assumed it was this poisonning that's been happenning. Needless to say, it was annoying as hell. Add to that; 800-comcast and 888-comcast were giving fast busy signals, so their call center was being DDOS'd by a swarm of angry customers.

Re:Last night...

[giantgreenhead]

I had the same problem. The simple, easy solution is to keep hitting refresh until you're lucky enough to find the server. The real fix involves changing the default dns server on your computer/router but im not sure of the details.

Re:Last night...

[Anonymous Coward]

use one of these:

4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2 .2.6
68.62.160.5
68.62.160.6

66.93.87.2
216.231.41.2
216.254.95.2
64.81.45 .2
64.81.111.2
64.81.127.2
64.81.79.2

Re:Last night...

[Anonymous Coward]

>>although I warn her everyday about relying on ISP-based email

and she's *still* your girlfriend?
nice one...

Re:Last night...

[Jon Abbott]

I had a very similar problem last night as well (4/7/05), and am using Comcast as well (in Jacksonville, FL). I rebooted my Powerbook after installing some security updates, and Finder took two minutes longer than usual to start -- a result of a bad domain lookup. Upon further investigation, the DNS entry my laptop had was not the same as the Win2k PC right next to it. The Win2k PC's connection appeared to be working fine (most likely as it had the DNS entry cached), so I copied its DNS entry into the Mac's /etc/resolv.conf file, which made it work fine. Upon rebooting the Mac overwrote the resolv.conf file, so I ended up just putting the DNS address in the Network Preferences GUI settings and that has worked fine so far.

Re:Last night...

[Anonymous Coward]

XP? 2k?

Your system still had dns entrys cached for sites you visit maybe.

There dns was down totally. But if you had it cached or knew the ip. It was ok.

Re:Last night...

[bhsx]

yeah, it was XP on this box, and Kubuntu on the other. Both could hit slashdot etc. so it was probably cached in my wrt54g router.

Comcast hides constantly

[WindBourne]

Comcast has had numerous issues with virus hitting their servers. Basically, every time that major new virus comes out, comcast gets hit; Big. They forced even the ATT/TCI unix servers over to Windows (in spite of much higher costs), so that the entire network takes it in the short.

Re:i got me...

[Anonymous Coward]

Damn you daypass people, I have a UID half yours and I have yet to get a frikkin' daypass.

Mod Parent Up. Crude == Funny

[Anonymous Coward]

Go ahead! You know you tasteless bastards are gonna do it anyway.

blah

[Anonymous Coward]

this is a test

Comcast DNS issues coincidence?

[spoonyfork]

Could it be coincidence that Comcast is currently experiencing DNS issues? Probably.. but it makes me wonder.

WOW PLEASE!

[xcfx]

" The main points are that only Windows DNS servers are vulnerable " And the sun is really hot! -- Windows is like a teenage girl in America, you never know what you're going to get!

Re:WOW PLEASE!

[Anonymous Coward]

It's really Microsoft's fault that admins haven't applied the service pack from 2002 that fixes the issue?

From the Internet storm-in-a-teacup dept...

[Eyeball97]

From the article:

"On Windows 2000 SP3 and above, the DNS server DOES protect against DNS cache pollution by default. The registry key to protect against the poisoning is not necessary: the value is TRUE if the registry key does not exist"

In other words, many or most 2000 installations should be secure against pollution if their admins posess the slightest clue.

"Windows DNS --> forwarding to BIND4 or BIND8. Windows DNS server assumes that BIND scrubs out the poisoning attempt. BIND4 and BIND8 do NOT appear to scrub the attack. Windows DNS trusts the data and the Windows DNS cache will become poisoned."

So much for "only affects MS servers" although the article does mention, and plays down ("ancient versions") the bind4/8 vulnerabilities.
I'm left wondering how many admins have their dns servers in forwarding mode, and how many of those are forwarding to bind4/8 servers? Very few, I'd think.

It's important to note, from what I've understood of it so far, that this exploit only affects the "MS server forwarding it's requests to a bind4/8 server" scenario which I would think, would be a pretty negligible number of DNS servers?!

Another interesting thing that caught my eye, was "On Windows 2000, you should manage the DNS cache protection security setting through the DNS Management Console. On Windows 2000 below SP3, the "Secure cache against pollution" is not the default so you should enable it using the DNS Management Console.
An admin who didn't already do this is dumb beyond belief, hardly a MS problem! Blaming it on MS is akin to blaming Ford if you forget to lock the door on your car. If you're a DNS admin and didn't think to check your configuration for this very old vulnerability it's time you hung up your admin hat!

For the record, I'm no more a fan of Windows than I am of *nix - but how much you wanna bet this post'll raise 80% MS bashing comments, 10% "funny" comments, and maybe 10% useful DNS Admin comments?

Re:From the Internet storm-in-a-teacup dept...

[AK Marc]

Blaming it on MS is akin to blaming Ford if you forget to lock the door on your car.

Nah, It'd be like blaming Ford if they sold all cars without oil in them and had, on page 545 of the 2000 page manual, directions to add oil before use.

Sure, they tell you and it is documented, but you shouldn't have the server install insecurely by default. The default should be secure, and then you need to enable the services you need. Less user friendly, more secure - that is why it isn't adopted by MS. They made a conscious decision to make it insecure (but easier to use). That is why MS bashing is justified.

Re:From the Internet storm-in-a-teacup dept...

[tliston]

So much for "only affects MS servers" although the article does mention, and plays down ("ancient versions") the bind4/8 vulnerabilities. I'm left wondering how many admins have their dns servers in forwarding mode, and how many of those are forwarding to bind4/8 servers? Very few, I'd think.

Think again.

You don't seem to be understanding the terminology. It isn't talking about situations where MS DNS will "forward to" BIND4/8. You receive DNS information from a "forward". Many/most ISPs run BIND and quite a few are running version 8. It appears that any MS DNS server using those servers as a forward will be vulnerable.

-TL

Re:From the Internet storm-in-a-teacup dept...

[Anonymous Coward]

"In other words, many or most 2000 installations should be secure against pollution if their admins posess the slightest clue."

Actually, no clue needed. Win2k DNS server has since SP3 made this the default setting. Win2003 DNS server also makes this the default setting.

So, zero action is required by Windows DNS admins, unless for some reason they are running Win2k pre-SP3, or NT4. Even with these older versions of the OS, a single setting change secures the box from DNS poisoning.

Re:From the Internet storm-in-a-teacup dept...

[Anonymous Coward]

Except you are wrong. Go back and re-read the article.

WRT DNS poisoning, Windows DNS servers have been secure by default since Windows 2000 SP3. The only vulnerability exists if they are getting already poisoned data from a vulnerable server (BIND4/8) used as a forwarder.

Re:From the Internet storm-in-a-teacup dept...

[Eyeball97]

Ummm... no, I understand the technology well enough. I think you just repeated what I said - that the "MS" end of the equation is vulnerable only if it's forwarding to a poisoned bind4/8 server.

A quick Google (I'm not wasting more than 30 seconds on this) shows bind8 vulnerabilities as far back as 2002, and bind 9 being released 4 months ago (having been in beta for several months before that). If "quite a few" isp's are still running bind8, there are "quite a few" negligent DNS admins!

Isn't the bigger issue, that the MS server is not inherently vulnerable unless it's forwarding to a poorly maintained *nix server?

Furthermore, it doesn't "forward" out of the box. It uses root hints to ask the authoritative server for answers. An admin would have to deliberately configure it as a forwarding server - and if he does so not knowing how secure the server he's forwarding to is, again he deserves what he gets.

Re:From the Internet storm-in-a-teacup dept...

[tliston]

I'm not disputing the "negligent" issue. You're correct.

However negligent they may be, the facts are:

~72% of DNS servers run BIND.
~28% of those run versions less than 9

Also, the BIND servers themselves aren't poisoned. When they do the initial lookup, they forward the poisoning information along, but don't cache it themselves. Subsequent lookups come from cache (and therefore don't contain poisoning info), but by then, it's too late.

-TL

Re:From the Internet storm-in-a-teacup dept...

[spitzak]

My understanding is that if the network consisted only of older Windows DNS servers, it would be subject to this problem. If it consisted only of Bind8 then it would not. The bug in bind8 is that it copies the bad data from Windows. But if you had no bind8 servers, you would still get the bad data from Windows when looking up web sites. Therefore I would say the serious bug is in Windows.

More at fault though is the total parnoia about back-compatability that seems to actually be hurting everybody, Windows and Linux. It's obvious that somebody at Microsoft actually fixed this problem and added it to their DNS. But rather than just turn it on, they added a "configuration" so you could set it, and defaulted it to off, probably because of a worry that it would somehow break something (all these reports say nothing about this switch actually breaking somethings).

Certainly Linux has long been guilty of shipping with all kinds of broken services switched on (an original RedHat 6 or so box is far more vulnerable than anything today), and that was due to paranoia about being incompatable.

Re:From the Internet storm-in-a-teacup dept...

[spitzak]

Actually further reading of the article leads to the same conclusion, except it appears the communication between bind and Windows DNS is the other way.

It sounds like bind9 removes the data that can poison Windows DNS, yet bind8 and earlier will pass it through. I don't understand why these earlier ones pass the data yet don't get "poisoned" themselves, but I really don't know how DNS works.

In any case I stand by my original statement that a network of only older Windows machines would be vulnerable, and a network of only older Bind machines would not. Therefore I consider this a Windows bug. Your complaint is like saying the mail server that passes through a Windows virus is at fault and not the Windows machine that executes that virus.

Re:From the Internet storm-in-a-teacup dept...

[Anonymous Coward]

Actually, many Win server ARE vulnerable, irrespective of their patch level:

"There seems to be other possible scenarios where cache poisoning can occur. When forwarding to another server, Windows DNS servers expects the upstream DNS server to scrub out cache poisoning attacks. The Windows DNS server accepts all data that it receives, regardless of the setting for protecting against cache poisoning. So vulnerability of the attack depends upon whether the upstream DNS server is filtering out the attack."

RTFA!

Re:From the Internet storm-in-a-teacup dept...

[McSpew]

In other words, many or most 2000 installations should be secure against pollution if their admins posess the slightest clue.

You've forgotten an important point, here. Windows DNS servers implicitly trust any servers they forward to, regardless of the "secure cache from pollution" setting. That's not good. Also, until this little brouhaha got enough attention from ISC, MS's KB articles were inaccurate and misleading.

You're also wrong about BIND. BIND 4/8 aren't vulnerable to DNS cache poisoning. They correctly ignore attempts to poison their caches. Unfortunately, they don't bother to scrub the poison when they pass that information on to servers that forward to them.

It's important to note, from what I've understood of it so far, that this exploit only affects the "MS server forwarding it's requests to a bind4/8 server" scenario which I would think, would be a pretty negligible number of DNS servers?!

Well, it's not as obscure as you'd think. My ISP (AT&T) runs BIND 8, and I had my otherwise-properly-secured Windows DNS servers set to forward to AT&T's DNS servers in order to improve performance and reduce unnecessary traffic. When I finally got ahold of AT&T (after ISC's update about the BIND/Windows connection) and verified they were running BIND 8, I was told I should stop forwarding to AT&T and use the root servers. They were almost indignant that I had been forwarding to them. I stopped forwarding, but I wasn't too thrilled with AT&T's attitude--it leads me to suspect they have no plans to either upgrade to a newer build of BIND, nor to warn other customers that forwarding to AT&T's DNS from Windows is a Bad Idea.

Now, I'm not too sure about you, but in my book, AT&T is a pretty big ISP and they've probably got more than a few customers running Windows DNS and forwarding to AT&T's servers. Maybe none of them are Cybertrust customers, but I'd suspect it's a decent-sized chunk of people, even if it is a small percentage of the companies connected to the Internet.

Re:From the Internet storm-in-a-teacup dept...

[McSpew]

So, zero action is required by Windows DNS admins, unless for some reason they are running Win2k pre-SP3, or NT4. Even with these older versions of the OS, a single setting change secures the box from DNS poisoning.

Except, as has been pointed out in TFA, when you forward to another DNS server. In that case, Windows ignores your security settings and believes everything it hears from the server it's forwarding to. BIND 4 and 8 pass poisoned entries to servers that forward to them. Since Windows ignores its own security settings in that scenario, it happily accepts the poison. No amount of clue can prevent this problem if your Windows DNS forwards to another server that gets poisoned or doesn't bother to scrub poison before passing it on.

Re:From the Internet storm-in-a-teacup dept...

[AK Marc]

Windows DNS servers have been secure by default since Windows 2000 SP3.

So, for all MS OSs prior to 2000 SP3, do you think they were secure? Do you think that 2000 SP3 would have been secured if people hadn't complained loudly and often?

Re:From the Internet storm-in-a-teacup dept...

[theendlessnow]

Blaming it on MS is akin to blaming Ford if you forget to lock the door on your car.

Actually the analogy is better said that Ford sells its car with an optional lock feature that can be enabled by a certified Ford technician or a person with some automotive repair experience. If you don't have the feature enabled... then it's your fault if your car gets stolen.

How strange, a car-computer analogy on slashdot!

Comcast, last night all DNS servers down

[Anonymous Coward]

I was happly using my Dual 2 Ghz and 30" screen when all sorts of nasty things happened. Which is a rarity for us Mac users as you all know.

1: Netstat hung process

2: Mail hung

3: Finder reboot wouldn't load menu bar

Nothing worked until I actually changed my network settings, then everything cleared up. I jumped on my 56k and chatted with Comcast after waiting almost a hour.

I simply said "What happened, something big?"

Comcast: "Yes we know, all our DNS servers are down"

http://homepage.mac.com/hogfish/PhotoAlbum2.html

Re:Comcast, last night all DNS servers down

[Anonymous Coward]

I drove to work yesterday in my 394-horsepower BMW Z8 and my computer didn't work either.

Re:Comcast, last night all DNS servers down

[stratjakt]

I'm a comcast customer, and fucked with my linux router for about an hour last night trying to figure out what the blue hell was going on.

It has a habit of just shitting out every time my dhcp lease expires, rather than refreshing it and moving on with life, so I figured that was it, or perhaps dnsmasq (which I use to proxy for my lan) got fubared.

Eventually I just plugged my cablemodem into a windows box, since they "just work" without fighting a bunch of resolv.conf or /etc/conf.d crap, and it had the same problem.

At that point I realized it was their DNS servers, since I could ping them, but they wouldn't resolve queries, and I just waited it out.

Interesting. Do you know for a fact that it was because of this poisoning stuff, and not because the new guy tripped over the cords?

They could have had their dhcp servers send out, at least temporarily, a good upstream DNS server, rather than piss off umpteen billion customers.

Re:Comcast, last night all DNS servers down

[Anonymous Coward]

Eventually I just plugged my cablemodem into a windows box, since they "just work" without fighting a bunch of resolv.conf or /etc/conf.d crap

That's funny.. I would have plugged into a linux box to AVOID the windows crap, and have it "just work" and be easy to debug with dhclient, ifconfig, and /etc/resolv.conf.

Re:Comcast, last night all DNS servers down

[stratjakt]

What do you mean debug?

I wasn't the least bit interested in debugging Comcast's problem. I thought it was something borked on the linux box, which is really very common. For instance, sleepycat DB, the ubiquitous backend for everything on linux, is notorious for just deciding to be corrupt all of a sudden.

If XP didn't work by simply plugging it in and hitting repair, it's a comcast problem. That should have been the first thing I looked at, really.

Re:Comcast, last night all DNS servers down

[Electrum]

They could have had their dhcp servers send out, at least temporarily, a good upstream DNS server, rather than piss off umpteen billion customers.

There is no such thing as a "good upstream DNS server". There are authoritative DNS servers and there are DNS caches (also called resolvers). The root DNS servers are authoritative only. You cannot use them to resolve DNS queries.

If you want to resolve queries you need to run a DNS cache, use your ISP's, or use one somewhere else that someone left open. Running a promiscuous DNS cache is a bad idea.

Re:Comcast, last night all DNS servers down

[Anonymous Coward]

Sad to say, but this tells you something about Windows vs Linux. :(

I use Suse 9 for my home server and WinXP for my main pc.

Re:Comcast, last night all DNS servers down

[Anonymous Coward]

Maybe we should all keep several public DNS server addresses handy, in case it went down again.

Re:Comcast, last night all DNS servers down

[J. Random Luser]

There is no such thing as a "good upstream DNS server".
True, but some are more "reliable" than others.

If you want to resolve queries you need to run a DNS cache, use your ISP's, ...
First part, yes. Second part, don't rely on your ISP alone, specially if he's giving you a DNS address via DHCP. At the first sign of shit, hardwire a more reliable one.

Re:Comcast, last night all DNS servers down

[Quattro Vezina]

I'm also a Comcast customer, and I had the same problem, as did everyone else I know. It seems to be fixed now.

DNS poisoning?

[Nom du Keyboard]

DNS poisoning?
What DNS poisoning?
Isn't this www.NerdsMeetingExcitingGirlsOnLine.org?

Get off the network

[jeffmeden]

If we were really dealing with an ideal 'invisible hand' at work, the smart, money-saving people would leave 'the' internet and start their own security-required network, which would quickly become the larger network and regain the distinction as 'the' internet, thereby forcing everyone on the 'old' internet to get secure in order to join up. But that doesn't happen, does it. Sadly, the invisible hand is only good at two things, truly open marketplaces, and giving you the finger.

hooooly sweet crap!

[happymedium]

"I offer $500 to the first person to publicly report a verifiable security hole in the latest version of djbdns."

(djbdns being the software written by the author of the "rant" above.)

Now if only MS were so generous. ^_^

Re:hooooly sweet crap!

[Electrum]

qmail has a similar security guarantee. It was offered in 1997 and has never been claimed.

crapcast

[Anonymous Coward]

actually crapcasts problem was fixed about 13 hours ago as of right now.

Thats what you get when an entire isp uses a single pair of dns servers in denver for the entire country.

janitor: (hey whats THIS wire for!)

Re:crapcast

[UWC]

Glad my suspicions were correct last night. Took forever to access a domain by URL, but once accessed, it seemed fine. And yeah, it's definitely been fixed longer than two hours, as it seemed to have been corrected earlier this morning when I checked.

Didn't know their DNS servers were so centralized.

Unfortunately Comcast is the only cable provider in town, and I had already become dissatisfied with local DSL offerings.

Re:crapcast

[Anonymous Coward]

Yup. Comcast is the largest isp in the country now. And around here. The best. Service and price.

I had them out here at 10pm on a sunday to reset the breaker in the repeater out front once. Very cool.

Try getting verizon to do that!

Thats what struck me as odd. that my dns was in denver. thats a LONG way from where im at. And i'd swear it used to be in chicago the last time they had dns problems and i was poking around.

At least if it goes down now. I dont need to call. Since there will be several million people in the same situation.

Mod Parent Up

[Daedala]

It's an externality. The invisible hand of the market isn't going to fix things for you

link with explanations

[Anonymous Coward]

Here is a good explanation at security focus

http://www.securityfocus.com/guest/17905

Re:Mod Parent Up. Crude == Funny

[Bonzor]

Nobody loves me :(

Additional Bind 9 security

[Anonymous Coward]

Even if you are already running Bind 9, you should consider reading Rob Thomas' Secure BIND Template for how to best configure bind.

Bind 4?

[duffbeer703]

Why is anyone still using Bind 4? Is there any justifiable reason for doing so other than sheer stupidity or laziness?

Re:Bind 4?

[Anonymous Coward]

Probably the same reason windows admins don't path theri systems. Yes just plain stupidness.

The article is a troll though. I like how he says Only windows then (and a couple versions of bind)

Re:Bind 4?

[stratjakt]

And only on Windows if the Admin was clueless enough to deselect the "protect against cache poisoning" box.

Yep, as with everything else, lousy admins = MSFT's fault.

Then they all hop on slashdot and start screaming racist bunk against Indians when they find themselves unemployed.

Re:Bind 4?

[Anonymous Coward]

There are those who prefer BIND 4 to BIND8 or 9, for various reasons.

There ARE somewhat secure/patched versions of BIND4 out there, notably Openwall'spatched version.

OpenBSD had a patched version of BIND 4 until a few distributions ago.

Anyways, it's funny to see that DNS Cache poisoning is still happening today. This was so 1990s.

I've never any problems using djbdns.

Re:Bind 4?

[Tony Hoyle]

On Windows it's *select* not *deselect*

Windows is insecure by default. Also that option isn't obvious at all.

There are other reasons I won't use Windows DNS but this doesn't help...

Re:Bind 4?

[Anonymous Coward]

You misread the summary. He didn't say windows and a couple of versions of bind. He said windows. And that bind9 will fix bad windows entries but not bind4 and bind8.

Michael

Re:Bind 4?

[Anonymous Coward]

" On Windows it's *select* not *deselect*
Windows is insecure by default. Also that option isn't obvious at all."

Umm, after SP3 it is most certinaly *deselect*.

Like the gp said. It must be Microsofts fault for having bad admins.

You sir are a retard.

Re:Bind 4?

[Anonymous Coward]

You are a very poor troll.

At least make somethign up if you can't argue the facts. Oh wait you did make somethign up.

Well, better luck next time.

Re:Bind 4?

[agallagh42]

"Windows is insecure by default."

In this case, it's not. This setting has been secure by default since the release of SP3 in 2002.

"Also that option isn't obvious at all."

How much more obvious does it need to be? It's plain as day on the advanced tab in the DNS server properties GUI.

Re:Bind 4?

[Anonymous Coward]

Yes, it's plain as day.

Just like their 'Make this computer hack-proof' checkbox. Can't get any more clear than that; after you click on the advanced tab, then preferences, then select security in the dropdown menu, jump up and down, and click next, its right there!

Re:Bind 4?

[agallagh42]

No need to be a weiner about it. Seriously, you click the advanced tab, and right there, it says "secure cache against pollution". There's a little checkbox beside it. There's also a little checkmark in the checkbox by default.

what is a daypass then?

[nietsch]

Is it something you don't get if you make enough inflamatory posts?

Re:what is a daypass then?

[Anonymous Coward]

Actually I just got one, so I guess the lesson here is compain and thou shall receive.

Crude and quite possibly befuddled answer

[A nonymous Coward]

djbdns dvides what BIND does into two entirely separate programs. One, tinydns, is authoratitive for its specific domains and nothing else. It might even drop all requests for anything else, I am not sure. The second program, dnscache, queries other, authoratative, name servers, and returns complete dns lookups. It will only query authoratative name servers; it will discard responses that are not authoratative.

DJB makes a big point in his documentation for djbdns about this. I get the impression that other (all? most? older?) name servers can be poisoned because they will accept non-authoratative answers as gospel.

For instance ... suppose you look up www.yahoo.com. You should start by asking the root servers for com, choose one of them to ask about yahoo, choose one of them to ask about www.

That seems so common sense to me that I do not quite understand DJB's complaint, yet apparently there are servers which will cache other addresses for which they are not authoratative. If I ask, say, plugh.com who is www.yahoo.com, and it has recently looked that up, it will pass it along to me as if it really really knew. djbdns will not, it will instead tell me to look it up properly.

How plugh.com gets bogus info for www.yahoo.com to start with is another question that I do not have any understanding of.

At least I think that is some of the flavor of cache poisoning.

Re:Crude and quite possibly befuddled answer

[Anonymous Coward]

authoritative authoritative authoritative

Re:Crude and quite possibly befuddled answer

[tedgyz]

Thanks for the explanation. As you indicated in your ending comments, you have described how a poisoned cache can spread poison. The unanswered question is, where does the poisoning originate?

Re:Crude and quite possibly befuddled answer

[Mr Guy]

From muddling through the crypto link above, it seems what would happen is I'd go ahead and set up my DNS and lie to it.

For example, I'd tell my DNS (correctly) that I'm suchandsuch.com. Then I'd lie to it and tell it that I'm also mandriva.com (Like anyone would use a stupid name like that). I'd then go to another machine on the internet and ask for something to resolve to suchandsuch.com, maybe emailing or http. When that machine looks up suchandsuch.com, apparently it'll see my devious lies about mandriva.com and it'll believe them. From then on anyone who hit that machine and was vulnerable would think I was mandriva.com

That's my limited understanding at least, because no one is being more clear to laymen.

Re:Crude and quite possibly befuddled answer

[Vainglorious Coward]

The unanswered question is, where does the poisoning originate?

From a DNS servers under the control of the perpetrators. In some cases, they are "merely" spammers, pimping products via webpages. The much more serious and sinister use is for phishing-type attacks - there's no need to create a domain-name or URL to try and fool the unwary if you can control where the genuine name/URL resolves to.

Re:Crude and quite possibly befuddled answer

[tedgyz]

Ok. I have all the pieces. Now I'm trying to fit them together...

Let's say I'm pimping the Robomatic 3000 Orgasmatron. I own lameproducts.com and have an authoritative DNS server running for that domain. I can add an entry in my DNS config that says shopping.yahoo.com is really the IP address for lameproducts.com.

What I'm trying to understand is, how does luser@aohell.com pick up the poisoned entry for shopping.yahoo.com. How would lameproducts.com get into a user's DNS chain? To put it another way, what is the sphere of influence of lameproducts.com. How the hell would someone trust them to be part of their DNS chain? Do you have to be on the same subnet? The same ISP?

I'm just trying to understand if I am at risk. Sorry if I don't have all the DNS lingo down.

Re:Crude and quite possibly befuddled answer

[tedgyz]

Someone has since posted a good explanation here.

Re:Crude and quite possibly befuddled answer

[inode_buddha]

If you follow the handler's diaries at isc.sans.org, they've narrowed it down to a handful of malware-infested sites which are presumably related.

Haors

[Anonymous Coward]

Why doesn't someone just 0wn the haxors who do this? Why is no one talking about justice being done?

Could it be that all you geeks find this rather exciting what with the "storm warning" (wtf) and "poisoning". ffs.

TCP/IP

[Anonymous Coward]

The whole point of Internet Protocol is to facilitate in the sharing of data. Even if you start your own private network you will most likely still use IP.

I used to be foolish and think like you, but no matter what the physical layer is, it still makes sense to have an IP stack and run Internet Protocol. And even if you have a different protocol, say ATM or some other, you use MPLS, and that translates between any two generic protocols and it all translates to TCP/IP.
You can't get away from it unless you want to redesign the way that networks behave. And if you do that why would anyone want it when the Internet already works. Whatever problems we have with BIND will be legion in your propriatory system. As buggy as some people make their versions of BIND, or whatever other piece of the Internet Toolset, their are other vendors or suppliers (often Open Source) who create code that doesn't have those problems.

Try the private network thing if you want, but it will cost you a lot. Why do this?

DJB is laughing this up I'm sure

[photon317]

When will the world learn to stop using BIND?

Re:DJB is laughing this up I'm sure

[SpaceLifeForm]

When will the world learn to stop using BIND?

When there is a better GPL replacement.

Re:DJB is laughing this up I'm sure

[Anonymous Coward]

There are GPL and GPL-compatible DNS servers out there besides BIND:

• MaraDNS
• Posadis
• PowerDNS (Recursion is incomplete and not part of the base package)
• NSD (No caching nor recursion)
• MyDNS (Specialized for people who insist on using MySQL to store DNS records)

Because of the Word from Upstairs.

[AltGrendel]

Often, its not an option to use something else. The shop I use to work for used BIND for the same reason many shops still use sendmail. It's a common denominator. It's not the best, it's not the worst, but it's definitely in use and alot of admins know it (to some degree).

Windows... let's lock 'em out.

[rice_burners_suck]

I really think the right thing to do at this point is to set up BIND 9 to completely ignore anything coming from a Windows DNS implementation. That will leave only Windows users stuck with the problem.

Re:Windows... let's lock 'em out.

[Anonymous Coward]

And what about that bind4/8 thing?

Re:Windows... let's lock 'em out.

[Anonymous Coward]

You can run BIND 9 as the DNS on Windows machines instead of using the Windows DNS. Then you can run your DNS just like you do on Unix machines. Then the Windows DNS problem is solved. The faith in the BIND 9 DNS is a lot higher than the Windows DNS. And if there is a problem with BIND 9 I'm sure that a fix is going to be made available a *lot* faster and will be installable on older Windows OS's too.

You can run BIND 9 on Windows using Interix (part of SFU): a BIND 9 binary package is available at http://www.interopsystems.com/tools/
There's likely a cygwin port of BIND 9 too.

So this explains why...

[Anonymous Coward]

... I had to call my ISP to get new Primary and Secondary DNS settings. The old settings worked fine for 7 years straight and then mysteriously crapped out a few days ago.

Djbdns - immune to DNS cache poisoning

[bad_outlook]

Djdns deserves another mention. Here's the thread that came up a few days ago on the subject. I'm running it on FreeBSD now, and have learned allot through this discussion (that hasn't happened to me on /. for a long time either, so it was pretty cool.

Previous /. THREAD

Djbdns site with a ton of good information

I like it.

bo

Silver lining

[jmichaelg]

Once I figured out that Comcast's dns server was gone, I reconfigured my network setting to use another dns pair. (Not for nothing do I record old tcp-ip setting values!)

It was like being on a ten lane freeway all by myself - everything was fast!

Only question now is does Comcast fire their CTO who recommended using Windows-based servers or do we get to see a repeat meltdown somewhere down the road?

Re:Silver lining

[bhsx]

I was shocked to realize that comcast uses windows for dns. I mean, think of the scale that comcast serves. How could they even think about putting that many millions of users dns on anything but a tried and true unix system. I'd think they were running Sun/Solaris or maybe AIX on most of their backplane.

Re:i got me...

[Anonymous Coward]

i have a quarter million UID and i got one this morning, i bet it's tied to metamod somehow

Simple explanation

[Otto]

DNS Poisoning is possible because of the way some DNS servers work.

When you want to lookup a site, you send a request to your DNS server, which then does the lookup and returns the results to you.

Say you need to know the address to www.yahoo.com. You ask the DNS server for it. It doesn't know, so it looks at what it does know. In the simplest case, it knows the address of the DNS server for *.com, so it asks him. He replies that he doesn't know either, but that he knows *.yahoo.com's DNS records are stored at x.x.x.x. So your DNS server goes and asks x.x.x.x. He does know where www.yahoo.com is, tells your DNS server, who then sends you back the address.

Typically, a DNS Server is running for a lot of users at once, so it improves speed by caching the results of these queries. So if you asked for www.yahoo.com again, your DNS server looks in the cache, finds that www.yahoo.com is in there, and gives you the answer right away. No need to look it up, time saved all around.

DNS Cache Poisoning is where an attacker tricks a DNS Server into caching incorrect information. This can happen by having a rogue server setup somewhere. So say the nameserver for www.badguy.com has records that say his name is also www.yahoo.com. When you lookup www.badguy.com, and get to that point, badguy.com says "hey, this is my address, and here's some other names that I'm known by: www.yahoo.com". Your DNS Server then stores all that info in his cache. Later you lookup www.yahoo.com and get back the address for www.badguy.com instead.

That's a slightly oversimplified way to explain it, but that's the gist of it. Somebody can trick your DNS server into giving back bad info. This is a critical security issue, because say they poison your cache and fool you into connecting to their server instead of, say, your bank's. They then give you a web page that looks just like your bank's does, you login as normal, and suddenly they have all your cash.

Many DNS servers are immune to this. How is simple: They don't cache stuff when badguy.com says he's also yahoo.com. They always go ask who yahoo.com is and only cache that more trustworthy answer.

However, the DNS system is setup as a hierarchy. Your DNS Server may not talk to root servers all the time, he might route all his queries through another, bigger DNS server. One of the bugs discovered here is that even if your DNS server is not vulnerable, the one just upstream of it might be, and that can propagate down to yours.

So there you go.

Re:Simple explanation

[Anonymous Coward]

perhaps redundant after the wonderfully lucid explanation from Otto above, but here is DNS for the less gifted, should you really require it...

MOD PARENT UP!

[Agent_9191]

Pretty good explanation. I'm a programmer (who's forced to do networking) and have just enough knowledge on DNS to see exactly how that could happen.

At least I'm consistent

[A nonymous Coward]

:-) and thanks, it looked odd while typing ...

Re:ACK!!!

[Anonymous Coward]

Isn't that one of those things they do to help choking people? The hemlock remover? Anyway, that stuff tastes great! Drink up...

anti-binders?

[NightEyez]

bind8 and bind64 are inappropriate in these matters. A simple netbstat -4/k! command in the subprocessing warp chambers will act as a perfect anti-binder, correct? To hell with DNS poison! Damn the photon torpedoes!

It's all very muddy

[A nonymous Coward]

See, I don't even see why poison spreads. Yes, if aohell.com were dumb enough to ask lameproducts.com if it knows who shopping.yahoo.com is, then I can see the poison spreading, but there are two related unanswered questions ... what would it take to get aohell.com to ask lameproducts.com who shopping.yahoo.com is, and why would aohell.com even trust some unrelated site in the first place so that it could be tricked into asking?

But maybe that's why Windows and old BIND sites are susceptible. Maybe it ws some optimization, like thinking, hey, I've got ten more sites to look up, I'll ask this unknown DNS server just on the off chance .... maybe back in the old slow days, it was a speedup, to save all the time involved for new separate connections for each lookup.

Re:It's all very muddy

[Vainglorious Coward]

what would it take to get aohell.com to ask lameproducts.com who shopping.yahoo.com is, and why would aohell.com even trust some unrelated site in the first place so that it could be tricked into asking?

The client *doesn't* ask the lameproducts.com DNS server about shopping.yahoo.com, it asks about something in the lameproducts.com domain (typically, prompted by an image embedded in an HTML email). The lameproducts.com DNS server sends back the answer about the request for the system in the lameproducts.com domain, but it *also* tacks on some more information about other domains for which it is not authoritative. A sensible client would simply ignore this additional information since (a) it never asked for it and (b) the information is outside the responding DNS's bailiwick. Unfortunately, there's a number of DNS caches out there that do not take a sensible approach.

Re:It's all very muddy

[tedgyz]

Based on the explanation here, I believe the answer is this:

luser has an un-patched DNS server at aohell.com. luser clicks some stupid spam mail which brings it to lameproducts.com. The DNS server at lameproducts.com gives a response which says, "Here is the IP address for lameproducts.com (authoratative). BTW, I am also known as shopping.yahoo.com (non-authoratative)." When luser then decides to see if shopping.yahoo.com has a better price on the Robomatic 3000 Orgasmatron, the un-patched DNS server at ahell.com says, "I already know shopping.yahoo.com. Here you go." luser goes to same site, URL in browser shows http://shopping.yahoo.com./

Man, if you can't trust DNS, who can you trust?

Is this affecting anyone's hardware routers??

[King_TJ]

This might sound like a stupid question, but I just spent the last few evenings fighting with DNS resolution problems on my home LAN, only to finally resolve it (at least for now) by a hard reboot of my Hotbrick LB-2 load-balancing router/firewall.

I have both a Charter cable modem and SBC DSL coming into my house, and the Hotbrick load-balances both connections and shares them to my PCs.

I started encountering an odd problem the other night where it seemed like after I initiated a file download, subsequent DNS requests (web pages, checking email, etc.) would just time out and fail. It was a bit erratic, but all my configuration settings appeared correct. (My Mac and PCs just use 192.168.0.1 as their DNS entries, since that gets them to the Hotbrick, which actually does the DNS resolution.)

Until now, I've had the Hotbrick running flawlessly for months on end, so the need to reboot it now puzzled me. This article made me wonder.

Re:Is this affecting anyone's hardware routers??

[zioncity]

I had the same problem basically. I noticed some sites took longer to access via web browsing lately. Last night at around 8pm, I came home to find mail.app would not work, nor would getting my default start page of google on my web browser.

So I figured,.. access my cheapie, but reliable SMC router and release the DNS connection and then renew... this was easy enough... but no fix. Okay.. reboot the modem, router and switch via unplugging and turing on in the same order. No fix.. okay.. I saw that the Belkin router in my room was not rebooted, did that.. no fix.

Tried hooking up my iBook directly, no go... but my roommates PC laptop would sorta work on Google and msn, even with a search only, but not when clicking on other links.

After reading this article on DNS poisoning etc... I am kinda relieved I 99.99% will not have to buy a new router as the night before I was introduced to iGetter for faster web downloads and the wonder of Independent Fan film sites and all that can be downloaded. Why download at 20-35k for a 120meg file when you can at 250-450k instead?

Now I get to go home and be a download whore again tonight, woo hoo.

Oh yeah... instant side thought... if this only affects Windows DNS servers etc.. how long before more Net Wide hacks and hoaxs due to the unlimited number of flaws in Microsoft products happen to us. OH yeah.. I forgot... if everyone still uses the many flavors of Microsoft products, then those people who preach and advise the continued use of it will still be in a job,.. as in a world full of much more OS X boxen and Linux Boxen and many IT guys getting the whole dot.com bust effect all over again.

Ahh.. what a wonderful world we live in.

-------
Zion's Sarcasometer is set to 11 baby!

Time to stop the DJB fanboy FUD

[Anonymous Coward]

Time to stop the DJB fanboy FUD.

BIND 9 is a complete rewrite of BIND. It has none of the security issues that older versions of BIND has. In particular, the best security attack against BIND 9 results in a denial-of-service; any such DOS attacks have been patched by the ISC.

BIND 9 also has a number of security features DjbDNS doesn't have. Starting with DNSSEC. Also, it has full support for DNS-over-TCP, which stops a certain attack that DjbDNS is not capable of stopping.

Stop listening to the DJB fanboy FUD and start paying attention to the facts. If you don't mind the fairly large footprint BIND 9 has, it is a completely free, secure, and excellent solution to your DNS needs. If BIND 9 is too big for you, there are other DNS solutions that are lightweight and aren't DjbDNS.

One fact DJB fanboys won't tell you is that DJBware is not free software.

Re:Time to stop the DJB fanboy FUD

[Anonymous Coward]

So, you're telling me it's time to start listening to the anti-DJB zealot FUD?

What does this mean for EPCglobal?

[supersat]

From what I understand, in the future, the EPCglobal system (which is being positioned as the replacment for UPC/EAN barcodes) will use DNS as the core technology behind their ONS (Object Name Service) system. So, if a store sees a new EPCglobal RFID tag and wants to know what it is, it can simply execute a DNS query to find out. I'll admit that I haven't looked very closely at the proposed architecture, but this seems like a recipe for disaster when combined with DNS poisoning, especially if automated checkout systems are used that read the EPCglobal tag on every item. I could imagine someone poisoning a store's DNS server, changing product information, such as the price, and causing all sorts of havok.

Re:What does this mean for EPCglobal?

[Jesus_666]

I could imagine someone poisoning a store's DNS server, changing product information, such as the price, and causing all sorts of havok.

You mean objects are falling down realistically and occasionally get stuck in the walls?

RTFA

[Anonymous Coward]

RTFA you nit.

The advisory states that this issue has already been fixed in Windows from Windows 2000 Service Pack 3, which was released 3 years ago. Windows 2003 has always been secure to this attack, and Windows NT is securable through a registry key.

You can..

[Xyl3ne]

You can just change your DNS server information in Windows easily to 4.2.2.1. I didn't do it on my Linux box, so I don't know how easy it is to change on there. That's what I did last night when Comcast shit out and my problems went away. I must have been the only person in town able to get online, heh.

Re:You can..

[michaelhood]

It's easier in Linux.
edit /etc/resolv.conf

You're reaching now ...

[Anonymous Coward]

He ducks! He dodges! He backpedals!

Dunno how many complaints there were, but I don't recall any great hue-and-cry. Do you? Can you link it? Don't forget, pre-Win2k/SP3 versions were securable with a single setting, as I said before.

bzzt! Wrong!

[Anonymous Coward]

Not much clue is required to prevent this problem. If you had read the article (or thought for a moment), you'd see it:

1) Check for defined forwarders on your DNS servers. Got none? Good, you're done.

2) For each defined forwarder you have, speak to whoever admins that server. Make sure they aren't using forwarders, and aren't poisonable. If you can't verify this, change to forwarders that meet these criteria, or stop using forwarders and start doing your own resolving.

Yes, BIND4/8 are vulnerable

[Anonymous Coward]

You're also wrong about BIND. BIND 4/8 aren't vulnerable to DNS cache poisoning. They correctly ignore attempts to poison their caches. Unfortunately, they don't bother to scrub the poison when they pass that information on to servers that forward to them.

From what you said about checking with AT&T, I suspect that's a typo, but if it's not, check this:

Google

The SecurityFocus article is especially good. Anyway yes, BIND4/8 are directly vulnerable to poisoning. Some later versions of BIND8 are fixed, but really, BIND9 is the way to go (imho).