A couple of years ago, I wrote a humourous article that mentioned a company taking advantage of the DNS to illegitimately take over most of Internet. I didn't expect it to come true, let alone by using legitimate means.
As of 2003-09-15, it has.
Verisign, the operator of the "com." and "net." registries, has added a wildcard "A" resource record for both "*.com." and "*.net.". Any DNS lookup for a domain name that is a subdomain of "com." or "net.", and that doesn't match a real registered subdomain, now maps to the IP address 64.94.110.11, which Verisign owns, whereas before the lookup would result in a "no such name" error.
[C:\]dnsqry a verisign-internet-coup-a098y35$4ibvs8!y34kbsad.com. | grep /b/u Answer:
Answer: verisign-internet-coup-a098y35$4ibvs8!y34kbsad.com. IN A 900 64.94.110.11
[C:\]
Effectively, Verisign has just staged a bloodless coup to take over vast swathes of Internet.
Ironically, this coup is perfectly legitimate. Everyone in the world delegates authority over the DNS namespace to one of the various DNS root server organizations, such as ICANN, ORSC, and PacificRoot. In turn, these root server organizations all delegate authority over "com." and "net." to Verisign. Verisign has, by pretty much everyone on Internet, been indirectly delegated the power to control "com." and "net." and all of their subdomains, and is using that power perfectly legitimately.
The consequences of this coup are severalfold.
Until now, supplying a non-existent name under "com." or "net." to a tool such as ping or traceroute would result in a "no such name" error message from the tool. Network administrators who made typing errors would discover them immediately.
Now, such typing errors are going to result in ping, traceroute, and their ilk attempting to communicate with 64.94.110.11, leading network administrators that haven't spotted their error to mis-diagnose network problems.
[C:\]tracerte www.microsfot.com.
traceroute to www.microsfot.com (64.94.110.11), 30 hops max, 38 byte packets
0 …
Until now, a "lame delegation" that resulted from a mis-spelled intermediate domain name in an "NS" resource record was easy to spot. DNS checking tools would highlight the "no such name" error that resulted when they attempted to look up the intermediate domain name.
[C:\]dnsgetns access-board-members.gov.
66.28.0.14
66.28.0.30
IUZ0031: The domain name "PRI6.NDS.PSI.NET." does not exist.
[C:\]
Now, the lookups for mis-spelled intermediate domain names will succeed (if those mis-spellings are in the second-level label of the domain name), yielding the IP address 64.94.110.11. All that the DNS checking tools will report is that no response could be obtained from the content DNS server being delegated to (since Verisign currently doesn't provide content DNS service on that address), leading DNS administrators to waste time looking for IP connectivity problems or problems with the operation of their servers, when they should have been looking for spelling errors.
Moreover, if Verisign were to start providing content DNS service on that IP address, in addition to the content HTTP service and SMTP Relay service that it already provides, the DNS checking tools would not even have lack of responsiveness on the part of the content DNS server to report; leading DNS administrators to waste time labouring under the mistaken belief that their servers were not serving the data that they were being given and looking for problems with their server softwares that weren't actually there.
Worse yet, given what Verisign has already done with wildcards, it is probable that any such content DNS service would also employ wildcarding and publish positive answers in response to queries about any domain names, impeding DNS fault diagnosis further still.
Until now, a mis-spelled intermediate domain name in an "MX" resource record would cause SMTP Relay clients to simply use the other SMTP Relay servers for a domain, if any.
Now, the lookups for mis-spelled intermediate domain names will succeed (if those mis-spellings are in the second-level label of the domain name), yielding the IP address 64.94.110.11.
Worse, Verisign runs an SMTP Relay server on that address. A mis-spelled intermediate domain name in an "MX" resource record now causes SMTP Relay clients to attempt to send their mail to Verisign. But Verisign's SMTP Relay server rejects all mail transactions. So whereas, before, in the event of a mis-spelling mail was still successfully delivered by the other SMTP Relay servers for a domain, a mis-spelling now can cause mail to be rejected by Verisign, and not be delivered at all.
(The SMTP Relay server that Verisign runs on that address, which calls itself "Snubby Mail Rejector Daemon v1.3" incidentally, is worthy of some comment. Apart from "QUIT" it doesn't appear to process the commands that are given to it at all. Instead it responds with a fixed series of responses, whatever commands are actually issued:It is somewhat disturbing that this simplistic and wildly erroneous behaviour is version 1.3 of the software.)250 OK 250 OK 550 User domain does not exist. 250 OK 221 […] closing transmission channel
Several SMTP Relay server softwares attempt to perform DNS lookups on the domain name portions of the sender mailboxes on message envelopes, on the grounds that they do not wish to accept mail from senders whom they will not be able to communicate with in the event of a transport or delivery problem. Such lookups follow the standard procedure of falling back to an "A" lookup if an "MX" lookup returns an empty resource record set.
For example:
- qmail with Nagy Balazs' MFCHECK patch applied does this.
- Postfix when configured to use its reject_unknown_sender_domain restriction does this.
Until now, the "MX" DNS lookup would have yielded a "no such name" error, and such measures would have blocked mail that used non-existent domain names in their envelope sender mailbox names.
Now, because of the wildcards that Verisign has deployed, such measures to reject unwanted mail are bypassed if the sender's mailbox is in one of the subdomains of "com." and "net.", since now all possible subdomains of "com." and "net." exist, according to Verisign. (This is what DNS wildcards do.) Whilst the "MX" lookups for (previously) non-existent domain names yield empty resource record sets, the fallback "A" lookups yield Verisign's IP address 64.94.110.11. Thus the SMTP Relay servers believe that they can, in the event of an error, communicate with the sender, and accept the mail that, before, they would have rejected.
Until now, a mis-spelled domain name in a recipient mailbox name would yield a failure when trying to look up the SMTP Relay server to contact, and mail transport to return an error message to the sender. The mail would not actually be transported anywhere.
Now, the lookups for mis-spelled domain names (that are subdomains of "com." or "net.") in recipient mailbox names will succeed, yielding the IP address 64.94.110.11. Mail systems now attempt to send mail, addressed to such mis-spelled mailboxes, to Verisign.
Worse, Verisign has announced its intention to publish connection data for its SMTP server, including full content, to researchers.
Several SMTP Relay server softwares (and ancillaries) come pre-configured to query several SMTP Relay client blacklists that are hosted in the DNS. In several cases, such as the erstwhile dorkslayers.com, those blacklists have ceased being published.
Until now, the use of such a defunct blacklist was benign. The DNS lookups, for looking up the IP addresses of SMTP Relay clients on the blacklist, would result in "no such name" errors, which is interpreted to mean "this client is not blacklisted".
Now, the lookups on those defunct blacklists succeed, for all IP addresses. This is because domain names being looked up match Verisign's wildcard, and an "A" resource record is thus returned (listing 64.94.110.11) by Verisign. All of a sudden, any SMTP Relay server that was using defunct blacklists has started reporting the entirety of Internet as blacklisted.
Whereas before the use of a defunct blacklist was, by design, benign; now, thanks to Verisign, defunct blacklists have the equivalent of (a very draconian) Dave The Resurrector.
(As of 2003-09-16, the dorkslayers.com domain is registered once again and is delegated to Joker.COM's content DNS servers, which are returning "no such name" errors to DNS lookups. This appears to be thanks to the efforts of Bill Maloy, president of Gulfcoast On-Line Development, Inc in the United State.)
The "W32.Sobig.A@mm" Microsoft Worm propagates itself in mail messages purporting to come from big@boss.com.
Until now, DNS lookups against "boss.com." would fail, because the "HOST" records for the domain were deliberately removed, in order to foil that very Microsoft Worm. SMTP Relay servers, who rejected mail transactions whose envelope sender mailboxes were in domains that couldn't be looked up successfully, would thus reject "W32.Sobig.A@mm" because a DNS lookup for boss.com would fail.
Now, because of the wildcards that Verisign has deployed, DNS lookups for boss.com. succeed once more. "W32.Sobig.A@mm" is once again welcome at many SMTP Relay servers, because Verisign is now saying that that domain exists.
[C:\]dnsqry a boss.com. | grep /b/u Answer:
Answer: boss.com. IN A 900 64.94.110.11
[C:\]
Various people have mused on how they can resist Verisign's coup. There is only one way to properly resist. There are several other rather flawed ideas that have circulated, however.
Verisign's Internet coup works solely because we have all, indirectly, delegated authority over "com." and "net." to it, as described earlier. The only reliable way to resist the coup is to simply revoke that authority : Contact the DNS root server organization that you delegate authority over the DNS namespace to, and tell it that you do not want it (in its turn) to delegate authority over "com." and "net." to an organization that doesn't want to serve up "no such domain" errors and that captures all unused subdomains by mapping them to its own services.
(Unfortunately, if your chosen DNS root server organization is ICANN, you'll encounter a conflict of interest. Verisign also runs two of ICANN's 13 "." content DNS servers, and is unlikely to bow to the wishes of any users of ICANN's root servers who ask it to stop delegating authority over "com." and "net." to itself. Your only recourse, in the event of such non-coöperation, is to stop delegating authority over the DNS namespace to ICANN itself, and to pick another more coöperative root server organization and delegate authority to that instead.)
Of course, there isn't currently an alternative organization available for the root server organizations to delegate the authority over "com." and "net." to, but if everyone delegating authority to the various root server organizations puts enough pressure on them that they start looking for alternative organizations to delegate "com." and "net." to, this threat might in turn motivate Verisign to change its behaviour.
Putting pressure on someone whom you have only indirectly delegated authority to is difficult. (Albeit that most resolving proxy DNS server softwares provide delegation override mechanisms of various kinds, allowing direct control of whom authority over "com." and "net." is delegated to, if needs be.) Several people have come up with various other, less arduous, schemes to try to resist Verisign's coup. Alas! They are all flawed in several ways, not least because they fail to address the fundamental fact that everyone has delegated the authority to Verisign to legitimately do what it has just done.
Some people have produced patches to various proxy DNS server softwares, including to dnscache from Daniel J. Bernstein's djbdns, and to ISC's BIND. These patches recognize answers that map domain names to the IP address 64.94.110.11, and replace such answers with "no such domain" answers. These patches are flawed for two reasons, in addition to the fundamental flaw of their not addressing the true cause of the problem:
Verisign can change the IP address that it is publishing at any time. People employing these measures have manoeuvred themselves into playing a never-ending game of catch-up with Verisign. Verisign need only change the address, and they have to modify their proxy DNS server softwares to match. When Verisign says "hop!", they have to jump.
Verisign can turn this measure against those who employ it. This measure is an effective denial-of-service weapon against any IP address. If, for example, one day Verisign changes the IP address that it publishes from 64.94.110.11 to 66.218.71.198, anyone employing this measure will find that they have just cut themselves off from Yahoo's HTTP server.
(Indeed, this weapon is even more potent than that. Given the way that "no such name" answers take precedence over any actual resource record sets in most caching proxy DNS server softwares, the simple addition of an "A" resource record listing 64.94.110.11 suddenly becomes an effective denial-of-service attack against entire domains.)
Some later versions of these patches attempt to determine which IP address to recognise, by explicitly issuing an "A" query for the literal names "*.com." and "*.net." in order to find out what the wildcard points to. These modified patches contain two further flaws, in addition to the aforementioned ones:
This mechanism provides Verisign with a means for fully automating any denial-of-service attacks that it makes using this new weapon, rather than having to wait for DNS administrators to manually update their server configurations with each new IP address that it chooses to switch to, as it would have to do otherwise.
Verisign can defeat the mechanism by turning its own automation against it. If one day Verisign modifies its servers to publish empty answers for explicit "A" queries for the literal names "*.com." and "*.net.", the mechanism will have no IP address to match against in the first place as a result. (Wildcards are internal matters for content DNS server softwares. There no requirement in DNS that they actually be accessible from outside a content DNS server.)
Some ISPs have altered their routing tables so that IP traffic to 64.94.110.11 is never routed to Verisign. This measure is flawed for three reasons, in addition to the fundamental flaw of its not addressing the true cause of the problem:
Verisign can change the IP address that it is publishing at any time. The ISPs employing these measures have manoeuvred themselves into playing a never-ending game of catch-up with Verisign.
Verisign can turn this measure against the customers of the ISPs who employ it, thereby putting pressure on the ISPs via the complaints from their customers. This measure is an effective denial-of-service weapon against any IP address. If, for example, one day Verisign changes the IP address that it publishes from 64.94.110.11 to 212.58.226.40, the ISPs employing this measure will find that they have just cut all of their customers off from the BBC.
This measure doesn't prevent softwares from receiving 64.94.110.11 as the answer to a DNS lookup in the first place, and doesn't remedy the problems that have been created for DNS fault diagnosis and for anti-UBM mechanisms.
ISC has produced a patch to BIND that provides a new delegation-only attribute that can be set on "zones". For such "zones", responses are transformed depending from whether they contain delegation information and what that information is:
This measure at least attempts to address the true cause of the problem. It attempts to provide a mechanism whereby BIND can be told to treat everything published by Verisign as either a referral or a "no such name" error, thus restricting Verisign's ability to publish anything else. However, it is flawed for three reasons:
Verisign can defeat the mechanism by simply adding delegation information (for some appropriate subdomain of "com." or "net." of its choice) to responses generated from its wildcards.
The delegation-only mechanism effectively distinguishes registered domains from non-registered domains by the existence of delegation information, for a subdomain of "com." or "net.", in the responses that it receives. Responses with such delegation information are left untouched by the mechanism. If, one day, Verisign changes its server to add a suitably generated "NS" resource record set to all of its wildcard-generated responses, the delegation-only mechanism's transformation of those responses into "no such name" answers will not be triggered, and Verisign's wildcard-generated information will be accepted by BIND once again.
Verisign can turn this measure against, specifically, those who employ it, in order to discourage them from using it. This measure is an effective denial of service weapon against all "glue" for "com." or "net." subdomains, and thus against those subdomains themselves. If, one day, Verisign changes its servers to never publish delegation information along with any complete answers that it publishes, the delegation-only mechanism will start denying the existence of "glue" when it is explicitly looked up.
The delegation-only mechanism turns complete answers without any accompanying delegation information into "no such name" errors. Such an answer in response to an explicit query for an intermediate domain name used in a delegation, such as (for example) "m.gtld-servers.net.", will be seen one way by those employing delegation-only, and another way by those not doing so. Those not employing the mechanism will still see the actual answer given. Those employing the mechanism, however, will see a "no such name" error for "m.gtld-servers.net.", as a result of the delegation-only mechanism transforming the response because it lacks accompanying delegation information.
Moreover, by turning off all "additional section processing" altogether, thereby forcing all "glue" to be explicitly fetched, Verisign can deny service for all "com." or "net." subdomains to people employing delegation-only mechanism (because it will turn the results of the "glue" fetches into "no such name" errors, thus effectively denying the existence of any "glue"), whilst leaving those who do not employ it relatively unaffected; thereby giving people a large incentive to not use the delegation-only mechanism.
The delegation-only mechanism prevents correct "NS" lookups in certain circumstances. This allows anyone with the right to obtain proxy DNS service, through a BIND server with this patch applied, to execute denial of service attacks against whatever subdomains of "com." or "net." they choose.
The response to an "NS" query for a "com." or "net." subdomain, from Verisign's content DNS servers, contains no delegation information. (At least, according to the delegation-only mechanism's definition of containing delegation information. Verisign's DNS server softwares place the "NS" resource record set in the "answer" section, and not in the "authority" section.)
[C:\]dnsqry /server:m.gtld-servers.net. ns google.com. | tail /12
[192.55.83.30:0035] -> [0.0.0.0:0000] 164
Header: 0001 1+4+0+4, R, , query, no_error
Question: google.com. IN NS
Answer: google.com. IN NS 172800 ns2.google.com.
Answer: google.com. IN NS 172800 ns1.google.com.
Answer: google.com. IN NS 172800 ns3.google.com.
Answer: google.com. IN NS 172800 ns4.google.com.
Additional: ns2.google.com. IN A 172800 216.239.34.10
Additional: ns1.google.com. IN A 172800 216.239.32.10
Additional: ns3.google.com. IN A 172800 216.239.36.10
Additional: ns4.google.com. IN A 172800 216.239.38.10
[C:\]
For example: An attacker can issue an "NS" query against such a patched BIND proxy DNS server for "google.com.". If the delegation information for "google.com." has not already been obtained and cached, BIND will query Verisign's "com." content DNS servers, receive a response without delegation information in it, translate that response in accordance with the delegation-only rules, and cache a "no such name" error. That lookup and any further ones for "google.com." will fail. Further lookups for subdomains such as "www.google.com." will be affected since the "no such name" error prevents BIND from locating the "google.com." content DNS servers.
ISC has produced a patch to BIND that provides a new root-delegations-only option. This mechanism simply extends the flaws of the delegation-only mechanism to cover all top-level domains and ".", automatically. Attackers who obtain proxy DNS service via such a patched BIND server can execute denial of service attacks against any name in the entire namespace.