Verisign's Wildcard A Records
Breaking the Internet

As of 15/08/2003 Verisign (the custodians of the .com and .net top level domains) have inserted a "wildcard A record" into the DNS which is designed to direct all requests for web sites with non-existent domain names to their services.

This is not a good thing for many reasons. Some of those reasons are a question of ethics, but many of them are technical.

E-Mail Domain Validation

Many ISP mail servers are configured to check whether either the SMTP "envelope" field or the "from" header correspond to a valid domain name. This is done by checking to see whether the domain name resolves. All ".com" and ".net" addresses are now explicitly resolveable and therefore this check is no longer possible.

Additionally many programs on the internet perform DNS lookups to check whether e-mail addresses submitted by users are valid addresses. These checks have now been broken. We have had to make modifications to our Ticketing Solutions ASP service to work around this change by Verisign.

DNS Realtime Blackhole Lists

Similarly, many ISP mail servers use DNS Realtime Blackhole Lists (DNS RBL) to validate the IP address of the system attempting to send mail through them. This is a common practice used to reduce spam by potentially refusing to accept e-mail from known "open relays" that are identified in these lists.

Typically these DNS RBLs work by creating a DNS record for each known open relay a.b.c.d such that d.b.c.a.somedomain.com resolves.

The current default SpamAssassin configuration refers to a DNS RBL hosted at orbs.dorkslayers.com. As it happens, this particular RBL is now defunct, and until today that didn't really matter. Unfortunately Verisign's actions now mean that any attempt to lookup anything.orbs.dorkslayers.com now resolves, leading to false positives.

Invalid MX records no longer invalid

E-mail servers use what are known as "MX records" to determine which hosts on the internet are responsible for handling the e-mail for individual domains. Each domain may have multiple MX records, and each record has a priority value to let remote servers know which host to try first.

Before today if one of your MX records happened to point to a non-existent host in the .com or .net TLDs it didn't matter. All standards compliant mail servers would simply skip over the invalid MX record and try the others in the list.

Today, it's a different matter. That invalid MX record now resolves, and worse still, it points at a host that Verisign are running that tries to send back a "550 domain does not exist" error. If your other MX hosts aren't working, and Verisign get the mail instead, it will bounce.

Worse still, the fake SMTP server that Verisign are running doesn't actually comply with the relevant internet standards, it simply sends back a standard set of response messages regardless of what data has been sent to it. If you're sending a mail message to multiple recipients that happens to end up at Verisign's server the dialog between the two servers does not follow the sequence that Verisign expect. This could have random nasty consequences.

The Ethics

Firstly, it is important to note that these changes were made with almost no consulation with the internet community, and certainly not with their approval.

Perhaps the worst ethical breach is that the wildcard record doesn't only affect domain names that haven't yet been registered, it also affects domain names that might (for completely legitimate reasons) simply not have DNS servers recorded in the "zone files". This is the case with dorkslayers.com as mentioned above. It is a valid, registered domain name, it just doesn't have any active addresses operational at the moment. By resolving all requests for addresses within this domain Verisign are intentionally interfering with the domain owner's right to exclude their domain name from the set of active domains.

Verisign have explicitly stated that they will log every request for an invalid domain name, and log all web and e-mail accesses to the host (64.94.110.11) now returned by their DNS servers. We apparently can't trust them to run the .com and .net namespace properly. Can we really trust them not to abuse this log data?

Ray Bellis, Technical Director, Community Internet plc, 16 September 2003