What's the problem we're trying to solve?
In order to lookup and obtain the IP address associated with a DNS name, a resolving DNS nameserver (a “resolver”) sends a single UDP/IP packet containing a DNS query to another DNS nameserver that may either have the answer or know of another nameserver that might. To guard against forged and spoofed replies, incoming candidate replies must exactly match the query to which they are replying. Unfortunately, the DNS protocol we are (still) using today was designed long before the threat represented by “spoofed replies” was appreciated. So no effort was made to make DNS replies “spoof resistant.” Queries contain a 16-bit Transaction ID which can only assume one of 65,536 possible values. Thus, 65,536 spoofed replies could be sent with each reply containing a different transaction ID and one of them would match!

When Dan Kaminsky realized the gravity of this problem in early 2008, he convinced the DNS industry to upgrade their DNS resolving nameservers to emit their single UDP/IP packets from random IP ports. Since there can be up to 65,535 possible ports, a successful spoofed reply packet would then need to correctly guess both the query's Transaction ID and the query's originating source port. This simple-to-implement change decreased the likelihood of obtaining a successful spoofed match from just 1 in 65,536 to 1 in 4,294,901,760 . . . or 1 in nearly 4.3 billion!

Unfortunately, legacy (pre-existing) DNS software and networking constraints can prevent DNS resolvers from emitting their packets from the entire potential 16-bit source port range. If the source port range is reduced significantly, or if a predictable pattern of source ports is used (such as simply incrementing the port number), the feasibility of successful attacks increases dramatically.

As a consequence of all this, end-users like you, who rely upon their ISP's domain name servers for help in connecting them to the proper web sites, need to know how “spoofable” the specific DNS servers serving them might be.

How can this “spoofability” be determined? . . .

That's what GRC's DNS Nameserver Spoofability Test accomplishes.

Schematic of GRC's DNS Spoofability Testing System

The diagram above depicts the operation of GRC's DNS Nameserver Spoofability Test. Step by step, the test proceeds as follows (see the numbers above and their descriptions below):

	The top of the DNS testing page contains a progress monitoring table. The beginning of each line of this table contains references to one or more images located at a special “virtual” domain of the form “xxxxxxxxxxxxx.dns.grc.com” where the “xxxxxxxxxxxxx” is replaced with a unique 13-character string of characters that has never been used before. This assures that the IP address of the virtual domain is unknown. In order to retrieve and display these images, the user's web browser must first lookup the IP address for this special “virtual” domain. So the browser asks the underlying operating system which, in turn, sends a DNS query to one of the DNS servers assigned to servicing the Internet connection. This request, from the user's computer to the ISP's DNS nameserver is shown by the number (1) above.
	Upon receiving the unique domain name query from the user's computer (the DNS client), the ISP's resolving nameserver begins attempting to learn the IP address of the new domain. To do so it forwards the query to a special “pseudo-DNS nameserver” located at GRC which we wrote for this special purpose.
	When GRC's special pseudo-nameserver receives a request for an IP address of the form “xxxxxxxxxxxxx.dns.grc.com” (where the 13 x's are actually a string like “d31gjjepamvkk”), our special server responds by indicating that the requested domain is actually an “alias” of the real domain name, which is a good deal longer and more complex. So instead of returning an IP address, GRC's special pseudo-server returns a DNS “CNAME” record that instructs the querying nameserver to lookup the IP address of a domain name of this form: ...a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.xxxxxxxxxxxxx.dns.grc.com Note that the original “xxxxxxxxxxxxx.dns.grc.com” is still there, on the far right, but it's now been buried behind a very long string of repeating “a” domains. In the box above, the three dot ellipses (...) at the left end indicate that the "a.a.a." pattern continues repeating off to the left for some length. In practice, there are typically about 50 of these repeating “a” domains.
	The domain name system is a hierarchal system that is evaluated, or “traversed,” from the “root” on the far right, step-by-step to the left until the final sub-domain name at the far left end is reached. So the only way for the ISP's resolving nameserver to get the IP of the machine at the domain residing at the far left end of that ridiculously long domain name is for it to step though the entire length of the domain name from right-to-left one “level” at a time. This is the way we induce the ISP's resolving nameserver to send us a large number of queries one after another in a short time. At each level, the ISP's resolver asks that level's nameserver for the nameserver at the next level down (to the left). GRC's special spoof-testing nameserver pretends to be each level's nameserver which allows GRC to receive and collect all of the successive queries sent by the ISP's nameserver as it patiently walks the domain name hierarchy. During this time, as shown by the (3) and (4) arrows in the schematic above, queries and replies are flying furiously back and forth between the ISP's resolving nameserver and GRC's special pseudo-nameserver. NOTE: It's quite likely that the ISP's resolving nameserver has never seen a domain name like this despite the fact that it's an entirely valid name within the domain name system. However, because the name is so unusual, some consumer-grade routers appear to be unprepared for an encounter with such a name. Unfortunately, they ungracefully collapse and crash when they attempt to deal with such long names.
	Finally, after all of this exhausting back and forth (typically 50 times) . . . just when the ISP's resolver is about to reach the far left end of the name, ready to declare victory and receive its reward of the wacky long domain name's IP address, GRC's pseudo-nameserver deliberately plays dumb, as if it doesn't know the final answer and returns an invalid and illegal response. But that's fine with us, because we already have all the data we were hoping to collect. GRC can now analyze all of the queries it received from the ISP's resolver and present a report about their randomness and unpredictability to the user running the test.
	Having received an invalid response from GRC's pseudo-nameserver, the ISP's resolver (probably feeling somewhat disgusted after everything it was just put through) returns a failure message to the user's computer indicating that the originally requested domain (of the form “xxxxxxxxxxxxx.dns.grc.com”) is somehow invalid. NOTE: The practice of finally deliberately failing the domain name lookup grew out of our development testing. We were initially rewarding the ISP's resolver with a successful lookup and an IP where the user's browser could obtain the long-awaited image file. But we soon discovered that succeeding the final lookup also crashed another set of consumer routers! This was caused because the ISP's resolving nameserver returns not only the final IP address, but also that crazy-long “a.a.a.a....” alias name in its reply . . . which again causes some consumer routers to go belly-up. The “router crash test” that was developed from this research does successfully deliver the final IP in order to test the router's “crashability” in this fashion as well. But since crashing someone's router prevents them from learning about the behavior of their ISP's nameservers, we deliberately avoid crashing routers during our normal test.

