All your *.COM./*.NET. are belong to us.

What has just happened

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.

Legitimacy of the Verisign Internet coup

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.

Consequences of the Verisign Internet coup

The consequences of this coup are severalfold.

It just became harder to diagnose network problems.

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 …

It just became a lot harder to diagnose DNS problems.

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.

Mail transport just became less reliable (1).

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:

250 OK
250 OK
550 User domain does not exist.
250 OK
221 […] closing transmission channel
It is somewhat disturbing that this simplistic and wildly erroneous behaviour is version 1.3 of the software.)

It just became possible to bypass widely used anti-UBM measures.

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:

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.

Mail just became less private.

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.

Mail transport just became less reliable (2).

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.)

Certain Microsoft Worms are now welcomed by SMTP Relay servers once more.

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:\]

Resisting the Verisign Internet coup

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.

The only correct way to address the problem is by administrative, not technical, means.

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.

Software "fixes" don't solve the problem, and actually make the situation worse.

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:

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:

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:

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:

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.


© Copyright 2003–2004 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.