Slashdot Mirror

← Back to Stories (view on slashdot.org)

Attack Code Published For DNS Vulnerability

Posted by samzenpus on from the protect-ya-neck dept.

get_Rootin writes "That didn't take long. ZDNet is reporting that HD Moore has released exploit code for Dan Kaminsky's DNS cache poisioning vulnerability into the point-and-click Metasploit attack tool. From the article: 'This exploit caches a single malicious host entry into the target nameserver. By causing the target nameserver to query for random hostnames at the target domain, the attacker can spoof a response to the target server including an answer for the query, an authority server record, and an additional record for that server, causing target nameserver to insert the additional record into the cache.' Here's our previous Slashdot coverage."

205 comments

  1. Here we go... by LostCluster · · Score: 4, Interesting

    This has to be the worst time ever to be a web surfer. How long until we see the major networks broadcasting the legit IP quads of sites we want to reach?

    1. Re:Here we go... by Carnildo · · Score: 4, Informative

      This has to be the worst time ever to be a web surfer. How long until we see the major networks broadcasting the legit IP quads of sites we want to reach?

      There's nothing new about this. DNS cache poisoning attacks have been found before, and the internet hasn't melted down yet. If you're paranoid, run your own caching resolver.

      --
      "They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
    2. Re:Here we go... by Darkness404 · · Score: 3, Insightful

      This has to be the worst time ever to be a web surfer.

      Ummm... No. Today I can easily surf the 'net with just about every ad blocked, have Flash blocked when I want it to, but re-enable it for say, YouTube, all at the click of a mouse. I can use an OS and browser that is free and open source. I can surf 100% anonymously easily. I can download every video game I played as a child in less than an hour. And I can hear just about any song I ever would want to hear in less than a minute.

      Sure, some things suck today, BT throttling, the ISP's "No-Usenet" crusades, but all in all, it is a better time than the very early 2000s or the late 90s.

      --
      Taxation is legalized theft, no more, no less.
    3. Re:Here we go... by Vectronic · · Score: 4, Funny

      "And I can hear just about any song I ever would want to hear in less than a minute."

      Shit, you should check out some of the songs that are longer than a minute, there's some good ones out there, but, yes...those quick little punk ditties are good too.

    4. Re:Here we go... by Martin+Blank · · Score: 5, Interesting

      You may still not be safe. If someone can fire off a XSS attack through your browser, it could do enough lookups to make you vulnerable. Combine this with a periodic other run to a controlled server to grab your source port for guessing (presuming that you have not patched), and you may have a problem.

      Granted, it's unlikely that you would explicitly be targeted, and things like NoScript help defend against it, but there are still possible gaps. In fact, there are several tens of million of systems which will remain vulnerable for some time to come; I haven't seen many SOHO router firmware fixes released so far, and a lot of people point to their routers for their DNS.

      --
      You can never go home again... but I guess you can shop there.
    5. Re:Here we go... by Mordok-DestroyerOfWo · · Score: 2, Funny

      Maybe he just speeds them up so they fit to a nice round minute. I for one would love to hear Freebird sped up so it lasts a minute.

      --
      "Never let your sense of morals prevent you from doing what is right" - Salvor Hardin
    6. Re:Here we go... by LostCluster · · Score: 1

      Your own caching resolver will submarine you for a while, but eventually it has to come up from air and trust some other DNS resolver to see if the info hasn't changed.

    7. Re:Here we go... by harlows_monkeys · · Score: 1, Interesting

      There's nothing new about this

      You are massively wrong. There has never been a DNS attack anywhere remotely as dangerous and effective as this one.

      It is people making boneheaded statements like yours that make people think it is no big deal and they can put off patching.

    8. Re:Here we go... by Vectronic · · Score: 4, Interesting

      lol... you should try it, then you wouldnt think so... I just did (in Sound Forge)... cut it down to 1:08, its just noise... cutting it down to 50% is alright though (4:35)... but somewhere around 65% (5:57) is about right, sounds kinda "proper".

    9. Re:Here we go... by Anonymous Coward · · Score: 5, Insightful

      Yes, there was. Before there was bailiwick filtering, spoofing was even easier. Back in the days, DNS servers would even accept "responses" with bogus data out of the blue. We've come a long way and we don't stop here. A patch of bad weather is ahead, but the sky is not falling.

    10. Re:Here we go... by spankymm · · Score: 1

      You are massively wrong.

      The metasploit code sends bulk randomly generated spoofed replies. If you look at Amit Klein's work on analyzing the PRNG's involved, there are *much* more effective attacks.

      It is people making boneheaded statements like yours that make people think you are a tosser.

      (Everybody still needs to patch/and or enable nat on egress, btw)

      --
      http://cafepress.com/spankymm - for the Masturbating Monkey in you!
    11. Re:Here we go... by Anonymous Coward · · Score: 4, Insightful

      This attack vector has been around for /years/. Just look at the list of affected systems. Some friends and I had stumbled on this a few years ago (yes, and the fact that you can insert yourself as an authoritative nameserver for that domain,) but we figured it was so obvious that it didn't need to be announced. That coupled with the fact that phishing wasn't really as popular back then. But now that the cat is out of the bag, as it were, you definitely want to patch your machines if they have not been. This is mostly dangerous to people who use Nameservers of large ISPs (which admittedly is a large portion of the internet userbase.)

      I guess this is just a wake up call that if you find such large flaws in network systems that could possibly affect millions, if not billions of users, that you should try to get the word out and get the products fixed beforehand.

    12. Re:Here we go... by Anonymous Coward · · Score: 3, Informative

      You can run your own recursive resolver which only talks to authoritative DNS servers. You can configure it to use random source ports if you want to make this attack much more difficult. Then an attacker would have to send you billions of spoofed packets to poison your DNS. That seems a little excessive for exploiting just one user. You could make it even more difficult by rate limiting your resolver (you're its only user after all).

    13. Re:Here we go... by Anonymous Coward · · Score: 0

      Some friends and I had stumbled on this a few years ago (yes, and the fact that you can insert yourself as an authoritative nameserver for that domain,)

      Yeah, right. You found a reliable way to spoof DNS and didn't consider it a big deal. Do you have any other wet dreams you would like to share?

    14. Re:Here we go... by harlows_monkeys · · Score: 1

      No, you did not stumble on this years ago. What you stumbled upon has long since been fixed. This attack gets around those fixes.

    15. Re:Here we go... by harlows_monkeys · · Score: 1

      Much more effective than 10 seconds?

    16. Re:Here we go... by afidel · · Score: 2, Informative

      Heck, MOST of the corporate firewalls don't do the right thing, so even if your clients and DNS server are patched you may STILL be vulnerable! Unless your firewall does transparent port passthrough (IE NAT but not PAT) you are vulnerable. For most firewalls this means you have to put a caching resolver in the DMZ and point internal servers and/or clients to it to be fully protected. Oh and don't forget things like anti-spam appliances, most are pointed directly out to the internet for DNS but not all are out in the DMZ.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    17. Re:Here we go... by Anpheus · · Score: 1

      Wow that is...

      *head-desk* Whoa, uhm. What was I going to post? *looks at winamp* Why was I playing Freebird?

    18. Re:Here we go... by afidel · · Score: 2, Informative

      Most large ISP systems are already patched as they were part of the insider group that got the patches before they were publicly announced. As of yesterday Comcast had some unpatched DNS servers and so did AT&T wireless, but those were the only ones I had seen reported as being unpatched.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    19. Re:Here we go... by spankymm · · Score: 4, Informative

      Yes - go read Amit Klein's papers on trusteer.

      Sending only a handful of more carefully calculated responses is also more likely to succeed if the victim is using mitigation techniques such as rate throttling.

      Even using source port randomization doesn't help as much as a lot of people think. You don't get one 32-bit PRNG, you get 2x 16-bit PRNGs. Each of these can be attacked separately. If you could narrow each of these down to 10 likely guesses, you only have to send 100 replies.

      --
      http://cafepress.com/spankymm - for the Masturbating Monkey in you!
    20. Re:Here we go... by ascendant · · Score: 1

      >a lot of people point to their routers for their DNS.
      ...and the router points to the ISP's DNS. I sincerely doubt it even caches. BFD if the ISP has fixed their server. Enough TLAs for you?

      --
      Do not attribute to malice that which can be easily explained by incompetence.
    21. Re:Here we go... by KGIII · · Score: 1

      Damn it. My faith in humanity had just been restored earlier today. See? Now I'm going to have to just give up surfing which means that I'll have absolutely no life at all and will probably have to string up causeing undue harm to my family. Fscking creeps. (I almost said "hackers" but that sure as hell isn't hacking.)

      --
      "So long and thanks for all the fish."
    22. Re:Here we go... by ILuvRamen · · Score: 2, Funny

      And also a solar storm can knock out the entire internet and power grid. And at any time we can be hit by a gamma ray burst or a black hole from the LHC can suck us all up. Yeah, internet security is never going to be 100%, DUH! Is it really even worth mentioning?

      --
      Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
    23. Re:Here we go... by Martin+Blank · · Score: 4, Informative

      Where I work, we run the servers through a proxy firewall with a DNS proxy service, and the DNS service on the firewall has been patched for this vulnerability. For traffic run through it, it doesn't preserve source port from the DNS servers, and from a quick glance, the source ports on requests seem to be randomized, so I think from that perspective, we may well be safer even for unpatched servers. However, our setup seems to be the exception, and we may have a couple of other networks (physically and logically separated from the primary) that do not have the benefits of this arrangement.

      --
      You can never go home again... but I guess you can shop there.
    24. Re:Here we go... by Anonymous Coward · · Score: 0

      How long until we see the major networks broadcasting the legit IP quads of sites we want to reach?

      ... or switching to djbdns:

      Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. [..] Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune

    25. Re:Here we go... by MadMidnightBomber · · Score: 4, Funny
      Can someone please send me the HOSTS file for the Internet?

      kthxbye

      --
      "It doesn't cost enough, and it makes too much sense."
    26. Re:Here we go... by Anonymous Coward · · Score: 0

      You may still not be safe. If someone can fire off a XSS attack through your browser, it could do enough lookups to make you vulnerable.

      Why would you need XSS?

      You just set up a site, say www.evil.com. Someone visits it, so you know their DNS server's IP address. You then give them a page with 10,000 images on, from aaaaa.google.com, aaaab.google.com, aaaac.google.com and so on. When their client tries to retrieve the successive images you send fake DNS responses to cache poison their DNS server with respect to www.google.com.

    27. Re:Here we go... by Bert64 · · Score: 1

      There has even been a publicly available tool for this, called ircnsid.c which has been available for years...
      It used to be on http://www.psychoid.lam3rz.de/ but that site is down, maybe web.archive.org has a copy of it or something.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    28. Re:Here we go... by Lincolnshire+Poacher · · Score: 2, Interesting

      You made me laugh, but as with all humour there is a grain of truth within.

      Curiously I spent some time yesterday attempting to estimate the number of zones currently known to DNS. Perhaps there is a better approach ( one that, say, inquires against DNS ) but by using Teh Googler to search for site:.${TLD} I came up with these order-of-magnitude results:

      • .com 7,980,000,000
      • .org 1,950,000,000
      • .net 2,140,000,000
      • .info 195,000,000

      These numbers just seem insane. Can anyone advise?

    29. Re:Here we go... by Bert64 · · Score: 1

      Look at efnet or ircnet, people spoofing dns has been fairly common for years.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    30. Re:Here we go... by Anonymous Coward · · Score: 0

      This cache poisoning attack works in seconds. Previous ones work in, what, hours or something. See the wired article.

    31. Re:Here we go... by spinkham · · Score: 4, Informative

      Different vulnerability, that tool checks for non-random TXID, not this exploit.
      This exploit changes the game in letting other exploits work well.
      It's not so much a new class of attack, as a way to give you infinite chances to use the old attacks. If you don't have a IPS checking for this, an attacker who can submit recursive queries to your resolver and wants to poising your DNS will eventually be successful. Publicly available tools work in one minute, Dan says coding in C on a fast connection he's able to do it in 10 seconds.
      Has DNS been broken this badly before? Yes, multiple times. However, the will and knowledge of how to use DNS cache poising for further evil is much higher now then it was in the past. Also, we are becoming increasingly dependent on the Internet, and attacks on the infrastructure do more then just keep us from our news sites.
      As Dan says, "Patch. Today. Now. Yes, stay late."

      --
      Blessed are the pessimists, for they have made backups.
    32. Re:Here we go... by spinkham · · Score: 2, Informative

      The best known unpatched attacks really had no upper bound. You got one chance to attack, then had to wait for the records to timeout before you could try again.(usually set from 1 hour to 1 week, depending on the service)
      What this vulnerability does is give you infinite chances to attack with no delay, so you can try 1000 times a second if your connection is fast enough. If you can do that, you will win, and quickly.
      The attacks themselves have not really changed, we can just use them much faster.

      --
      Blessed are the pessimists, for they have made backups.
    33. Re:Here we go... by hesaigo999ca · · Score: 1

      Is there no way of basically saying to your own dns server not to update or ask for each update it gets, then you can do a look up something like that, cancel or allow like vista...

    34. Re:Here we go... by LostCluster · · Score: 2, Informative

      That's a count of URLs, not domains within each TLD. For example, site:cnn.com accounts for 3,540,000 of your .com results.

    35. Re:Here we go... by Anonymous Coward · · Score: 0

      Has Dan Bernstein written anything recently, or has be been to busy smelling his own farts?

      Really, that dude is a major tool.

    36. Re:Here we go... by Just+Some+Guy · · Score: 1

      I just did (in Sound Forge)... cut it down to 1:08, its just noise...

      How does Sound Forge shrink it: by throwing away chunks or by generating a DCT and then resynthesizing the sound?

      --
      Dewey, what part of this looks like authorities should be involved?
    37. Re:Here we go... by Anonymous Coward · · Score: 0

      I know of two really big organizations that still have not patched their name servers as of yesterday. One of them is a large DSL provider the other is used by government agencies.

    38. Re:Here we go... by Deagol · · Score: 1

      Nice setup. Do you mind sharing what you use? I tried a quick search to find a true application firewall proxy app for DNS (old fashioned FWTK style), and didn't find much.

      --
      Method of processing duck feet
    39. Re:Here we go... by Leftist+Troll · · Score: 1

      Fscking creeps.

      Yeah, those filesystem-checking weirdos creep me out too. I mean, look at Reiser, we should have seen it coming.

    40. Re:Here we go... by Vectronic · · Score: 1

      I would assume DCT/et al, since it takes a fair bit of processing, and it has adjustments you can make to reduce/remove echo, and also filters for certain types of "music"... like voice, or high and low-end, drums, air instruments, etc, plus wet and dry gain, channels, etc. (in the "Time -Stretch plugin itself)

      Its limited to 50% of original though for shrinking (500% for expanding) so for "Free Bird" you have to run it at 50% 3 times, which is no doubt lessening the quality each time, however I doubt its enough to say "if it didnt" it would be an ok song at 1:08... you can also change it by BPM and etc.

      Like you probably already figured out... "i dont know" but what i do know is that its not just cropping out pieces.

    41. Re:Here we go... by Just+Some+Guy · · Score: 1

      Thanks for the info. I'm now off to make a Freebird ringtone that's under a minute long, even though I can't stand that song.

      --
      Dewey, what part of this looks like authorities should be involved?
    42. Re:Here we go... by spinkham · · Score: 1

      This is why hubris is one of the most important qualifications of a security researcher, and what makes us a PITA to deal with.
      Most people look at a protocol and say, "Gee, Paul Vixie and the rest of the DNS people are smart, and I'm sure they've thought of all the important stuff."
      Security researchers are the people who say, over and over again, "I bet they didn't think of this!"
      That's essentially the job description, thinking you're smarter then the rest of the world. Kind of makes us pricks, but it's a fun job. ;-)

      --
      Blessed are the pessimists, for they have made backups.
    43. Re:Here we go... by Martin+Blank · · Score: 1

      The DNS servers themselves are an eclectic mix of Linux, Solaris, and I think BSD, running a mix of BIND and djbdns. The firewalls are Secure Computing Sidewinders (now Secure Computing Secure Firewall), which are expensive but I think worth it. Secure Computing issued a patch for the DNS vulnerability last week, and some follow-up tests show that we're not vulnerable.

      To be clear, the Sidewinders just seem to handle the source ports. I don't believe that they alter the query ID at all, so patching the DNS servers themselves (or just running djbdns) is still important.

      --
      You can never go home again... but I guess you can shop there.
    44. Re:Here we go... by Anonymous Coward · · Score: 0

      There is always "I Want To Marry A Lighthouse Keeper" that was in the film classic A Clockwork Orange That song lasts one minute if I am not mistaken.

      Classic punk songs by the Ramones that I've heard are in the 2-3 minute range by comparison.

    45. Re:Here we go... by CTachyon · · Score: 1

      Actually, besides being a count of pages matched and not domains (like another reply mentioned), Google's result counts are just estimates and can sometimes be wrong by several orders of magnitude. The numbers get more accurate the deeper you go into the search results, i.e. the first page statement "Results 1-10 of about X" has the most inaccurate value of X that Google returns.

      Things like GoogleFight are somewhat useful, in a fun way, since a difference in result counts between two terms probably reflects an actual difference in popularity (albeit completely ignoring PageRank and other spam-unfriendly metrics). However, I cringe every time I see someone cite Google result counts in a serious article or (ugh) research paper, because that's missing the point entirely of what the word "about" is implying.

      --
      Range Voting: preference intensity matters
  2. Google by bdasd5 · · Score: 5, Funny

    And here I am, thinking I was on Google.

    1. Re:Google by hostyle · · Score: 1

      Lookout! The DNS rockstars are coming for YOU!

      --
      Caesar si viveret, ad remum dareris.
  3. The Book Of Internets, Chapter Three, Verse Twelve by Aussenseiter · · Score: 5, Funny

    And lo, all unpatched websites were rendered unto Goatse.

  4. DNS sploit result by hostyle · · Score: 2, Funny

    %> /usr/bin/treaceroute fruity.stuff

    traceroute to fruity.stuff (1.2.3.4), 30 hops max, 42 byte packets
    evil bit detected. re-routing ...

    --
    Caesar si viveret, ad remum dareris.
    1. Re:DNS sploit result by Varun+Soundararajan · · Score: 1

      %> /usr/bin/treaceroute fruity.stuff

      i think you got the command wrong: it is /usr/bin/traceroute fruity.stuff

      Unix is unforgiving if you make a typo.

  5. Re:The Book Of Internets, Chapter Three, Verse Twe by Anonymous Coward · · Score: 0

    Welp, thats it. Might as well give up. They've won.

  6. Re:The Book Of Internets, Chapter Three, Verse Twe by Bryansix · · Score: 4, Informative

    It doesn't work that way. DNS local servers are either run by a corporation or by your ISP. Either one could be hacked now. So it's not if the website is patched. It is if the DNS server your computer is using is patched.

  7. Re:The Book Of Internets, Chapter Three, Verse Twe by LostCluster · · Score: 4, Informative

    unpatched websites

    Have you been following this story. It's not sites that need the patch, it's DNS servers. Site owners are powerless if the ISPs fail to protect their domain name from the an entry leading to the spoof site's IP address.

  8. I know by Daimanta · · Score: 4, Funny

    I exploited this and let a huge cache of people visit my site(127.0.0.1) in stead of the site they wanted to go. It was kickass.

    --
    Knowledge is power. Knowledge shared is power lost.
    1. Re:I know by Anonymous Coward · · Score: 3, Funny

      HAHA, fool! now that I know your ip address, I shall soon hack you into oblivion!

    2. Re:I know by Anpheus · · Score: 4, Funny

      Don't worry, I just disabled his intern

      [CARRIER LOST]

    3. Re:I know by houghi · · Score: 1

      Could you please set it back? I can't get to my site http://hackme.houghi.org/

      --
      Don't fight for your country, if your country does not fight for you.
    4. Re:I know by g-san · · Score: 1

      No need to hack, I already logged in and made accounts for you all, just use your local username and password at that address. Login and trash it!

  9. And the "fix" isn't by Anonymous Coward · · Score: 0

    And do please forgive me if I'm under the impression that the supposed "fix" really isn't one.

    1. Re:And the "fix" isn't by cortana · · Score: 3, Interesting

      The fix is DNSSEC.

    2. Re:And the "fix" isn't by LostCluster · · Score: 1

      Ever think that the government would let us have an unhackable Internet-used protocol for anything? If it was all secure, how'd the NSA get in?

    3. Re:And the "fix" isn't by _Knots · · Score: 4, Interesting

      DNSSEC is a steaming pile, though after thirteen years, many RFCs -- each of which read "This Time For Sure!" -- it may in fact be workable.

      It is _a_ fix to this problem, but there are many simpler fixes that seemingly are being discarded for reasons I don't quite understand -- perhaps more full threat models are the target problem, but securing DNS doesn't make sense if we're then going to use HTTP to the addresses resolved! On the flip side, if we were using TLS everywhere, then dicking with DNS amounts to a DoS, which is much less powerful than the arbitrary redirection attacks we have now.

      One such simpler fix is using EDNS0 to add a nonce RR (goes out in the Query, comes back in the Additional section). And while EDNS0 is subject to rollback attacks, DNSSEC depends on EDNS0. So that's not an excuse not to use it.

      --
      Anarchy$ dd if=/dev/random of=~/.signature bs=120 count=1
    4. Re:And the "fix" isn't by Tiber727 · · Score: 1

      They used the key in the magnetic container under the bumper of Al Gore's car.

    5. Re:And the "fix" isn't by pfleming · · Score: 2, Funny

      Setec Astronomy

    6. Re:And the "fix" isn't by Anonymous Coward · · Score: 3, Informative

      "DNSSEC is a steaming pile"...

      Yes! Unfortunately this is completely and utterly true. Unlike many of the great crypto tools we have available to us (ssh, pgp, https), DNSSEC increases complexity by an order of magnitude.

      Watch as you lose the ability to effectively block full zone transfers from your domain name since DNSSEC requires NSEC records, which are essentially a linked list of all your zone entries!

      Be amazed when you find out that you need to run a cron job to sign all of your zone files every 15 days!

      Become aghast when you find out that you then need a second cron job, running on an alternate server, that runs a script that checks all your zone files for signature expirations.

      Become horrified when you find out that a properly validating DNSSEC caching server will block domains with expired signatures with NXDOMAIN, since there were only four choices in the existing DNS protocol and that response was the least bad.

      Smirk as you find out that virtually no one at all is using DNSSEC. Run `dig nsec $DOMAIN` against some well known DNS zones, and find that practically no one (except for the ISC) is using it.

      Since there are political problems with the key signing heirarchy, ISC is setting up an alternate place to put your higher level keys in their DLV registry. .com and .net are not going to be implementing DNSSEC.

      I have gone through and encrypted everything I could on my servers recently. I attended a presentation by ISC about how great DNSSEC is. I came away convinced that it was a lot of hot air, and that ISC was trying to sell the Internet a bill of goods. DNS isn't perfect, but DNSSEC is a half baked solution that virtually no one wants, and I frankly can't ever see it ever becoming popular in anything approaching its current form. Not ready for prime time... back to the drawing board guys!

    7. Re:And the "fix" isn't by spinkham · · Score: 1

      NSEC3 solves the enumeration problem, but everything else you have to say is valid.
      Of course, we have yet to see what the uptake will be in the US, because the TLDs are not signed yet.
      Until that happens (.org this year sometime, the rest undetermined) there's no good way to use DNSSEC.

      --
      Blessed are the pessimists, for they have made backups.
  10. DNS Glue poisoning was already known... by nweaver · · Score: 2, Informative

    The interesting thing, DNS glue (additional) poisoning WAS known, just not widely. EG, the SECOND hit for "dns glue poison" in Google gets http://lists.oarci.net/pipermail/dns-operations/2006-May/000537.html.

    Quoting Emin Gun Sirer:
    Incidentally, the client should be wary of trusting glue records unconditionally, as they are non-authoritative. A well-known cache poisoning attack works by tricking clients to believe glue records for all time and for all queries. Glue should be trusted for only the lookup in question for only the duration of that lookup. We'll assume that the clients treat glue properly (even though many do not).

    Thus it was already known, two years ago, that trusting Glue records is "well-known cache poisoning attack". Just apparently, not well known enough by the authors of Bind, Microsoft's DNS server, Cisco, etc.

    --
    Test your net with Netalyzr
    1. Re:DNS Glue poisoning was already known... by Anonymous Coward · · Score: 0

      I knew I shouldn't have sent all those trojans to the glue factory... Now we have to deal with them infecting our DNS servers...

    2. Re:DNS Glue poisoning was already known... by pecosdave · · Score: 1

      Trojans to a glue factory..... .....are you playing practical jokes on your hooker?

      --
      The preceding post was not a Slashvertisement.
    3. Re:DNS Glue poisoning was already known... by harlows_monkeys · · Score: 2, Funny

      That's not the attack. Try again.

    4. Re:DNS Glue poisoning was already known... by Anonymous Coward · · Score: 5, Insightful

      Congratulations, you confused the mods. Bailiwick checking was added to all DNS resolvers in response to glue poisoning and made cache poisoning through spoofed glue records very difficult. The current problem is that the typical filter rules are insufficient for stopping a glue poisoning attack which appears to come from the authoritative server: Kaminsky found a way around the glue poisoning countermeasure. This means that a very dangerous kind of attack which was thought to be defeated is now possible again.

    5. Re:DNS Glue poisoning was already known... by Martin+Blank · · Score: 1

      The problem is that glue records are often used to pass the addresses of nameservers required to resolve the domain in question. If that glue record can be passed back with a false address to the nameserver, the entire domain can now be controlled. If you can pull this off with a TLD, then the attack becomes much more serious. It appears at first glance that in addition to TTL restrictions (com has a TTL of two days), bailiwick limitations may limit these kinds of attacks (com, for example, is served off of [a-m].gtld-servers.net). Even if bailiwick limitations wouldn't stop this case, it would take probably tens of thousands of days -- and hence many years -- to pull this off, and that's if you got the response just perfect. If there's a way to have a DNS server ignore a TTL or drop it from the cache and necessitate a lookup, though, there could be some more promise in this route.

      --
      You can never go home again... but I guess you can shop there.
    6. Re:DNS Glue poisoning was already known... by Lost+Race · · Score: 0, Redundant

      Bind

      FYI, that's not a proper name, it's an acronym for "Berkeley Internet Name Daemon", and should properly be written as "BIND".

    7. Re:DNS Glue poisoning was already known... by szap · · Score: 2, Insightful

      No, but it's a "feature" that makes the attack possible. Turn it off, or make it stricter, and the attack falls apart.

    8. Re:DNS Glue poisoning was already known... by nweaver · · Score: 2, Insightful

      Read the quotation again...

      Emin Gun Sirer: "Glue should be trusted for only the lookup in question[Emphasis added] for only the duration of that lookup.

      This says "No Bailiwick checking at all": glue (additional) records should NEVER be cached. Period.

      --
      Test your net with Netalyzr
    9. Re:DNS Glue poisoning was already known... by blueg3 · · Score: 4, Informative

      It only works because the DNS server caches the result of the glue record, against the recommendation of the above writer.

      The glue record is necessary if, say, you need to provide the address of a nameserver when you provide the name of the authoritative nameserver for a query. You should use that glue record for that query only.

      What happens is that an attacker queries lbixds.google.com (or some other nonexistent domain) and then sends the server he issued that request to a response to that query that also has a glue record giving a false address for ns.google.com. If the DNS server only used that false address for resolving lbixds.google.com, cached lbixds.google.com, and left it at that, then lbixds.google.com would be the only entry the attacker could poison -- basically useless. However, the DNS server caches the glue record giving the address for ns.google.com, too.

    10. Re:DNS Glue poisoning was already known... by g0at · · Score: 1

      ... and then sends the server he issued that request to a response to that query that also has a glue record...

      I don't understand what you mean there; I'm presuming you meant to say "...and the server issues a response to that query that also has a glue record..." In any case, I don't understand why a properly-designed resolver would pay any heed to such a reply. If it's asking the google.com authority to resolve "lbixds", and it receives an answer, why would it also expect (and cache) an unsolicited answer for the domain "ns" (in your example)?

      -b

      --
      myselfmusic
    11. Re:DNS Glue poisoning was already known... by Martin+Blank · · Score: 2, Insightful

      Because that's how DNS generally treats requests that fall within the same domain (known as bailiwick protection). The question that you ask has been asked numerous times, and there's certainly good reason to review the logic behind Additional Resource Record handling, but tinkering with DNS is a very tricky thing. A proposed solution may fix the problem, but break other things on a much wider scale.

      --
      You can never go home again... but I guess you can shop there.
    12. Re:DNS Glue poisoning was already known... by blueg3 · · Score: 4, Informative

      So, first part. An attacker is trying to poison a DNS cache. Generally, he'd be interested in poisoning a DNS server that's a caching server for a group of people, like one run by a regional ISP. An efficient way of getting a poisoned record into its cache is to issue a request to that server, and then immediately send a forged response to the server. So, for example, I issue my local nameserver a request for abcd.google.com. It doesn't have this cached (you don't say!), so it starts trying to resolve it. I quickly send it a forge response for abcd.google.com, and it believes me. Transaction IDs make this a slim chance that it'll believe me, but it's still a chance, and I can issue a ton of requests to different fake addresses.

      The answer to the second part is tricky. Basically, say I want to resolve mail.google.com. I have nothing about google.com in my cache. So I contact the nameserver for .com. It isn't authoritative for the google.com domain, but it knows who is, and it tells me so. (Say that it's ns.google.com.) Knowing ns.google.com is the nameserver for that domain is useless without its IP address, so it tacks on a glue record that gives me the address of ns.google.com. Now I can contact ns.google.com to ask it the IP of mail.google.com.

      Originally, these records were just accepted. This is a huge security hole: I could request bob.domainiown.com, send a legitimate response (I control domainiown.com), and tack on a record telling them where ns.google.com is, even though I'm not authoritative for that. Now, such a record can only be attached to a request that is in the same domain, so I need to ask for bob.google.com to attach an ns.google.com record, which requires me to forge a response.

      There are a number of situations where these auxiliary records are necessary, so they can't just be ignored. However, they shouldn't be cached -- they should be used only for the one request that generates them.

    13. Re:DNS Glue poisoning was already known... by Anonymous Coward · · Score: 0

      Okay faglazer this is NOT what the attack is. Read the Internet, then go home and punch yourself in the face (you are not allowed to enjoy it.)

    14. Re:DNS Glue poisoning was already known... by CyprusBlue113 · · Score: 1

      No it doesn't, it's already as strict as it can be and still exist and it is still vulnerable coupled with another attack. Go read the brief again.

      --
      a handful of selfish greedy people are no match for millions of selfish, greedy people -u4ya
    15. Re:DNS Glue poisoning was already known... by szap · · Score: 3, Informative

      Maybe it wasn't clear, but I was going to echo nweaver's reply:

      glue (additional) records should NEVER be cached. Period.

      djbdns's total lack of support for glue records (IIRC) is one of the reasons it's one of the few old dns software not vulnerable. And that's the point I was trying to drive: the glue records feature made the cache poisoning possible -- I just read the exploit code, and it uses Additional Section to inject the malicious entry. Without this feature, like in djbdns, the exploit wouldn't work.

      Yeah, I should have said "don't cache glue records", not "make it stricter" mea culpa.

    16. Re:DNS Glue poisoning was already known... by g0at · · Score: 1

      Ahh, I get what you mean now about sending a reply TO the server that was just QUERIED. I mis-read this as some kind of convoluted typo, but I follow the logic now. Interesting.

      Thanks for taking the time to expand.

      -b

      --
      myselfmusic
  11. Re:The Book Of Internets, Chapter Three, Verse Twe by Aussenseiter · · Score: 1

    Slip of the digital tongue while attempting to make a quick funny. Please don't hurt me!

  12. Re:The Book Of Internets, Chapter Three, Verse Twe by Anonymous Coward · · Score: 1, Insightful
    My understanding is that it's DNS resolvers, not servers, which need to be patched.

    Now if your windoze box doesn't do its own resolution, it forwards all requests to a caching resolver (e.g. at your ISP) then your ISP's resolver needs to be patched. Or if they run DJB's dnscache, it's not vulnerable because DJB recognised the problem years ago.

  13. Meh - no big deal. by pecosdave · · Score: 1

    If you use Verizons DNS you wont be able to tell the difference anyways. Seriously, I don't know if Verizon is paid to redirect DNS request or they just have really crappy security/maintinance on them.

    --
    The preceding post was not a Slashvertisement.
  14. I can't contact ftp.debian.org this last 2 days by Anonymous Coward · · Score: 0

    is it related?

    1. Re:I can't contact ftp.debian.org this last 2 days by Vectronic · · Score: 3, Informative

      try http://ftp.debian.org/

      for a bit more info:
      http://wiki.debian.org/ftp.debian.org

    2. Re:I can't contact ftp.debian.org this last 2 days by Trogre · · Score: 1

      * To: debian-mirrors-announce@lists.debian.org, debian-infrastructure-announce@lists.debian.org, debian-devel-announce@lists.debian.org, debian-user@lists.debian.org
          * Subject: ftp.debian.org update
          * From: Josip Rodin <mirrors@debian.org>
          * Date: Mon, 03 Dec 2007 20:52:00 +0100
          * Message-id: <E1IzHKi-0007AN-MH@keid.carnet.hr>
          * Mail-followup-to: debian-devel@lists.debian.org
       
      Hi,
       
      We're going to be changing ftp.debian.org setup a bit... but first,
      a friendly reminder.
       
      Many people seem to think that ftp.debian.org is the canonical location of
      Debian packages and that it will be best for them to use that site for apt
      or for mirroring. This is *not true*.
       
      ftp.debian.org is merely one of several servers that get updated from an
      internal Debian server. That address is presently located on a single server
      in the United States, and it still exists mainly for backwards
      compatibility.
       
      In the future, it may get services reduced, or shut down, or converted into
      a globally load-balanced name, or whatever. Please don't use it.
       
      If you're using it now, please switch to a country-based DNS name
      such as ftp.us.debian.org, ftp.ca.debian.org, ftp.uk.debian.org, ...
      The list of those servers is at http://www.debian.org/mirror/list
      ...
       
      --
      Josip Rodin
      mirrors@debian.org

      --
      "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
  15. Re:CONFIRMED: Steve Jobs has AIDS !! by DurendalMac · · Score: 3, Funny

    For fuck's sake, whoever is DDoSing 4chan needs to stop already! The tards have spread out and are trolling the whole internet. At least the 4chan cesspool kept them all mostly in one place. Now they're left with nowhere to go and are taking their idiocy all over the internet!

  16. Y2K 2.0? by oneal13rru · · Score: 1

    Oh noes, the world is going to crash down around us! Just saying, why overreact? If it isn't one thing, it's going to be something else, and as usual, I'm fairly sure the best solution is to grin and bear it, or to round up a digital posse and fix the little tards.

    --
    Never disregard the raw power inherent to stupidity... they call it "dumb luck" for a reason...
  17. See if you're vulnerable by neokushan · · Score: 4, Informative

    There's a tool on the site below that apparently checks if the DNS you're currently using is vulnerable to such an attack. I checked my work DNS and my home DNS - both were fine. Apparently OpenDNS is secure as well, so there's probably nothing to worry about.

    http://www.doxpara.com/

    --
    +1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
    1. Re:See if you're vulnerable by maXXwell · · Score: 5, Informative

      The DNS OARC (http://dns-oarc.net) has an improved version:

      http://entropy.dns-oarc.net/test/

    2. Re:See if you're vulnerable by AnyoneEB · · Score: 2, Informative

      He also links to a way to check from the command line: porttest.dns-oarc.net -- Check your resolver's source port behavior. That method also allows you to test DNS servers other than the one you are using, so it provides a simply way to tell if your ISP has fixed their servers yet without changing your own config. The sidebar on doxpara just shows a 404 for me.

      --
      Centralization breaks the internet.
    3. Re:See if you're vulnerable by hal9000(jr) · · Score: 1

      Bugger. My Verizon DNS servers have great TXID randomness and poor source port randomness.

    4. Re:See if you're vulnerable by gQuigs · · Score: 3, Informative

      So.. What's their IP?

      It looks like 66.240.226.139 to me...

    5. Re:See if you're vulnerable by Rigrig · · Score: 1

      Seems my ISP's DNS violates RFC 1149.5: It always uses port 5353 instead of port 4.

      --
      **TODO** [X] Steal someone elses sig.
    6. Re:See if you're vulnerable by afidel · · Score: 2, Interesting

      Yeah, they're probably behind a firewall with PAT since Verizon was one of the ISP's involved in the private patch effort AFAIK. The problem is the DNS client/server patches are broken most firewalls and this was not known till people started testing after the patches were publicly released. You can use OpenDNS or L3's resolvers as I know those are patched and NOT behind a PAT firewall and are publicly available.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    7. Re:See if you're vulnerable by QuoteMstr · · Score: 1

      Kinda sucks for those of us who have split-horizon DNS though.

    8. Re:See if you're vulnerable by afidel · · Score: 1

      This is also great for testing things which don't have a browser like networking gear and spam filters.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    9. Re:See if you're vulnerable by LeandroTLZ · · Score: 1

      My home ISP was vulnerable (201.251.7.2) and so was a friend's. I just changed my DNS entries to OpenDNS and told my friend to do the same; took about two minutes. If you find you're vulnerable and don't want to risk being hit by this exploit, just change your DNS servers to the ones listed at http://www.opendns.org/ until this is patched (208.67.222.222 and 208.67.220.220)

      --
      Futurama Madhouse
    10. Re:See if you're vulnerable by geminidomino · · Score: 2, Insightful

      Doesn't OpenDNS fail to properly return NXDOMAIN results, or is that another service (I've not slept in >24 hours, so I could be mistaken.)

    11. Re:See if you're vulnerable by Anonymous Coward · · Score: 0

      Comcast has POOR and GREAT results, respectively. Any idea how 'bad' that is?

    12. Re:See if you're vulnerable by Anonymous Coward · · Score: 0

      bad. it probably hasnt been patched yet.

    13. Re:See if you're vulnerable by Anonymous Coward · · Score: 0

      Yes, it gives you an OpenDNS web page for failed lookups. ORSN does not, but they seem to be flaky at the moment.

  18. Guess now there's no need by al0ha · · Score: 1, Funny

    to watch the Black Hat DNS vulnerability webcast tomorrow. My only question is, what took so long?

    --
    Did you ever wake up in the morning, with a Zombie Woof behind your eyes? -- FZ
  19. Oh my. by Anonymous Coward · · Score: 0

    Prepare to enter teh suck.

  20. Re:The Book Of Internets, Chapter Three, Verse Twe by rs79 · · Score: 3, Insightful

    Um... even if you run your own caching server, if your ISP runs a "transparent" web proxy it will do its own dns. You may in fact run DJB which is immune from this bug, but if your ISP runs an unpatched dns server you'll still be scrod despite running your own caching server.

    Slick huh?

    They need to take the dns lookup out of the web proxies.

    --
    Need Mercedes parts ?
  21. More edifying than TFA's script by laburu · · Score: 3, Informative

    Cédric Blancher's annotated command-line exploration of the “in-bailiwick” DNS vulnerability

    1. Re:More edifying than TFA's script by PRMan · · Score: 1, Funny

      This link is in French. I'd rather read scripts. At least they're in Geek.

      --
      Peter predicted that you would "deliberately forget" creation 2000 years ago...
    2. Re:More edifying than TFA's script by Anonymous Coward · · Score: 0

      Code snippet added, so you can get something out of it, if you did not find latest MSF exploit yet...

  22. Use djbdns! by Neanderthal+Ninny · · Score: 2, Interesting

    Even though it is not as popular as BIND but djbdns doesn't have this vulnerability. Remember Dan J Bernstein had the original idea in 2002 about this issue and Dan Kaminsky and Paul Vixie looked into this and found these vulnerabilities.

    1. Re:Use djbdns! by Anonymous Coward · · Score: 1, Insightful

      Please understand that there is a downside to massively randomizing your source ports -- you use a lot more of them! File descriptor consumption->exhaustion is an issue that a lot of folks are running into with the patched versions of BIND. People running djbdns no doubt ran into similar problems years ago and had to deal with them too.

      So, before you jump all over ISC about dropping the ball, understand that a capacity/security tradeoff was made based on an assumption that it was difficult to exploit this knownweakness. Kaminsky discovered a not-so-difficult way to exploit it, and that's why the landscape changed.

      If DNSSEC were implemented, this would all be a non-issue. After the immediate crisis subsides, expect a lot of recriminations and finger-pointing with respect to why DNSSEC is still undeployed after all this time.

    2. Re:Use djbdns! by afidel · · Score: 1

      DNSSEC is still undeployed because it's had three mutually exclusive RFC's and to be really useful requires most of the internet to upgrade. It's similar to why IPv6 hasn't taken off. In both cases I expect that it will take a crisis to really force the switch. In the case of IPv6 it will be IP exhaustion and in the case of DNSSEC it will be when connections are fast enough that a brute force attack works in 10 seconds even with randomized ports, or once another critical flaw is found which can't be worked around.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    3. Re:Use djbdns! by PlusFiveTroll · · Score: 2, Interesting

      6 root root 4096 2002-10-11 11:10 dnscache

      That list my oldest still running djb dnscache install, yes the kernel and glibc have been upgraded around it. The mail server it's on has handled 750k messages per day. Does rdns lookup on smtp connections from servers, from our tests almost every valid smtp mail source has a reverse dns name of some sort. Spambots virus are the largest amount of mail from unnamed IPs.

      This being said, if your running out of file descriptors you probably have one of the following issue.
      -Linux kernel 2.4, Solaris or AIX. (recent bind beta fixes most of this)
      -Messed up ulimit settings.
      -Poorly engineered dns caching network.

      Trying to run all your clients on a few 'big/fast' caching servers in general is a poor design that uses more bandwidth (to contact the centrally located dns server) and puts the entire userbase at risk if one of the caches does become poisoned. The cable company I worked with realized this years ago and distributed the dns load to each market with at least two dns servers in each city, then more per 'area' as the customer base grew. The boxes were diskless with an extremely stripped linux/glibc installs with dnscache, SSH, and SNMP support. No hard disks let these servers run more like an appliance, they were easily switched out, and rarely suffered failures. Just put the new numbers for the node in the dhcp server and over the period of a day or so as the dhcp clients renewed the load balanced out.

      As per D.J.s security suggestions, only ip addresses that belonged to their networks could resolve off the cache. This is significant as many large ISP currently allow anyone to resolve DNS off their networks. Which in the current security context no trickery or fishing is necessary to poison an ISPs cache. A hacker anywhere in the world could poison the cache at their leisure.

      They used Bind on there authoritative nameservers, since it fit in with their toolchain, but they turned off the forwarding mode so queries outside of the servers scope would not be resolved.

      It's been awhile since I worked there, but I'm sure someone from the network security department after reading the news, called a meeting on how they were going to deal with this issue. I'm sure he may have been surprised when the answer was 'We fixed that 5 years ago'. It's funny, a lot of people wrote off D. J. Bernstein, not because of what he said, but how he said it. Time has now shown he was right, and even Paul Vixie admitted that he was wrong.

    4. Re:Use djbdns! by Anonymous Coward · · Score: 0

      It's funny, a lot of people wrote off D. J. Bernstein, not because of what he said, but how he said it. Time has now shown he was right, and even Paul Vixie admitted that he was wrong.

      Well, it wouldn't be the first time that an academic's little pet project turned out to be more clever about some certain thing than a much more widely-deployed and popular package that has a userbase a magnitude larger, and plenty of "legacy" requirements to fulfill. Let DJB enjoy his time in the sun, at least until the permanent fix to this problem (DNSSEC) is implemented. Apparently DJB doesn't believe and doesn't implement DNSSEC -- it's not "clever" enough for him -- so djbdns will likely be left in the dust.

    5. Re:Use djbdns! by BitHive · · Score: 1

      You're just the poster child for anonymous cowards aren't you?

    6. Re:Use djbdns! by PlusFiveTroll · · Score: 2, Insightful

      Cryptography is not magic.

      While I don't expect the AC to read this, it lays out why we are not going to see DNSSEC for some time. http://www.internetnews.com/security/article.php/3758566/Is+DNSSEC+the+Answer+to+Internet+Security.htm

      http://en.wikipedia.org/wiki/DNSSEC is also suprisingly good with a lot of easy to read information, and includes why the current DNSSEC specs may open up more security risks.

      example1 >Note that someone could deliberately or inadvertently cause a degradation of service by sending large number of queries for uncached RRs, for example, traversing the NSEC RR chain for a large TLD.

      example2>DNSSEC forces the exposure of information that by normal DNS best practice is kept private. NSEC3 drafted in march 2008 may correct this.

      Also, most people don't realize that DNSSEC is not an end-to-end security mechanism. It only protects DNS data between an authoritative name server and a caching name server. Currently no operating system resolver libraries that I know of verify that the caching server is providing legitimate results to DNSSEC protected domains. Until your OS or applications provide DNSSEC support, running your own DNSSEC enabled cache is the only way to currently protect your dnssec queries from being forged.

    7. Re:Use djbdns! by Cato · · Score: 1

      How exactly did you upgrade the kernel without restarting the box, or glibc without restarting dnscache?

    8. Re:Use djbdns! by PlusFiveTroll · · Score: 1

      I never said I didn't reboot, this was the install date. I've used DJBDNS before that, but all of those servers have been replaced.

    9. Re:Use djbdns! by Anonymous Coward · · Score: 0

      Restricting zone enumeration is not a "DNS" best practice, it's a "best practice" that a bunch of security folks who are totally ignorant of DNS, pulled out of their behinds and foisted on their respective DNS administrators.

      Most experienced DNS admins don't care about zone enumeration. If the information wasn't public, we wouldn't put it in a publically-accessible zone in the first place.

  23. Re:The Book Of Internets, Chapter Three, Verse Twe by blincoln · · Score: 3, Insightful

    They need to take the dns lookup out of the web proxies.

    The problem with doing that would be that it would then be impossible (at least using current DNS software, as far as I know) to allow clients on an internal network to have limited internet access without allowing them to perform DNS tunneling (and thereby upgrade their internet access to "full").

    Once someone (anyone?) releases a DNS package that allows firewall-style rules (e.g. "client on this range of IPs may only resolve subdomains of the following domains...", "clients may only look up X distinct subdomains each of Y domains every Z hours" then the picture would probably change.

    --
    "...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
  24. BIND is not a demon by DragonHawk · · Score: 2, Informative

    it's an acronym for "Berkeley Internet Name Daemon"

    Actually, BIND stands for "Berkeley Internet Name Domain". Berkeley did the seminal work for the original DNS implementation, and that's what they called their idea. BIND is a suite which includes a stub resolver, some utilities, and named (name daemon). (Along with some other stuff, now.)

    If you want to get fancy, "ISC BIND named" is the proper name of the software we're talking about. ISC is the company, BIND is the product, named is the program.

    See: http://www.isc.org/sw/bind/index.php

    --

    dragonhawk@iname.microsoft.com
    I do not like Microsoft. Remove them from my email address.
  25. Re:CONFIRMED: Steve Jobs has AIDS !! by Anonymous Coward · · Score: 0

    I assume you've never heard of Woz either

  26. BIND 9 named views for access control by DragonHawk · · Score: 3, Interesting

    Once someone (anyone?) releases a DNS package that allows firewall-style rules (e.g. "client on this range of IPs may only resolve subdomains of the following domains..."

    I think you might be able to do that with the "views" feature of ISC BIND v9 named, although I've never tried. I know you can define ACLs for clients and control how they see the DNS using the ACL. You should be able to define forwarding zones for the domains you want to work, and blackhole everything else. I think.

    http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#view_statement_grammar

    --

    dragonhawk@iname.microsoft.com
    I do not like Microsoft. Remove them from my email address.
  27. DJBDNS by vrrrtk · · Score: 1

    Given that's a vulnerability in the DNS protocol I really wonder if the dnscache (djbdns) is affected by this one. Because it's said that djb's dns suite is immune to any type of cache poisoning attack. I better test it.

    1. Re:DJBDNS by afidel · · Score: 1

      It's not unless it's behind a PAT firewall, you'll need to put it in the DMZ for most firewalls. IPTables is Masquerade mode and PF can both be made to behave in a manner that doesn't remove the randomization of ports that DJBDNS and patch BIND and MS servers perform.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    2. Re:DJBDNS by makomk · · Score: 1

      Supposedly, it may not be even if it is behind PAT; it's apparently less trusting about Additional RRs than other DNS servers. Might be worth testing.

  28. Unclear on the concept by DragonHawk · · Score: 2, Insightful

    Oh noes, the world is going to crash down around us! Just saying, why overreact?

    A problem you ignore will have full impact. A problem you prepare for and take counter-measures against is prevented from having a serious impact. That's the whole point.

    We spent great effort fixing Y2K bus, thus prevented the bugs from causing serious damage. Therefore, you conclude, we should not have fixed the Y2K bugs.

    I guess, since seat belts have saved lives, we should not wear them.

    Get it now? :-)

    --

    dragonhawk@iname.microsoft.com
    I do not like Microsoft. Remove them from my email address.
    1. Re:Unclear on the concept by oneal13rru · · Score: 1

      It was more of a general concept, things that seem apocalyptic tend to end up being fairly anticlimactic after tons of buildup, with or without extensive preparation. I just don't personally plan to freak out about something that really isn't a new issue. I cant even ARP a network I have full admin access to easily, because it's such an old problem, there are fixes out there. All I'm saying is the freakout level is nowhere near what the article implies.

      --
      Never disregard the raw power inherent to stupidity... they call it "dumb luck" for a reason...
    2. Re:Unclear on the concept by bigstrat2003 · · Score: 1

      We spent great effort fixing Y2K bus, thus prevented the bugs from causing serious damage. Therefore, you conclude, we should not have fixed the Y2K bugs.

      You misunderstand his logic. The logic was: we spent great effort fixing Y2K bugs, which would not have caused serious damage (even if we had not fixed them). Therefore, we should not have fixed the Y2K bugs.

      I happen to agree with him, for the most part. Y2K, by the time it was all said and done, was a huge marketing scam. I mean, I even had a stereo system that said "Y2K compliant!" on the box. WTF? There may have been some legitimate concern at first, but it wasn't long before people blew the whole thing way out of proportion, and turned it into a big "crisis".

      --
      "16MB (fuck off, MiB fascists)" - The Mighty Buzzard
  29. Only 1 thing comes to mind by Anonymous Coward · · Score: 0

    ... what a fucking douche bag

  30. DNSSEC today by DragonHawk · · Score: 1

    The fix is DNSSEC.

    DNSSEC won't solve the present problem. Almost nobody has deployed it. In particular, the root zone does not use it, and I haven't seen mention of any GTLD or ccTLD zone doing so, either. Certainly not the big three (.COM, .NET, .ORG).

    I am not saying cryptographically securing DNS is not a good idea. It is, and indeed, is the only viable long-term fix. I'm just saying that DNSSEC is not magic dust.

    --

    dragonhawk@iname.microsoft.com
    I do not like Microsoft. Remove them from my email address.
    1. Re:DNSSEC today by Anpheus · · Score: 1

      Hey-oh! .ORG is switching to DNSSEC.

      Also, several country level TLDs use it.

    2. Re:DNSSEC today by Phroggy · · Score: 1

      I don't believe the people saying DNSSEC is the answer are suggesting that if you deploy DNSSEC on your nameserver today you'll be safe. They're saying if everyone deploys DNSSEC on everybody's nameservers including the root zone, then we'll all be safe. DNSSEC is not a short-term solution, but if the spec is stable enough now and the various kinks have been worked out, then now is a good time to start testing it on root servers, gTLD servers, and ccTLD servers. Once that's done, then ISPs should start using it, and it will actually do some good.

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    3. Re:DNSSEC today by slash.duncan · · Score: 2, Interesting

      What you've apparently missed (as you mentioned .org but not this) is that the .org folks (PIR) just got ICANN board approval to deploy DNSSEC at their gTLD level. This occurred at the 32nd Annual ICANN meeting in Paris (in June, I believe). Apparently PIR has been pushing DNSSEC for some time and is pretty much ready to go, altho it'll still take some time to actually get up and running.

      Here's one informative link I found on Google. Google for dnssec .org icann for more:

      http://blog.nominet.org.uk/insight/2008/06/icann-paris-dnssec/

      --
      Duncan
      "Every nonfree program has a lord, a master,
      and if you use the program, he is your master."
      R Stallman
  31. Help Please by bobetov · · Score: 1

    Hey all, I see lots of comments re: OpenDNS as a good solution if your ISP sucks (as mine does) and has not patched.

    But I can't trust my DNS to resolve correctly to OpenDNS.com or whatever.

    Anyone got dotted quads for me?

    --
    Looking for a Rails developer in Chapel Hill?
    1. Re:Help Please by daemonburrito · · Score: 1

      208.67.222.222 208.67.220.220

    2. Re:Help Please by Anonymous Coward · · Score: 0

      I trust my ISP more than I trust "daemonburrito", personally, but to each his own.

    3. Re:Help Please by daemonburrito · · Score: 1

      Why confuse the poor guy? (bobetov: those are the ip addresses for opendns).

      "AC": Troll me directly, please.

    4. Re:Help Please by Raineer · · Score: 1

      208.67.222.222 208.67.220.220

      Seconded, don't trust your ISP... for home use the 2 above work just fine. In addition, some of the adult-filtering for curious kids in the house is a WONDERFUL optional side benefit.

    5. Re:Help Please by totally+bogus+dude · · Score: 2, Funny

      Unfortunately it.slashdot.org has already been poisoned; you actually posted that request to an elaborate mock-up of the real slashdot, and the replies are coming from l33t hackers who are supplying you with false DNS servers which currently appear to work correctly.

      You'd best disconnect from the internet and burn your computer. It's the only way to be sure.

  32. In Soviet Russia by Archangel+Michael · · Score: 1

    DNS Cache poisons you.

    Sorry, I had to.

    --
    Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
  33. Use OpenDNS if your ISP is vulnerable by duplicate-nickname · · Score: 5, Informative

    I used one of the tests below and found that my ISP's DNS servers were vulnerable. Now I am using the OpenDNS servers on all of my clients instead:

    208.67.222.222
    208.67.220.220

    Their servers are not vulnerable, and you can create an account to enable things like antiphishing at the DNS level (much better idea then a browser plug-in).

    If you find that your ISP's routers are vulnerable, your best bet is switch to OpenDNS...or just run your own caching server.

    --

    ÕÕ

  34. Microsoft's hamfisted "patch" by bizitch · · Score: 4, Informative

    In case anyone is dumb enough to use a Microsoft DNS server as a authoritative internet DNS server -

    MS has released two lovely patches -

    KB951746 and KB951748

    The problem with this fix is that it turns the DNS.EXE daemon into a UDP socket grubbing whore.

    After the patch, the DNS.EXE daemon grabs no less than 2500 freaking UDP sockets.

    This wreaks havoc on anything that - you know - needs UDP sockets on the same server.

    So far Zonealarm, Blackberry BES and Sphericall VOIP software all break with this "patch"

    Stay tuned for more fun to come ...

    --
    ---- "Logoff! That cookie shit makes me nervous!" - A. Soprano
    1. Re:Microsoft's hamfisted "patch" by duplicate-nickname · · Score: 1

      It sounds more like Zonealarm, BES and Sphericall are broken. Why would they try to listen on a UDP port that is use? There are only 65,000+ ports available, why are they running into conflicts when only 2500 are in use? If the port is not in use, why are they not validating the data they are receiving through UDP?

      Not to mention that similar conflicts are starting to show up on patched BIND servers that are running other services which rely on UDP.

      --

      ÕÕ

    2. Re:Microsoft's hamfisted "patch" by Anonymous Coward · · Score: 0

      Authoritative DNS servers aren't relevant to this exploit; the exploit consists of forging responses to resolvers and thereby poisoning their caches.

      Perhaps you meant something other than "authoritative internet [small "i", sic] DNS server". [Insert appropriate Princess Bride quote here]

    3. Re:Microsoft's hamfisted "patch" by networkzombie · · Score: 1

      Zone Alarm already has a patch out because KB951748 brought its existing problems to the surface. Try contacting your other software vendors as they most likely have a fix for their software too. Of course, blaming Microsoft is good too if you want to stick with that.

    4. Re:Microsoft's hamfisted "patch" by Phroggy · · Score: 2, Informative

      ZoneAlarm breaks in the sense that it thinks Microsoft's new DNS resolver is behaving like malware and should therefore not be trusted. ZoneAlarm has a ridiculous little slider with three security levels marked "High", "Medium" and "Low"; if you set it to "High" (as recommended), you can't resolve DNS.

      ZoneAlarm has released a patch to work around the problem. You can set your security setting to "Medium" while you download the update.

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    5. Re:Microsoft's hamfisted "patch" by totally+bogus+dude · · Score: 1

      While we're bitching about Microsoft, what the fuck is up with the description for these patches?

      A security issue has been identified that could allow a remote attacker to misrepresent a system action or behavior unbeknownst to users on Microsoft Windows systems.

      They could at least mention something about DNS so you know what the patch is actually for without having to read the info on their site.

    6. Re:Microsoft's hamfisted "patch" by Kent+Recal · · Score: 1

      ZoneAlarm breaks in the sense that it thinks Microsoft's new DNS resolver is behaving like malware and should therefore not be trusted.

      You mean ZoneAlarm must be broken when, for the first time, it makes a reasonable assessment?

    7. Re:Microsoft's hamfisted "patch" by Anonymous Coward · · Score: 0

      What the fuck are you doing running anything on your DNS server except, er, DNS? "Hamfisted"? You deserve everythign t

  35. help all the SOHO router people by paulbd · · Score: 2, Interesting

    so, there are a lot of us in the following position, no doubt: we run a router (linksys, whatever) that gets DNS from our ISP. lets assume that the ISP is patched. our local machines use the router for DNS. do we need to patch the router? are its DNS request services even accessible to the external network? can it be compromised in the same way that the ISP DNS could be? i have been wondering this ever since news of this problem broke, and i have still not seen a clear answer.

    1. Re:help all the SOHO router people by duplicate-nickname · · Score: 1

      From my understanding, if you are using a DNS proxy on your router (which most SOHO routers seem to do now), then you might be vulnerable. I checked my 2wire (which has no option to turn off DNS proxy for DHCP clients) and they have not updated the firmware in forever. :/

      See my post below about switching to OpenDNS instead.

      --

      ÕÕ

    2. Re:help all the SOHO router people by profplump · · Score: 2, Informative

      Generally the proxy on a SOHO router runs as a forward-only cache (or even just a simple proxy) to your ISP's DNS. As such it's really your ISP's DNS that is or isn't vulnerable, because you aren't ever going to see records from anyone else, nor will anyone else know you're asking for them.

      The test listed above -- http://entropy.dns-oarc.net/test/ -- will let you know what the rest of the world sees as your DNS source address, and whether or not that source is sufficiently randomized.

    3. Re:help all the SOHO router people by blueg3 · · Score: 3, Informative

      Most of these routers don't run caching, recursive resolvers -- they just forward the request to your ISP's DNS server. As such, they are immune.

    4. Re:help all the SOHO router people by Cato · · Score: 2, Informative

      Mod parent up! Home broadband/WiFi routers may well be vulnerable unless you've specifically checked.

      Unless you've checked the internals of your home router and whether it's using the wrong sort of DNS proxy/cache, I recommend *everyone* with a home router switches their client computers to using OpenDNS, so it's Windows/Mac/Linux directly requesting DNS services from OpenDNS. (If you have DHCP for your clients at least you only need to change the router, but any laptops should also explicitly use OpenDNS in case a WiFi hotspot has unpatched DNS.

      Then you can take your time about updating the router firmware. I happen to run DD-WRT and this doesn't yet have a patched version of dnsmasq - for some reason the author of dnsmasq wasn't included in the insider group that patched non-embedded OSes, Cisco/Juniper routers, DNS servers, etc.

    5. Re:help all the SOHO router people by RevEng · · Score: 1

      Actually, many home routers do contain caching, recursive resolvers. The easiest way to tell is to look for a "DNS caching" option. Most routers I've seen have this disabled by default, but I haven't seen enough of them to make any kind of generalization from that.

      Anything that does recursive DNS lookups and caches the results is susceptible to this attack. The patches help, but they don't solve the problem, they just make the attack more difficult.

  36. Re:The Book Of Internets, Chapter Three, Verse Twe by QuoteMstr · · Score: 2, Insightful

    Yes, DJB "recognized" the problem by lobotomizing DNS, and he refuses to consider what will solve the problem once and for all, DNSSEC. Right...

  37. Re:The Book Of Internets, Chapter Three, Verse Twe by rs79 · · Score: 2, Interesting

    If you want to support verisign forever, go with dnssec.

    --
    Need Mercedes parts ?
  38. Re:The Book Of Internets, Chapter Three, Verse Twe by rs79 · · Score: 1

    "The problem with doing that would be that it would then be impossible (at least using current DNS software, as far as I know) to allow clients on an internal network to have limited internet access without allowing them to perform DNS tunneling "

    You've lost me toally. I'm not talking about expolicit web proxies, but the "transparent" ones that ISPs use.

    I can connect with ssh and ftp to free.tibet, but not via port 80 ("web") service. It's all in the wrist action of (the screw you I'm doing my own dns lookup of) the "transparent" web proxy the upstream has.

    This has nothing to do with "dns tunnelling" whatever that is on internal networks or what have you. I dunno about where you are but around here every provider of dialup, broadband, wireless and sat uses these dumb "transparent" web proxies. They're also a vixieism, iroically.

    --
    Need Mercedes parts ?
  39. NAT routers by smash · · Score: 3, Informative
    Be aware that if you patch your DNS server, and it sits behind a NAT that forwards requests, its possible that you are still vulnerable. Would suggest using one of the available tools, (eg on www.doxpara.com) to check your DNS, and if required/possible update your NAT firewall as well.

    Simply patching your DNS server may not be enough.

    --
    I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    1. Re:NAT routers by Cruicky · · Score: 1

      This is a very good point. I run my own DNS server here, and the NAT that it sits behind remaps the ports from the random ports that BIND uses, to sequential ports on the other side of the NAT, which gives a straight line graph on the already recommended DNS OARC test. http://entropy.dns-oarc.net/test/

  40. Re:The Book Of Internets, Chapter Three, Verse Twe by QuoteMstr · · Score: 1

    It works tolerably well for X.509. What's your proposed alternative?

    You're like those environmentalists who say "no" to nuclear, coal, wind (birds), dams (fish), solar (semiconductor manufacturing), and everything else, but who say "yes" to nothing.

  41. I think this is exactly what is needed ... by arcade · · Score: 1

    Sorry, but I'm pretty certain that this is needed. It needs to use random UDP ports for each reply. If it's just 2500 ports, that's bad. It should use around 64K ports.

    One chosen at random, for each reply it is sending.

    Or is it something I do not understand in the problem you're describing? Or is it you to that do not understand the problem?

    --
    "Rune Kristian Viken" - http://www.nwo.no - arca
    1. Re:I think this is exactly what is needed ... by felipekk · · Score: 1

      I don't know that much about sockets, but I'm guessing the optimal here would be for it to grab a random port that is not being used between say 1000~65000 at the moment that it has to send a packet.

      Instead, it seems to be grabbing 2500 random ports at spawn and keeping them forever.

      Can't they do something more dynamic?

    2. Re:I think this is exactly what is needed ... by Alioth · · Score: 1

      If the original poster is right, it's not ports that are the issue, it's the number of *sockets* it's grabbing. It's doing the equivalent of

      fd[x]=socket(AF_INET, SOCK_DGRAM, 0);

      2500 times. You don't need to do that to use a random port for each reply, you just open the socket when you need to. Unless, of course, the underlying OS's call to socket() is extremely inefficient.

      --
      Oolite: Elite-like game. For Mac, Linux and Windows
    3. Re:I think this is exactly what is needed ... by arcade · · Score: 1

      Then I misunderstood you.

      I thought you disliked that it always grabbed a different port number. :-)

      Getting yourself 2500 ports, and keeping the same ports for the duration of the nameservers life is certainly not a very intelligent solution. For one, it's way more predictable than using 64000 randomly.

      --
      "Rune Kristian Viken" - http://www.nwo.no - arca
    4. Re:I think this is exactly what is needed ... by felipekk · · Score: 1

      I'm not the OP though.

  42. Re:CONFIRMED: Steve Jobs has AIDS !! by Alex+Belits · · Score: 0, Offtopic

    The only proper response to /b/ on Slashdot can be GNAA in Habbo.

    --
    Contrary to the popular belief, there indeed is no God.
  43. When karma-whoring hinders efforts to educate by laburu · · Score: 1

    The terminal session excerpts in Cédric's article are intelligible to a great many more Unix-speaking geeks than script kiddie-ready Ruby; therefore, regardless of the popularity of the French language, the link I provided is still probably more illuminating for most geeks than the self-congratulatory sploit TFA links to. And, in any case, if you had bothered to read past the article title and meta-info, you might have noticed the link to a suitable machine translation right there, above the article text.

    Your reply does a great disservice to people who might otherwise have clicked through and learned something. But I guess that, to you, getting a measly karma point is more important than educating people w.r.t. network security issues. You had better hope that black-hat hackers have the same linguistic scruples as you; otherwise, one of these times, the ones who are undeterred by French and Russian and [whatever else] are going to have a field day pounding your... NIC.

  44. Test your own server by Akardam · · Score: 4, Informative

    A Google search revealed this way to test specific DNS servers from the command line (in case you're using a DNS server other than the one that's authoritative for the netblock you're in):

    Good:
    $ dig +short @208.67.222.222 porttest.dns-oarc.net txt
    z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
    "208.67.222.222 is GOOD: 26 queries in 0.1 seconds from 26 ports with std dev 17746.18

    Poor:
    $ dig +short @206.13.28.12 porttest.dns-oarc.net txt
    z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
    "206.13.28.13 is POOR: 26 queries in 0.2 seconds from 1 ports with std dev 0.00"

    More discussion on this method here:
    http://www.dslreports.com/forum/r20759262-CERT-VU800113-DNS-Cache-Poisoning-Issue~start=20

  45. Re:The Book Of Internets, Chapter Three, Verse Twe by Anonymous Coward · · Score: 0

    He objected to one thing. Sheesh. You're like those Fox News morons who pretend to be level-headed and objective.

  46. Re:CONFIRMED: Steve Jobs has AIDS !! by Ant+P. · · Score: 2, Funny

    The idea of /b/ spreading outside of 4chan terrifies me more than the thought that my DNS might get hijacked, TBH.

  47. Re:The Book Of Internets, Chapter Three, Verse Twe by Lennie · · Score: 1

    If you set up your own caching server and point it to the ISP-caching server, yes. But that would kinda defeat the point of using your own caching server. If you were doing it for your security.

    --
    New things are always on the horizon
  48. Simple solution... by sal_park · · Score: 1

    Isn't there a simple solution to this ?

    Current situation:

    1) DNS server receives request to resolve x.com
    2) DNS server ask for it to be resolved by root server
    3) poison DNS server responds first, poisoning the DNS server
    4) connection closed
    5) root server responds, response is ignored

    Why can't we just:

    1) DNS server receives request to resolve x.com
    2) DNS server ask for it to be resolved by root server
    3) poison DNS server responds first (with correct id etc), poisoning the DNS server
    4) After first response is received (DNS server assumes it *could* be false) it keeps the port open for a time (say 5 seconds) waiting for a second response
    5) If no other response is received then it assumes the first response is genuine and uses it.
    6) If a second response is received it discards both as 'potentially bad' and trys again.

    Obviously this will mean any DNS request will take as long as we wait in step 4 above (5 seconds in this example), but this is on the initial query which can then be cached so the performance hit should not as bad as it first seems.

    Or have I missed something ?

  49. Y2K impact by DragonHawk · · Score: 1

    we spent great effort fixing Y2K bugs, which would not have caused serious damage (even if we had not fixed them). Therefore, we should not have fixed the Y2K bugs.

    I was involved or exposed to a number of Y2K bugs which would have led to serious problems in one field or another. (For appropriate definitions of "serious".) I don't know if planes would have fallen out of the sky, but billing statements being calculated wrong, schedules being planned wrong, phone systems crashing, etc., are pretty serious to the people actually using those systems.

    Understand that one of the biggest myths about Y2K was that the problems would manifest at 12:00 AM on 1 January 2000. Y2K problems started well before then. For example, banks, railroads, airlines, and similar started having to worry about Y2K back in the 1980's -- they routinely work on schedules spanning decades.

    I won't deny that a lot of people turned legitimate Y2K concerns into marketing opportunities, but that doesn't mean it wasn't an issue.

    For example, fans of djbdns are having a field day with this DNS thing, since djbdns doesn't have this flaw. Marketing opportunity. Not that I blame them. :-)

    --

    dragonhawk@iname.microsoft.com
    I do not like Microsoft. Remove them from my email address.
    1. Re:Y2K impact by oneal13rru · · Score: 1

      I don't deny entirely that there was real cause for some concern. I was merely making very clear exactly how much I believe in mass-overreaction. I have never seen panic as a reasonable means to solve problems, only to exacerbate them. I find it much simpler to let the people who need to deal with the problems do so, and avoid mass hysteria.

      --
      Never disregard the raw power inherent to stupidity... they call it "dumb luck" for a reason...
  50. machine cheat by Anonymous Coward · · Score: 0

    Say pieces on a board, make each piece a pair with another piece.

    like...

    |55|33|66|
    |44|66|55|
    |33|44|22|
    |22|11|11|

    a piece can only be figured out to move one way...

    pick any piece, try to move it somewhere...

    have the chosen piece move to another piece, it moves there and makes the other piece have to move too.

    when a piece is moved to another piece, it becomes a pair with the piece it moves to.
    any piece that is moved has to have it's pair move at the same time.

    any piece to move to another piece is a piece that moved at the same time as it's pair, and moved to another piece that

    moved at the same time as it's pair too. A piece that moves to another piece becomes a pair with it, and the other of the pair
    has moved to become a pair with another piece.

    try anyway, works in one way where a piece can move back to the piece to move first.

    A common type of problem, I forget what it's called.

    A piece always goes where a piece leaves, the first piece has the last piece go where it left.

    You can't move a piece that moves where the piece came from.

    There is no such thing as a free space, a piece always moves to another piece.

    A pair never moves to a pair.

    A piece works out to move where another piece can get back to where a piece moves from.

    The last move has to be known for the first move to be made, because the first move can't be understood until
    the last move is. That's because the first move is where a piece moves to and it works around to the last move, and the
    last move is where a piece can work getting to from the first move.

    so try this...

    draw starting at each piece a line that shows the piece it moves to, and each piece to move for how a piece moves back
    where it starts.

    see this as a machine diagram.

    move a piece then figure the machine diagram again, it's the same machine though...

    see how every other piece moves another way now?

    what happened for how the machine moved?

  51. Re:CONFIRMED: Steve Jobs has AIDS !! by Anonymous Coward · · Score: 0

    I am so happy I have no idea what you're talking about.

  52. Re:The Book Of Internets, Chapter Three, Verse Twe by rs79 · · Score: 1

    The ISP's dns server may not be the same as the dns server the transparent web proxy cache uses. Unless THAT buger points to a djbdns or patched dns server it doesn't matter what you or your isp does for dns service.

    Sneaky huh? I have a sense some poeple are gonna be phuqued by this.

    --
    Need Mercedes parts ?
  53. Automation the NS injection approach by laburu · · Score: 1

    FWIW, CAU has also posted a second sploit script that implements Cédric Blanchard's proof-of-concept.

  54. If only.... by Xtifr · · Score: 1

    If only we could persuade some of the botnets to launch a huge DDoS attack against him! :)

  55. Re:The Book Of Internets, Chapter Three, Verse Twe by Lennie · · Score: 1

    Ohh, sorry, I misread the parent post.

    I guess there is only one solution, pay for your bandwidth double or tripple, by getting an account on a server somewhere.

    --
    New things are always on the horizon
  56. What's open in OpenDNS? by Anonymous Coward · · Score: 0

    Any idea what the "Open" part in their name is supposed to mean?

    1. Re:What's open in OpenDNS? by xous · · Score: 1

      An Open DNS server is a server that allows recursive queries from any host.

  57. Re:CONFIRMED: Steve Jobs has AIDS !! by Anonymous Coward · · Score: 0

    THE CANCER!!

  58. Re:The Book Of Internets, Chapter Three, Verse Twe by blincoln · · Score: 1

    This has nothing to do with "dns tunnelling" whatever that is on internal networks or what have you. I dunno about where you are but around here every provider of dialup, broadband, wireless and sat uses these dumb "transparent" web proxies. They're also a vixieism, iroically.

    DNS tunneling is essentially the ability to set up a VPN tunnel using only DNS queries. It's a very interesting topic if you haven't read about it before - I only just found out about it a couple of months ago. The upshot is that if a machine has the ability to directly query DNS for arbitrary public domains, and the person using it has a public domain name and the ability to set up a pseudo-DNS server, then they can set up a VPN tunnel from that machine to their pseudo-DNS server on the public internet even if the client machine does not have internet access otherwise.

    I'm not really familiar with transparent proxies, but I would guess that they're not actually doing the DNS lookup for you, but reading the host header and possibly doing a DNS lookup on that. I mean, if you don't tell your browser/OS to use an explicit proxy, how is it going to know to hand off DNS resolution to a transparent proxy that it doesn't even know about?

    Anyway, if I'm right, then it can't really be "turned off", since you have to send a host header to get to basically every website now. And it's not as if the owners of the transparent proxies would choose to turn it off if it were optional, since presumably the reason they set them up was to intercept traffic.

    --
    "...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
  59. Don't panic by DragonHawk · · Score: 1

    I have never seen panic as a reasonable means to solve problems, only to exacerbate them. I find it much simpler to let the people who need to deal with the problems do so, and avoid mass hysteria.

    Ahhh, I see, now. No argument there! :)

    --

    dragonhawk@iname.microsoft.com
    I do not like Microsoft. Remove them from my email address.