Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security The Internet IT

DNS Cache Poisoning Update 199

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."
This discussion has been archived. No new comments can be posted.

DNS Cache Poisoning Update

Comments Filter:
  • Informative Links: (Score:5, Informative)

    by TripMaster Monkey ( 862126 ) * on Friday April 08, 2005 @12:28PM (#12177889)

    In the interest of promoting discussion, there is a good definition of DNS poisoning here [wikipedia.org], and a longer explanation/rant regarding DNS poisoning here [cr.yp.to].

    • by TripMaster Monkey ( 862126 ) * on Friday April 08, 2005 @12:31PM (#12177928)
      Hmm...the # sign in the second link doesn't seem to work...sorry...try this [cr.yp.to] link instead.
    • by 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
      • by bigberk ( 547360 ) <bigberk@users.pc9.org> on Friday April 08, 2005 @12:43PM (#12178051)
        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.
        • by ldspartan ( 14035 ) on Friday April 08, 2005 @12:52PM (#12178158) Homepage
          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.
          • Well, Gentoo is pretty easy to install if you know the right commands [bash.org]. 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 exa

      • by nothings ( 597917 ) on Friday April 08, 2005 @12:50PM (#12178141) Homepage
        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 [cr.yp.to]. (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 [securityfocus.com], 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.

      • by carpe_noctem ( 457178 ) on Friday April 08, 2005 @12:56PM (#12178206) Homepage Journal
        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.
      • by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Friday April 08, 2005 @01:06PM (#12178291) Homepage Journal
        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.

        • by Electrum ( 94638 )
          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 t
          • by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Friday April 08, 2005 @01:45PM (#12178756) Homepage Journal
            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.

        • 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?
          • 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 eac

      • by Anonymous Coward
        If that DJB bloke weren't so damn arrogant, many admins would have much less of a problem with using his software.
      • 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 nee

    • 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 tes
      • 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 t
        • 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.

          • by mlyle ( 148697 )
            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 reco
      • by cmacb ( 547347 ) on Friday April 08, 2005 @02:37PM (#12179322) Homepage Journal
        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.
    • by foobsr ( 693224 )
      The second link already seems to show white, so [informationweek.com] not exactly a replacement but perhaps an addendum.

      CC.
    • by tedgyz ( 515156 ) * on Friday April 08, 2005 @12:42PM (#12178047) Homepage
      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. :-)
      • 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
        • 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?
          • 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 ma
      • 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 :)
        • 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
      • Simple explanation (Score:5, Informative)

        by Otto ( 17870 ) on Friday April 08, 2005 @02:16PM (#12179124) Homepage Journal
        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.
      • by greed ( 112493 )

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

        • 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

    • "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. ^_^
  • by Silverlancer ( 786390 ) on Friday April 08, 2005 @12:28PM (#12177890)
    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.
  • Update on the Update (Score:5, Informative)

    by Hulkster ( 722642 ) on Friday April 08, 2005 @12:28PM (#12177891) Homepage
    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 [sans.org] (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 [dslreports.com] 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 [comcast.net] it was resolved about two hours ago - scroll down to the bottom of the page.

    • 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.
    • 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.
  • Wow! (Score:1, Funny)

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

    Who knew? Truly, "stuff that matters".
  • Somehow, I just knew Windows was at the root of the whole thing...
    • by 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.
    • Well, actually, the root of the whole thing, ".", is handled by UNIX servers.
  • by Ktistec Machine ( 159201 ) on Friday April 08, 2005 @12:35PM (#12177965)
    ...at least, according to this link [lwn.net] from the lwn.net security page.
  • by Anonymous Coward on Friday April 08, 2005 @12:38PM (#12177999)
    "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?
    • 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.
    • by jeffmeden ( 135043 ) on Friday April 08, 2005 @12:59PM (#12178228) Homepage Journal
      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.
    • Mod Parent Up (Score:5, Informative)

      by Daedala ( 819156 ) on Friday April 08, 2005 @01:00PM (#12178234)
      It's an externality. [schneier.com] The invisible hand of the market isn't going to fix things for you
    • 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?

      • 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
    • by wren337 ( 182018 ) on Friday April 08, 2005 @01:39PM (#12178686) Homepage

      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.

    • 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?
  • I wonder if this is the reason Comcast's DNS servers all took a gigantic shit yesterday.
    • 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 workin
    • 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... (Score:5, Informative)

    by bhsx ( 458600 ) on Friday April 08, 2005 @12:40PM (#12178023)
    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.
    • 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.
    • 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?

      • 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.
  • by spoonyfork ( 23307 ) <spoonyfork@@@gmail...com> on Friday April 08, 2005 @12:51PM (#12178146) Journal
    Could it be coincidence that Comcast is currently experiencing DNS issues? [slashdot.org] Probably.. but it makes me wonder.
  • by Eyeball97 ( 816684 ) on Friday April 08, 2005 @12:53PM (#12178167)

    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?

    • by AK Marc ( 707885 ) on Friday April 08, 2005 @01:08PM (#12178313)
      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.
      • by 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.
    • 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
    • by 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.
      • 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 [sans.org], 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

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

  • by 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/ [mac.com]
    • 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 s
      • 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. Run
        • 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.
    • I'm also a Comcast customer, and I had the same problem, as did everyone else I know. It seems to be fixed now.
  • by Nom du Keyboard ( 633989 ) on Friday April 08, 2005 @12:56PM (#12178203)
    DNS poisoning?
    What DNS poisoning?
    Isn't this www.NerdsMeetingExcitingGirlsOnLine.org?
  • by Anonymous Coward on Friday April 08, 2005 @01:02PM (#12178262)
    Here is a good explanation at security focus

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

  • by Anonymous Coward on Friday April 08, 2005 @01:05PM (#12178276)
    Even if you are already running Bind 9, you should consider reading Rob Thomas' Secure BIND Template [cymru.com] for how to best configure bind.
  • Why is anyone still using Bind 4? Is there any justifiable reason for doing so other than sheer stupidity or laziness?

  • When will the world learn to stop using BIND?
  • 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.
  • 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 [slashdot.org]

    Djbdns [cr.yp.to] site with a ton of good information

    I like it.

    bo

  • 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

Trap full -- please empty.

Working...