That time Verisign typo-squatted all of .com and .net

That time Verisign typo-squatted all of .com and .net

A little over 20 years ago, Verisign did something mighty evil: they effectively typosquatted every single unregistered domain in the .com and .net top-level domains. They could do this because they controlled those from the registry side of things, and it was trivial to slam something that would make it resolve.

Reactions from people like me who had systems to run and spam to block were swift and universally negative due to all of the collateral damage it caused. Here's one situation it created: sometimes you'd have a user who thought they were being clever, and they'd put something like "nospam" in the from address in their e-mail client. Thus, they'd try to send mail as [email protected] instead of just @example.com.

Before Verisign pulled that crap, the mail servers of the day would have just rejected it as an invalid domain that didn't resolve (in DNS). Once it was online, it WOULD resolve, and so the mail system would accept it. Utter chaos.

Or, how about all of the random people who would mistype something? Instead of getting a failure to resolve error from their browser and/or organization's web proxy, it would just pop out to that stupid Verisign site.

It should surprise nobody that a bunch of us sour sysadmin types did things about it rather quickly over the next day or so. I still have the snippet of cruft to drop into a sendmail.cf in my notes from back then. I got this from Usenet, apparently:

Local_check_mail
R$*                     $: $>canonify $1
R$*<@$*.>               $: $1<@$2> strip the trailing . if present
R$*<@$+>                $: $(verisign $2 $)
R64.94.110.11           $#error $: "550 Real domain name required for sender address"

Incidentally, if any of you can still parse that syntax in your heads just by reading it, I'm so sorry. Take it from me - that ability does go away eventually, but you have to stop supplying it with new data.

Anyway, what that did was to exploit the limitless programmability of sendmail's config language to resolve the supplied domain. If it came back to 64.94.110.11, it would reject it right then and there. That was the IP address they were using for their little marketdroid-fueled fever dream, and I bet there are *still* systems blocking it 20 years later (and they probably have no idea why).

Over the next couple of days, a bunch of other things happened. ISC wrote a "delegation-only" feature for BIND (aka named, the occasional remote sudo implementation). You could use this to say that the "com." or "net." zones were only allowed to provide delegation to other zones. That is, within the bailiwick of "com.", it could say that "example.com." has a nameserver at <foo> with IP address <bar>, but that's it. It couldn't come right out and say that something had an A record outright.

Now, this worked great, but it wouldn't have been terribly difficult for them to sidestep it. They could have had it delegate all of those things down to some other level which then would have had a blanket answer for any incoming questions. Fortunately, this did not happen.

This whole bout of stupidity lasted about three weeks, and then it disappeared. They've never done it again, but plenty of other providers of recursive resolver action have pulled it since then as a matter of course. Screw up the way DNS works in order to fellate the advertisers? Brilliant!

Remember this? That was 2019.

I find it strangely fulfilling that this event has garnered a Wikipedia article in the years since. Hopefully people will never forget what happened back in 2003 with the DNS.