In the diagram above, the ISP's nameservers (usually at least two) configured for use by the user's PC are the same nameservers that query GRC for the unknown domain names. After all of the querying is completed, the DNS spoofability report will show the IP addresses of those nameservers. However, as shown below many ISPs use a slightly more complex system of “forwarding nameservers” and “resolving nameservers”:

Intermediate DNS “Forwarding” Nameserver

As you can see from this diagram, the user's computer (the DNS client) sends its DNS query to the nameservers it has been configured to ask. But rather than being “resolving” nameservers, those nameservers are “forwarders” that forward the query to one or more resolving nameservers. In this case, the IP addresses that the user's machine is configured to query for DNS lookups (the forwarders) will be different from the IP addresses of the resolvers that send GRC queries on behalf of the user. Therefore, the final spoofability test will show different IP addresses and possibly many more resolving servers than the user's computer is configured to query.

With an understanding of how this nameserver query/reply system operates with its expansion of the “xxxxxxxxxxxxx.dns.grc.com” short domain name into the much longer multi-level “a.a.a.a.a...” name, and with the concept of either eventually succeeding or failing the final domain name lookup, the meaning of the customizable test parameters should be more intelligible.

The Customizable DNS Spoofability Test utilizes five parameters that can be changed from their default to induce various useful diagnostic behaviors from remote resolving nameservers:

• “Number of Sub-domains” & “Name Resolution Point”:
As shown in the diagram below, the “Number of Sub-domains” parameter determines the length of the expanded domain name by specifying the number of “a” sub-domains added to the left end of the base domain name:

Similarly, the “Name Resolution Point” parameter, shown above, determines at what point in the back-and-forth query/reply interaction the special GRC pseudo-nameserver finally resolves the request and returns the requested IP address. The value of “Name Resolution Point” versus “Number of Sub-domains” determines the outcome of the query/response interaction as follows:

• If “Name Resolution Point” is less than “Number of Sub-domains”, GRC's server will resolve the entire, longer, requested domain name before it walks the querying DNS resolver all the way out to the left end of the name.

• If “Name Resolution Point” equals “Number of Sub-domains”, GRC's server will resolve the requested domain name in normal fashion when the left end of the expanded domain name is reached.

• If “Name Resolution Point” is greater than “Number of Sub-domains”, GRC's server will never resolve the requested domain name. It will reply in a deliberately “defective” fashion once the point specified by the “Number of Sub-domains” has been reached. As explained in the grey box below point #6 above, this deliberate failure has successfully avoided crashing some consumer routers, which helps to minimize any inconvenience from the use of our standard DNS spoofability test.

• “Simultaneous Query Chains”:
A meaningful appraisal of “randomness” or “entropy” requires the analysis of a surprising number of samples. Since sub-domain counts larger than 50 cause some consumer routers to crash, our default DNS test deliberately limits the number of expanded domains to 47. But this limited domain length results in too few nameserver queries to establish an accurate analysis of a server's query randomness. In order to induce the generation of sufficient queries, we run multiple simultaneous queries for several unique domain names where the “Simultaneous Query Chains” parameter (which defaults to 4) specifies the number of simultaneous domains to resolve at one time.

• “Minimum Query Chain Duration”:
One of the ways in which GRC's DNS spoofability test is significantly superior to any of the others on the Internet (see the Acknowledgments page for links to the others) is in its ability to discover all of the many possible resolving nameservers that might produce DNS queries on behalf of the user's DNS client PC. It is not uncommon for us to discover more than ten resolving nameservers where the other testing sites find only one or two. This is important because any weak and non-random resolvers could compromise the user's Internet access. We therefore want to find and check every possible nameserver. One of the ways this is accomplished is through deliberately “throttling” the rate of our replies to queries to keep the querying nameservers busy in their pursuit of the final domain name IP address. During this wait, the user's client PC or an ISP's forwarding nameservers, which originally initiated the request for DNS resolution, will become impatient and will eventually initiate duplicate queries to additional nameservers. The “Minimum Query Chain Duration” parameter (which defaults to 5 seconds) allows a response delay to be evenly distributed across our DNS replies in order to retard the return of a final answer and thus cause the original waiting systems to generate duplicate queries of additional nameservers.

• “Search Patience”:
As explained in the item above, this system is designed to locate all possible resolving nameservers servicing a client's PC (you) since the vulnerability of any such nameserver translates into a vulnerability for the user. During the extensive developmental experimentation with this system, we discovered that a single set of queries—no matter how long, slow or deep—often failed to find all of the nameservers that would ultimately be found after repeated searching/querying. We therefore created the “Search Patience” parameter to perform repeated sets of queries, as many as needed, until no additional new nameservers were discovered for “n” sets of queries, where “n” is the “Search Patience” (which defaults to 4). Setting “Search Patience” to zero causes a single query iteration to be performed.