DNS Security, Part VI: Blockchain-based Name Systems

Posted by ekr on 04 Feb 2022

This is Part VI of my series on DNS Security (parts I, II, III), IV, V). I thought I was done after talking about recursive to authoritative, but I then realized I wanted to cover blockchain-based name systems; these aren't strictly part of the DNS, but they're intended to fulfill a similar function, so it's worth covering them a bit.

DNS is a distributed system: name data is spread across multiple servers and resolving a given name requires asking those servers.^[1] Specifically, it is a hierarchical, federated system. In this case, federated means that different domains are controlled by different people and hierarchical means that domain example.com is subordinate to (and hence controlled by) .com, which is in turn subordinate to the root. This is easy to see if you work through the resolution process described in post I: if the root decides to lie to you about who owns a given domain, then you just get the wrong answer. This notion of trust is baked into DNSSEC, where each zone is signed by its parent: here too, any compromise of the root or of a parent domain leads to compromise of the child.

Government Takeover #

This structure has lead to a fair amount of complaining about the trustworthiness of the DNS. The conspiracy theory version of this is that the root is operated by the Internet Assigned Numbers Authority (IANA), which is part of the Internet Corporation for Assigned Names and Numbers (ICANN), which is a US corporation, and so the US government will take over the root and require it to misbehave (e.g., taking over people's names, signing false records, etc.). For instance, suppose that the US government decided that the Iranian TLD (.ir) shouldn't work any more. To my knowledge that has never happened—and for reasons covered below, I think it's kind of unlikely—though it's of course possible in principle.

What has happened, however, is that various governments have simply seized people's domain names. This isn't done by leaning on ICANN, however, but rather by serving the registrar or the registry with legal process. US Immigration and Customs Enforcement (ICE) does this, as does the FBI, with the typical thing to do to just be replace the web site with something like this:

Note that once you've taken over the site, you own the name and can put whatever on it. The typical practice seems to be to put the kind of warning label I show above, which is pretty obvious, but you could just as well build a replica of the site and continue to silently operate it —you can even get a valid TLS certificate—though this doesn't seem to be common.

A related concern is that many of the popular TLDs are actually owned by foreign countries who might not have the most friendly relationship with the jurisdiction that registrants are in. For example, .ly (as in the URL shortener https://bitly.com) is actually the Libyan TLD. If you have one of these domain names, you're obviously somewhat exposed to action by the parent jurisdiction.

Of course, it's somewhat of a semantic question whether this is actually an attack. Obviously, if you're the owner of airbags.com you might be unhappy about the government seizing your domain name, but it's not clear how different it is from just seizing your servers or your car; the government has plenty of processes for taking your stuff. The situation is somewhat different here in that so much of the infrastructure is in the US, and so people who don't live in the US are suddenly exposed to actions by the US government, but the situation isn't too dissimilar to what happens if you live outside the US but decide to store your money in a US bank and of course there certainly are plenty of TLDs that are operated by non-US entities.^[2].

As I said, despite fears to the contrary, I'm not aware of any case when the US has used its control of the root to take over a name. It's not even really clear how this would work because in order to take over example.com they would first need to take over all of .com and serve all the other records besides example.com normally. This seems like a lot of work and it's not really something you could do surreptitiously, as lots of people would notice that .com suddenly had a new DNS key and was being served from a new set of servers; it's much easier to just require the registry to change their records.

Again, I want to emphasize here that most of this isn't about attacking the technical infrastructure of the DNS. Rather, it's changing actual ownership relationships in the name hierarchy, as when the government seizes your car; the DNS just reflects those ownership relationships. In other words, this is the system faithfully publishing the official data as it is designed to do.

Filtering #

Even if you don't control the TLD for a domain name, it's comparatively easy to filter the DNS if you control the network. This is not so much because of the hierarchical structure of the name system but because of the fact that the name resolution tends to be controlled by the network. This means that if you control that resolver you can easily remove any names you don't like or (if DNSSEC is not in use) replace them with names of your own (see here).

This kind of filtering is fairly common. For instance, China's Internet filtering uses DNS blocking. It's also common practice in enterprise or school environments to block domains corresponding to material that the network operator thinks is contraband (often "adult" material). One of the impacts of encrypted DNS is to make this kind of blocking harder, especially if the device or software is configured to use an unfiltered resolver.

Name Ownership Disputes #

Finally, there are circumstances in which a domain can be involuntarily transferred from one party to another. One common case is where someone registers a domain name which corresponds to a trademark held by another entity. Suppose, for instance, that I register coca-co.la (which incidentally, seems to be unregistered) and started some business selling soda (EKR Cola!). The Coca Cola Company might be upset about this and their recourse is ICANN's Uniform Domain Dispute-Resolution Policy (UDRP) which allows them to file a complaint and potentially gain control of the name. The details are of course complicated, but here are some high points:

b. Evidence of Registration and Use in Bad Faith. For the purposes of Paragraph 4(a)(iii), the following circumstances, in particular but without limitation, if found by the Panel to be present, shall be evidence of the registration and use of a domain name in bad faith:

(i) circumstances indicating that you have registered or you have acquired the domain name primarily for the purpose of selling, renting, or otherwise transferring the domain name registration to the complainant who is the owner of the trademark or service mark or to a competitor of that complainant, for valuable consideration in excess of your documented out-of-pocket costs directly related to the domain name; or

(ii) you have registered the domain name in order to prevent the owner of the trademark or service mark from reflecting the mark in a corresponding domain name, provided that you have engaged in a pattern of such conduct; or

(iii) you have registered the domain name primarily for the purpose of disrupting the business of a competitor; or

(iv) by using the domain name, you have intentionally attempted to attract, for commercial gain, Internet users to your web site or other on-line location, by creating a likelihood of confusion with the complainant's mark as to the source, sponsorship, affiliation, or endorsement of your web site or location or of a product or service on your web site or location.

Name registration is frequently first come first served, and it's actually reasonably likely that you'd be able to register some domain name or another that was arguably infringing, as it's kind of a subjective judgment, but the UDRP allows the holder of the trademark to try to reclaim the name in these cases after the fact.^[3]

Note that here too, we're not talking about a technical process but rather a legal/policy one. The UDRP allows the trademark holder to argue that a certain domain name shouldn't have been registered and if they prevail, then the domain registration will be transferred or canceled. When that happens, the DNS gets changed to reflect the outcome of that process, but that's just publishing a decision which got made outside the DNS.

Blockchain/Ledger-Based Systems #

This brings us to the topic of alternative name systems based on ledgers, which are advertised as addressing these issues, especially censorship. Probably the two best known of these are the Ethereum Name Service and Namecoin. Here's Namecoin's description of its value proposition:

• Protect free-speech rights online by making the web more resistant to censorship.
• Attach identity information such as GPG and OTR keys and email, Bitcoin, and Bitmessage addresses to an identity of your choice.
• Human-meaningful Tor .onion domains.
• Decentralized TLS (HTTPS) certificate validation, backed by blockchain consensus.
• Access websites using the .bit top-level domain

What all this means will become clear below.

How to build a blockchain-based name system #

As with everything crypto, the details are fantastically complicated, but the idea is conceptually simple:^[4] The blockchain provides a decentralized append-only ledger. I'll probably describe how this works at some future point, but for now, this means it's a data structure which:

• Has a fixed order of operations
• (Mostly) anybody can write to it.
• You can only write to the end of it
• Everyone agrees on the contents
• Nobody can change anything that happened in the past^[5]

With a data structure like this, it's easy to build a simple first-come-first-served (FCFS) name system. You just write a record to the ledger consisting of (1) the name you want to register (2) your public key. E.g.,

{
    "domain-name":"example.com",
    "public-key":
     {"kty":"EC",
          "crv":"P-256",
          "x":"...",
          "y":"...",
          "use":"enc",
          "kid":"1"},
}

Public key borrowed from RFC7517.

As long as you're the first person to register a name, congratulations, you own it!^[6] Anyone can validate you own it just by looking through the entire ledger from the beginning (this may take some time) and seeing that you were the first person to register it. If someone tries to register it afterwards, then it's just ignored (whether it even makes it into the ledger or not is a detail, though an important one in practice). From this point on, things are pretty simple: once you've registered your public key you can just use it to sign ordinary DNSSEC records for your name and use DNSSEC for every name below you. Of course you also need some way to tell resolvers which authoritative server to go to to get those records, but this can be stuffed in the blockchain as well, or stuffed somewhere else and signed with your blockchain-based key.

You'll notice that above I've tried to register a domain in .com but actually this is bad news: if we have two mechanisms for registering names that are uncoordinated we're going to run into situations where some people see example.com as one thing and other people as another (RFC 2826 does a good job of laying this out). In practice, people who want to build their own naming systems tend to try to locate them in as-yet-unused portions of the DNS space: for instance, Namecoin uses .bit and ENS uses .ens.^[7]The idea here is that if you have a Namecoin-capable client you look at the top label and if it's .bit you use Namecoin and otherwise you use the DNS. Of course, these names are still notionally within the DNS and so there's actually nothing stopping ICANN from deciding tomorrow to mint a .bit domain, which would cause confusion. The general idea seems to be that once you get enough usage of your new TLD, ICANN will avoid creating it because it would cause too much trouble; it remains to be seen whether this is actually true.

It is technically possible to register a Special Use Domain Name (SUDN) that is outside of the DNS hierarchy, so one might imagine doing so for a new blockchain-based name system. The bar for this is quite high and the only top-level SUDN which has been registered for an alternative namespace is .onion (RFC 7686) for Tor's cryptographically-generated domain names. This registration was controversial at the time and in some sense sui generis because the names are cryptographically verified rather than looked up; for obvious reasons the IETF and ICANN are less excited about registering TLDs name resolution protocols which are conceptually similar to DNS but use different technical underpinnings.

Technical Properties #

With this under our belts, let's look at the technical properties of the system. For the purposes of this discussion, I'll be assuming that the ledger behaves as advertised; there are potential attacks on the ledgers but they're not so interesting here.

The main advertised advantage for blockchain-based systems is censorship resistance. The first thing that Namecoin lists as it's value proposition is "Protect free-speech rights online by making the web more resistant to censorship." Similarly, ENS advertises itself as "Launch censorship-resistant decentralized websites with ENS.". The answer to the question of whether these systems are more censorship resistant is "sort of". As we saw before, there are two primary ways to censor a domain name in the DNS (1) legally/administratively take over the domain itself (2) block the domain name resolution process. We need to look at these independently.

Domain Takeover #

How resistant this kind of system is to domain takeover depends on the name allocation and reassignment policy. The simple first-come-first-served system I described above really is more resistant to takeover by governments or by anybody else. The ledger enforces ordering and so there's just no external mechanism to transfer a name from someone to someone else. The system of course needs a mechanism to do transfers, but that's done by having the original owner sign the a transfer and that means you need the owner's private key, which the government or ICANN wouldn't have.

It's far from clear that these are actually good properties to have, for two reasons. First, if you lose your signing key you have effectively lost your domain, which seems like a terrifying prospect if you're the person in charge of cisco.bit. You certainly don't want to be like that guy who had 220 million dollars locked up in a Bitcoin wallet that you've lost the password for. Second, while it may seem like a good property that nobody can take your correctly registered domain away from you, it also means that if someone registers a domain for a trademark you own then you can't take it away from them, which is obviously less desirable. Given the importance of the UDRP for the existing domain name system, I have a hard time seeing most big company wanting to participate in that kind of a system, given the risk that they will be unable to protect their trademarks.

It's of course possible to build a system that allows for controlled involuntary transfers: you just have some group of people who can sign those transfers. It appears that this is what ENS has done, requiring four out of seven trusted people to change policies (see here) for a much more negative assessment of the ENS system), but then the censorship resistance benefits come down to how much you trust those people and especially how much you trust them not to be pressured by governments.^[8] The material that ENS has published here isn't very encouraging:

The root node is presently owned by a multisig contract, with keys held by trustworthy individuals in the Ethereum community. We expect that this will be hands-off, with the root ownership only used to effect administrative changes, such as the introduction of a new TLD, or to recover from an emergency such as a critical vulnerability in a TLD registrar.

The keyholders are drawn from respected members of the community, and with the exception of Nick Johnson, founder of ENS, are unaffiliated with ENS. We ask and expect them to exercise their individual judgement acting in the interests of the ENS community, rather than rubber-stamping requests made to them by ENS developers

This kind of ad hoc decision based on people being expected to act in the best interests of the community doesn't really seem sufficient to govern a name system which supports trillions of dollars of transactions.

Finally, it's worth noting that none of this means that your domain can't be taken away by legal process because that could potentially be used to force you to sign the transfer. In this case the system will duly publish that transfer as there's no real way for it to tell you signed it under duress). All the cryptographic machinery is really doing is making it hard for people who can't force you to do things to effectuate the transfer.

Filtering #

It's a bit hard to tell whether this kind of system is more resistant to filtering than ordinary DNS. At the moment, the answer is almost certainly "yes" because there is an established ecosystem devoted to filtering DNS and the blockchain-based name systems are too small to be worth filtering.

I don't think, however, that there is any real technical reason why these systems are more resistant to filtering. At the end of the day, the way these systems work is that you download a bunch of data from the ledger and then verify all the signatures. So what makes them filtering resistant is that the distribution mechanism for the blockchain data is peer to peer and also that you can layer them on top of some other system that is censorship resistant (e.g., download them from the Web or via a real anti-censorship system like Tor).

However, you can do precisely the same thing with DNS. First, if things are DNSSEC signed then they can just be passed around directly because DNSSEC chains are self-contained. And even for non-DNSSEC-signed domains, it's certainly possible to have some third party (e.g., Google public DNS) sign the data. So, as long as you have a censorship-resistant publishing mechanism—this is the hard part—DNS will be equally filtering resistant. Moreover, given that secure DNS transport mechanisms are already in common use, it seems like it's going to be a lot easier to make the DNS hard to filter than to deploy some entirely new naming system, especially given that much of the Internet will be running on DNS for years whatever new system is invented.

What about the rest? #

Let's just look quickly at the rest of the Namecoin value proposition. (I'm not trying to beat up on Namecoin here; mostly similar comments would apply to ENS or any of these systems.)

Attach identity information such as GPG and OTR keys and email, Bitcoin, and Bitmessage addresses to an identity of your choice #

This seems like a reasonable goal, but there's nothing special about a blockchain system that lets you do this. DNS already supports new record types and we've already seen how to attach cryptographic material to DNS; it's straightforward to add all of these record types as well. All you'd need is to want to do it.

Human-meaningful Tor .onion domains. #

This is kind of confusing until you read the FAQ. The situation is that .onion addresses are special because the address is actually the hash of a cryptographic key. With Namecoin you can register a pointer from a regular name to a .onion name. This is fine, but of course you can do it with DNS as well as long as the domain is DNSSEC signed.

Decentralized TLS (HTTPS) certificate validation, backed by blockchain consensus. #

There are two points here: first that you can have a TLSA record associated with your Namecoin domain. This is of course equally possible with ordinary DNS as well. The second point is just the one I made above, which is that the name registration is rooted in the blockchain not in the DNS hierarchy.

Access websites using the .bit top-level domain #

And this just means that you can use .bit instead of .com or whatever.

Summary #

At the end of the day, I don't really see much advantage to these blockchain/ledger-based systems. The primary value proposition is that they are censorship resistant. However, this property is provided by having them rigidly and mechanically enforce some policy, which seems more like a bug than a feature. Our existing name system depends on flexibility in order to function, both to save people from themselves (if they lose their key) and to save them from others (if people register your name in the DNS) and so a system that doesn't provide any discretion seems like a step backwards. It's of course possible to layer some kind of governance structure over top of such a system—this would of course have to be cryptographically reified—but that's not what we have now and at that point, it seems like you've reproduced the same discretionary properties of the DNS that motivate these systems.

Even if these systems do turn out to be technically superior, they face the same network effect challenges that we saw with TLSA: anyone can get a DNS name today and it will be acceptable to basically anyone else on the Internet. By contrast, if you register something in .bit then very few people will be able to see it, so you're most likely going to want to register both a DNS name and a .bit name, at which point the incentive to register the Namecoin name as well seems rather low.