A list of (mostly) technical consequences of TLD wildcards, in no particular order...
Previously, browsers and HTTP proxies could detect non-existant servers and do things like:
Now, all com/net typos go to the Verisign search page.
Non-port 80 HTTP requests for hosts that resolve to the wildcard address receive a "connection refused" error message instead of an "unknown host" error message.
sitefinder returns a "disallow all" robots.txt file. What effect does this have for names that are in transition? For example, if "rmtl.com" forgets to pay their bill, robots connect to sitefinder and receive the "disallow all" robots.txt file. Their site does not get indexed, and might even be removed from existing indexes. How long does a robot wait until it checks robots.txt again?
The Web Proxy Auto Discovery (WPAD) is a way for user-agents to automatically learn about HTTP proxies they are supposed to use. It works by making a DNS request for "wpad.domain.name". If the user has a typo, or is using a made-up domain name (in com/net), these WPAD lookups now succeed and resolve to Verisign. In theory, Verisign could return a proxy auto-config function and control many aspects of the user's browsing. In other words, they could know exactly every web page visited by a user.
Even without sending back a valid WPAD answer, Verisign can also collect information such as
The DNS registration system allows for certain names to be registered, but not be usable. These special names do not have delegated nameservers. Previously, a query for such a domain resulted in a "no such domain" error. Verisign's wildcard can't differentiate between a name that does not exist (ooooooooooooooooooooooooooooooo.com) and one that does exist, but does not have any nameservers (a.com).
A registered name may not have any nameservers for a number of reasons:
When a registrant does not pay their bill, their domain name is deleted from the top-level zone file and it goes into a "redemption grace period." Previously, such domains would not resolve, sending an obvious signal to the registrant that something is wrong. Now, this signal is less obvious.
Now, names that have illegal characters in them are resolving to an IP address. These are names that could never be registered, such as:
DNS resolvers generally have the ability to search for a name in one or more parent domains. For example, Unix's resolv.conf might look like this:
search a.com b.com server 127.0.0.1
Search lists are most important when the user (or application) requests a single-component name, like "www" or "gateway". In this case, the resolver looks for "www.a.com". If that fails, it looks for "www.b.com" and so on.
Now, if one of the search domains does not exist, the lookup is always successful and the search terminates.
Some resolvers may also use the search list for multi-component names, and they may even try the search list first. For example, if a user asks for "www.rmtl.com" the resolver might first make a query for "www.rmtl.com.a.com" and this will return an answer, instead of an error.
Domain name resolvers can be configured to query other databases if the DNS fails. These other databases include: NIS/NIS+, the /etc/hosts file, and NetBIOS. Now that a .com/.net lookup never fails, these other databases will never be queried.
Verifying an email message's "From" address is a popular way to detect spam. Email servers make DNS lookups (MX and/or A records) for the from address. If it does not resolve, the mail is rejected. For example:
reject=451 4.1.8 Domain of sender address martin@thethinkcap.com.ar does not resolve
This technique no longer works for com/net because of the wildcards. Thus, users are receiving more spam than before.
Real-time Blackhole Lists (RBLs) are another popular anti-spam technique. One such RBL, at dorkslayers.com, is now defunct but some mail server installations are still configured to use it. They are now blocking ALL email as spam because every lookup in the dorkslayers.com domain returns an (Verisign's) IP address.
previously, users received "instant" notification of mis-typed email addresses. The local mail server would refuse to send mail to a hostname that does not exist. Now, all domain names exist, so the message goes to Verisign and then bounces back to the user some time later.
An organization might have a "backup" (or primary) MX record pointing to a name that no longer exists. For example:
IN MX 5 mail.example.com.
IN MX 10 mail.iforgottodelete.netPreviously, the invalid MX host would be silently skipped. Now, however the bogus MX points to Verisign which returns a hard delivery failure that is not re-tried.
Similar to the MX problem above, some NS records may have names that no longer exist. Previously, a caching nameser would simply skip NS records that did not resolve. Now, the wildcard IP address is presumably being sent a constant stream of DNS queries that, we hope, will never be answered. Another wonderful data mining opportunity for Verisign, and we would never know if they are collecting or not.
Some operating systems have a "feature" that sets a NIC's IP address based on a hostname. If this hostname is a typo or unregistered, the user's host is assigned the IP address returned by Verisign's wildcard.
A university department hired an amateur administrator who set up their Active Directory domain with a bogus .com name. When the TLD wildcards were installed, users could not log in to their systems. In some cases it took more than 30 minutes before they were logged in. Previously, the non-existent domain resulted in an error that allowed the login to proceed quickly.
Perhaps the biggest threat to the Net's stability is that Verisign's move offends people. They feel cheated and violated. These people are more likely to use one or more of the anti-establishment root server systems available out there (see www.new.net, www.adns.net, www.opennic.unrated.net, www.alternic.org, www.pacificroot.com)
The technical community seems to disagree about whether wildcards have a negative impact on DNSSEC.
With wildcards, when I request https://a.com/ my browser reports:
Could not connect to host a.com
This makes me think "a.com" has a bug and forgot to start their server, rather than think that the hostname "a.com" is invalid.
I get a different error message if I visit https://a.org/, for example.
If Verisign accepted TCP connections on port 443, they could respond with an apparently valid SSL certificate. Said Steve Bellovin:
In the security world, we call this a man- (or monkey-)in-the-middle attack, for which the standard defense is crypto. But that doesn't work well when your trusted third party is part of the threat model...
Sites like netcraft may become confused. For example, see what happens when you ask netcraft about www.ooooooooooooooooooooooooooooooo.com. Since Verisign uses Apache, does it mean Apache's "market share" will suddenly increase?
Given a non-existant host/domain name, ping and traceroute try to do something useful. But ping never gets any answers and traceroute dies somewhere close to Verisign. To a novice user it looks like the host exists, but is down or having network problems.
You don't have to be Verisign in order to surreptitiously benefit from TLD wildcards. Anyone who has the ability to sniff network traffic can also mine the data. For example, I can find common domain name typos by picking out DNS replies with the wildcard IP address.