A:The potential problem of DNS spoofing has been well known and understood for quite some time. So searching the Internet for “DNS Spoofing” will turn up many hits (at the time of this writing, Google returned about 155,000 results). But if you are looking for a clear tutorial-style explanation, the Security Now! podcast Leo and I assembled on this topic back 2008, shortly after Dan Kaminsky reminded the world about so-called “Cache Poisoning Attacks” is probably the best place to start. You can download the audio in two sizes or the transcript text in three different formats:

Security Now! Audio/Textual Podcast #155 “Bailiwicked Domain Attack” • Highest Quality, 103 minute, Audio File 49 MB • Lower Quality (1/4 size) Audio File 12 MB • Formatted Web Page podcast transcript 131 KB • Raw Text File podcast transcript 78 KB • Printable, Offline Readable, PDF transcript 137 KB

A:This issue causes more confusion than anything else. Users set their DNS servers to IP “A” and “B”, but the spoofability test shows resolvers “X” “Y” & “Z”. The query flow diagram below shows what is going on:

Intermediate DNS “Forwarding” Nameserver

Your computer, shown as (1) in the diagram above, is configured to use the nameserver (2). But instead of it directly issuing the public queries on behalf of your computer, it forwards those queries to one or more “resolving nameservers”, shown as (3) in the diagram above, which do the actual DNS resolving work. Those resolving nameservers (3) are then the ones that issue the public queries onto the Internet which are picked up, seen and analyzed by GRC's Spoofability testing nameserver (4).

So GRC's Spoofability testing system (4) “sees” the queries coming from the one or more resolving nameservers (3) and reports their IPs. And this is what you want, since it's the public queries being made by the resolving nameservers that would be the spoof targets for any DNS cache poisoning & spoofing attack.

A:Whoops! During the development testing of the DNS Spoofability testing system we discovered that some testers' routers were dying during the test and dropping their user's networks offline. In some cases the routers would recover after a while by themselves. But it was usually necessary to shut down and reboot the router to bring it back to life. (No permanent damage was ever done to anyone's router, the testing procedure simply crashed the router.)

Through additional testing we finally determined specifically what it was about the original testing that was causing these routers to crash and we were able to redesign the test to remove that aspect from the regular spoofability testing. But since the spoofability test was only causing a user's PC to perform valid DNS queries, and since those queries should never cause anyone's router to crash, we also created a separate “Router Crash Test” to allow anyone who was curious to see whether their own router might be crashable.

We don't know whether there's any way to exploit a router's “crashability” to perform a remote takeover of someone's network. But most security exploits begin as system crashes which are then explored and developed into more powerful vulnerabilities. Either way, it is now true that any web site which wanted to could cause any of the crashable routers listed on the Router Crash Test page to crash at any time. That's not good.

A:Yes!  The trouble arises from the fact that the router is acting as the network's DNS server . . . and doing an inadequate job of it. Very few small office home office (SOHO) routers make good DNS resolvers. Mostly they just get in the way and add no value whatsoever. They don't cache, they don't accelerate, they merely catch and forward DNS requests from inside the network to the public Internet. They're just in the way. And when they are crashable, they're worse than useless. So if you simply configure your PC to use your ISP's DNS servers instead of your network's router, or reconfigure your network router to forward your ISP's DNS resolvers, or if you choose the best resolvers for your location (see GRC's DNS Benchmark for that) you'll be in much better shape.

A:A spoofed DNS reply contains the IP address of a malicious server. If such a reply is accepted as valid by the receiving DNS resolver, any users of that DNS resolver who request the IP address of the spoofed domain will be redirected to a malicious server. Generating a spoofed DNS reply is inherently a “blind” process because the spoofer cannot see and does not receive the DNS query, the attacker must correctly guess several of the query's parameters in order for it to be accepted as valid. Therefore, the more predictable the queries are, the more predictable the replies are, and the easier they are to guess.

“Entropy” in this context the refers to the inherent randomness of values being used to form DNS queries. If the same single value were always used, it would have effectively zero entropy since it never changes and could be easily guessed. In fact it would simply be known. Similarly, if a value increased linearly and continuously by one each time, its entropy would be very low since its future values could be easily predicted. Or if a value jumped among only a few possible values there would be a high likelihood of guessing it.

The DNS Spoofability system carefully examines a large set of query values in an attempt to determine their “provable entropy”. The system is able to determine if entropy is obviously low, but software does a notoriously poor job of determining whether entropy is high. The human eye is able to do a much better job of spotting patterns amid noise, which is why the Spoofability page provides those scatter diagrams... to give its users the chance to spot any obvious patterns.

A:Since the Spoofability results page is long, a simple screen capture won't capture the entire page. Various web browsers often have add-ons to accomplish this. A free add-on for Firefox which works perfectly is “ScreenGrab” and we recommend it without hesitation if you are a Firefox user.

A:To understand exactly what this system is doing, how it works, and how it develops its results, please first see the “How This Works” page which presents a very clear, step-by-step explanation of the operation of the Spoofability testing system. Additionally, the “Custom DNS Nameserver Spoofability Test” page allows you to experiment with the various testing parameters you'll learn about on the How This Works page. Together, those two pages should answer all of your questions.

A:Many ISPs have large banks of DNS resolvers dedicated to providing DNS services for their users. The strategies differ about which resolver will receive which query. Some might use a round-robin approach, others might use a least-busy strategy. But there's no way to force every resolver that might be available to be used. Ultimately, it's a matter of chance. GRC's DNS Spoofability testing system uses a number of strategies specifically designed to encourage every possible DNS resolver to reply and be seen, but there's no way to force this. So you may see some variation from one run to the next.