Discussed since the 1990s, the Domain Name System Security Extensions (DNSSEC) add authenticity to DNS records. To understand the current state of DNSSEC deployment, we interviewed Ulrich Wisser, who works at the Swedish Internet Foundation, a CENTR member that operates the .se top-level domain. We also discuss an Internet Draft co-authored by Ulrich Wisser that proposes an algorithm and a protocol to automate operations for multi-signer DNSSEC. The text has been edited for brevity and clarity.
GG:. DNSSEC adoption in the world still remains lower than what most people anticipated. What do you think has impeded the deployment of DNSSEC?
UW: The tooling available for authoritative DNS servers has been quite bad. However, over the last decade, it has improved to a point where DNSSEC is now a yes/no option in domain configuration.
On the resolver side, we often hear that resolving could fail with DNSSEC. But, in Sweden, even the largest ISPs in Sweden can’t even recall one instance where they had to disable DNSSEC for a domain.
One of the biggest problems with DNSSEC adoption remains the one that almost all security technology faces: customers do not ask for it. Domain sellers are in a low-margin business, so they will not spend money on anything they believe is unnecessary. This is understandable, but frustrating nevertheless.
GG: You mentioned on the DNS operations mailing list at the IETF that .se has high DNSSEC penetration (approx. 50%), and that all major ISPs support it. Some estimates put it even higher. Regardless of the precise figure, Sweden’s adoption of DNSSEC is impressive compared to the world, and to Europe in particular as well. What are the steps Sweden has taken to achieve such high DNSSEC adoption?
UW: The Swedish Internet Foundation places incentives to drive change. Our registrars, which are also the biggest hosting companies, get a 5% cost reduction for signed domains. This isn’t much per domain (approximately €0.60), but if you sign 100k domains, it starts to add up.
Additionally, we run a community of ISPs, hosting companies, registrars, and DNS enthusiasts where we exchange the latest in DNS, but also try to help each other if anything goes wrong.
GG: Encrypted DNS protocols like DNS over HTTPS and DNS over TLS are rising in popularity. Of course, they only support in-flight authenticity and confidentiality, perhaps deliberately so to achieve a more modular design. However, that does mean that they do nothing to solve the problem that unvalidated DNS records are often used: public resolvers using these protocols could still be sending unsigned records. Do you view the development of DoT and DoH as missed opportunities for promoting DNSSEC or do you feel it's better that they aimed at a separate part of the puzzle?
UW: DoH and DoT primarily target privacy, whereas DNSSEC primarily targets data accuracy. However, what I find strange is that trusted resolver rules of browsers (eg. Mozilla’s program) have a long list of requirements, but DNSSEC (data accuracy) isn’t one of them. A resolver I trust must support both. And, hopefully soon they will take up recursive to authoritative DNS with encryption too.
GG: You recently co-authored an Internet Draft, DNSSEC automation, and presented it at the DNS Operations working group at IETF110. Could you describe the motivation for it?
UW: As the registry for .se, we only interoperate with registrars, and do not have direct contact to registrants. If the registrar is also the name server operator, then there are usually no issues. For a domain, if the registrar is not the name server operator, registrants have to somehow get DNSSEC data to their registrar. And that is a problem. Additionally, even if the registrar is the name server operator, a registrant will have to go through complex operations if they want to change to another registrar (and the name server operator too), or risk going insecure, i.e. temporarily without DNSSEC.
Now, at .se we have decided that we want to become the first 100% signed ccTLD. One of the challenges is that changing the name server operator is really complex. So, we were looking for a solution when Steve Crocker and Shumon Huque came along with their project to automate Multi-Signer DNSSEC. It turns out that changing one’s name server operator is a special use-case of Multi-Signer DNSSEC.
What we are actually trying to do is to describe the algorithms on how to initialize and unwind a Multi-Signer setup, and how to roll keys or algorithms. The next steps will be creating a description on how to do this manually with current name server software, then describing an API that would be needed for automation, and finally describing a protocol for fully automating the process of changing the necessary information between name servers.
With the help of CDS/CDNSKEY and CSYNC, nothing has to be communicated out of band. Specifically, no DNSSEC information has to be forwarded by the registrant.
GG: Ah, so there are other use cases of multi-signer DNSSEC setups?
UW: For instance, one would need a full multi-signer setup when they want to use several large DNS providers. Let’s say you are running a large cluster of machines that get started and stopped all the time. You make use of DNS to reach these machines and therefore you publish their names in the DNS. For operational security, you do not run your own DNS but rely on a large DNS provider like Dyn or CIRA. For even higher fault tolerance, you may want to use both. Each operator will use their own keys for signing, and consequently you have the need for a multi-signer setup.
Our own use case, i.e. changing of name server operator, can be considered a special case of this. You want to change name servers and also who controls the DNSSEC keys of the domain. The old operator will not release the private key and neither will the new operator. In that scenario, we have to join both operators in a multi-signer setup and then the old operator has to leave the multi-signer setup.
GG: Ah, transitioning to a multi-signer set up is indeed a nifty way to change name server operators. How has been your experience with implementing this?
UW: We actually tried to get some running code, but it turned out that name servers are currently ill equipped to handle this setup. We tried to add additional DNSKEY records to a zone with dynamic updates, but that failed miserably. Just adding additional keys through the command line turned out to be an adventure. We actually had to use our support contracts with vendors to get it right.
CDS/CDNSKEY are often automated, which means a name server will not publish a CDS/CDNSKEY record for a key it doesn’t know about. But, that is actually needed for a multi-signer setup.
So, currently we have a somewhat-tested version of the needed algorithms. Our collaboration with deSEC gave a first working API that allows publishing additional keys, CDS/DNSKEY sync records.
Soon, we will have guides for manual operations of PowerDNS. And we hope to start a conversation with other software implementers on support for this.
GG: Ulrich, thanks for the detailed explanation, your time for this interview, and the great work at the IETF!
***
This article was written for CENTR by Gurshabad Grover, a technologist and legal researcher based in Bangalore, India, where he is Senior Researcher at the Centre for Internet and Society. His writing focuses on network security, privacy and censorship.
