DNS: January 2008 Archives

The reason that front running works at all is that WHOIS leaks the name of the domain you're looking to the WHOIS service operator and in this case the operator is the adversary, thus giving them an opportunity to get ahead of you. The usual answer to this problem is to create a set of policies that treat WHOIS queries as sensitive information (see ICANN's study on front running). One could, for instance, require the WHOIS operator to treat WHOIS queries as private.

However, there's a cheap, compatible, technical hack that substantially increases the difficulty of front running attacks without any new policies: allow WHOIS searches on hashes of domain names. The way this would work is that the WHOIS operator would create a parallel tree of phony domain name registrations in WHOIS. For instance, if I registered example.org, then they would also create an entry for SHA-1(example.org)=20116dfd6774a9e7b32eddfea3f6cb094e38fc3f.org (we might need to register a new TLD to make this work and guarantee no collisions) and populate it with the record for example.org. Then, I could locally compute the hash for each domain name I wanted to check on and easily verify its existence or nonexistence.

Other properties:

• The WHOIS server doesn't get the name being searched for, just the hash. It's in principle possible to iterate through all possible names to see what hashes match, but this isn't practical for any at all unusual name, and of course most obvious names have already been registered.
• The WHOIS protocol doesn't need to change: this looks like a valid domain name.
• It's easy to generate the records on the server side: just run some script over your WHOIS database.
• It's easy to enhance your WHOIS client to do the hash first, but even if you don't, command line hash programs are easy to get.
• Note that there is some chance of name collisions

You still might need ICANN or someone like them to force the operators to do this, since it's not clearly in their interest. On the other hand, direct cost to them is so low that it's hard to really object to on difficulty grounds.

Technical Note 1: This problem is related to private information retrieval but is dramatically easier because we don't care about the server knowing what record we fetched if it exists, only if it doesn't exist. Actually, we only care if the record exists. We don't need the record itself, which makes the problem yet easier.

Technical Note 2: It would be nice to have a solution that didn't allow dictionary attack. The best solutions I know use Bloom filters.

• The server can send you a Bloom filter with the names he knows. This is completely resistant to dictionary attack but is still of linear size in the number of inserted domain names per key. And, of course, there are false positive issues.
• The client can request the values of specific bits in a server-side Bloom filter. By asking for a superset of the bits you want you can get some dictionary attack resistance. This has much lower space requirements, but still leaks some information to the attacker—I haven't done the math on how much, but it clearly scales to some extent with the number of bits requested, with the limit being all of them.

Note that the hash solution isn't technically constant size in the number of registered names either—the required hash size for any given false negative probability depends on the number of registered names. However, since 160 bits is so small people just think of this as constant size.

Domain Name News reports that Network Solutions is engaging in front running of domain names—when a user uses WHOIS to check on the availability of the name, NSI grabs the domain:

A story is developing regarding domain name registrar Network Solutions front running domains. According to multiple sources on DomainState.com, it appears that domains searched via NSI are being purchased by the registrar thereby preventing a registrant from purchasing it at any other registrar other than NSI. As an example, a random domain which DNN searches such as HowDoesThisDomainTasteTaste.com can be seen in this whois search to now be unavailable to register at other registrars but at NSI it can be purchased

The whois contact now says :

    Registrant: Make this info private
    This Domain is available at NetworkSolutions.com
    13681 Sunrise Valley Drive, Suite 300
    HERNDON, VA 20171
    US

The domains are likely being purchased and held in NSI ownership until the potential registrant comes back to purchase the name through NSI. If the purchase is not made at NSI within 5 days, NSI uses the same 5 day grace period that domain tasting operations use and they delete the domain. Once a search for a domain is conducted at NSI the domain name is registered and only available to be purchased by a registrant at NSI. It is not clear if NSI has increased prices on domains that have received multiple whois searches and that they are front running.

Obviously, even if NSI isn't increasing prices, customers don't really want to be locked into NSI. NSI's defense? They're doing it to protect customers:

"I'd like to clarify what we are doing. In response to customer concerns about Domain Name Front Running (domains being registered by someone else just after they have conducted a domain name search), we have implemented a security measure to protect our customers. The measure will kick in when a customer searches for an available domain name at our website, but decides not to purchase the name immediately after conducting the search.

After the search ends, we will put the domain name on reserve. During this reservation period, the name is not active and we do not monetize the traffic on these domains. If a customer searches for the domain again during the next 4 days at networksolutions.com, the domain will be available to register. If the domain name is not purchased within 4 days, it will be released back to the registry and will be generally available for registration.

This protection measure provides our customers the opportunity to register domains they have previously searched without the fear that the name will be already taken through Front Running.

You are correct that we are trying to take an arrow out of the quiver of the tasters. As you know, domain tasters are the largest Front Runners. Due to no fault of registrars, Front Runners purchase search data from Internet Service Providers and/or registries and then taste those names. Some folks may not agree with our approach, but we are trying to prevent this malicious activity from impacting our customers."

I don't really understand how this is a defense against front running. Say that I search for example.com and I find it's not taken but I decide not to purchase it. Someone else is monitoring that whois and decides to purchase the name. WHOIS is unauthenticated, so they can buy it just as well as I can, they just have to go through NSI. I see how this is to NSI's benefit, but how is it to mine? I suppose one could argue that NSI is more expensive than other registrars, so forcing them to go through NSI sort of deters attackers, but that seems like a pretty crude instrument. Other than that, I don't see that this is a useful safeguard.