DNS traffic encryption is all the rage, with standardisation, software and deployment advancing. But root server operators are questioning encryption for traffic going up to their servers. In a joint public statement of 31 March they declared they would not introduce encryption for the 13 root servers at this point in time. We asked the operators of root servers I and K, Lars-Johan Liman from Swedish operator Netnod and Kaveh Ranjibar from Ripe NCC, why root operators do not want to secure DNS queries by encryption.
CENTR: People have been complaining that the DNS is a security weak protocol for some time. Now that encryption mechanisms have been added, the root operators say they do not want to be early adopters of encrypting the traffic for that last hop in the DNS hierarchy. Can you please explain why root operators feel this way?
Lars: Root server operators have a common understanding of their main priorities and responsibilities. Stability and accessibility rank highest alongside accuracy of data. We want to continue to be seen as a stable foundation of the internet system as a whole. When you introduce change to a system, there is always a risk of instability if you do not have a full understanding of the consequences. The DNS is a system with so many bits and pieces working together that it is impossible to foresee the consequences for the whole system.
We want to deploy encryption step by step, monitoring changes introduced in other parts of the DNS system where possible problems would have a smaller impact. This way, the DNS community as a whole can learn more about the effects before we introduce changes to the root servers where the effects might be considerable. We do not want to be at the forefront of this deployment.
CENTR: Kaveh, you’ve participated in the root operator discussions. How does it actually work?
Kaveh: There are thirteen identifiers managed by twelve organisations, who are all independent. Every one of the twelve root server operators read the 31 March statement we are talking about and agreed to it, making it our joint statement. But just to be clear I can’t speak now for all 12 organisations. I may sound formalistic, but our mutual independence is part of the power of the root system.
CENTR: Oh, could an independent root operator decide to try encrypting traffic on its own?
Kaveh: Definitely. It is one hundred percent within our operational remit. But why my organisation does not implement encryption, even though it provides security, is that the root zone file is a publicly accessible file. We have a broader view of security where we broadcast the zone file, making it more accessible. Accessibility is also a security feature, since we want to make sure that people who ask us questions get actual answers.
We also care about the integrity of the zone file. We prove this with cryptographic signatures. This is to make sure that the answer we give is correct.
Now let’s talk about request encryption. Normally we receive queries which cannot be answered from the middle players in the DNS hierarchy. If a DNS resolver at an ISP cannot answer where a .com, .org or .eu domain lies, the question is referred to us. By design we receive the full DNS query which includes the name of the TLD, the domain and potentially subdomains. There is now standardisation work in the IETF to reduce what we as root server operators and everybody else in the chain sees. Namely, data minimisation with respect to giving a meaningful and correct answer to a query.
CENTR: QName minimization…
Kaveh: Exactly, ask for .org instead of its.myserver.org. That seems pretty simple. But if we consider also DNSSEC, a DNS security feature that authenticates who owns a domain, it becomes more complex.
CENTR: Lars, would you also reserve the right to experiment with encryption?
Lars: We try very hard not to experiment with the root services. The typical way to introduce new things is to do them gradually. One root server operator at a time. We did so with DNSSEC and with IPv6.
Kaveh: And anycast….
CENTR: Has anyone in the group of 12 already expressed interest in becoming the first to try root traffic encryption?
Lars: For me that is the natural next step. But it is further down the line. I suppose that it is what is going to happen when the DNS community as a whole has more experience with DNS encryption. It should come after we have seen the effects it has in the other parts of the DNS tree, after potential bugs have been ironed out and after we are confident that it works the way it is supposed to.
CENTR: In the published statement you mention that new protocols create new risks, can you speak about some of the risks and trade-offs that slowed you down?
Lars: The biggest risk is always the unknown. Take DNSSEC as an example. The first generation of secure DNS was designed in the late 1990s. We first played around with that in test facilities to see how it worked. Then we got together with a large group of DNS experts and realized that yes, this design is secure and has the security properties we want it to have. But it is totally unusable.
It was impossible to administer it, but it is just too cumbersome, and we had to change the protocol to make it usable in day-to-day operations. And today it works. Our original design had no security problem, and no issue with traffic load. Only the administration made it fall and that could be the case here too. New software could have bugs that need to be ironed out. A bug that makes you receive an avalanche of questions for example. That is why you need to test gradually and to slowly expand the set of queries. We are probably also going to see a need to change the various tools we work with, for instance in cyberattack mitigation.
CENTR: What kind of attacks?
Lars: DDOS might be an issue. The less information the query contains, the more difficult it is for our tools to adapt to it.
CENTR: In the statement the root server operators write that future steps also depend on the transport chosen, and there are several options out in drafts or RFCs. How will the choice for DNS over Quic or DNS over TLS impact the next steps for the root?
Lars: I foresee that implementers will choose different solutions and we will have multiple methods. The root server operators need to be prepared to at least deal with TLS queries and Quic queries. Again, we want to see deployment in other places first, and build trust in the technologies before we gradually roll out changes over the root zone operators.
CENTR: What is the role of DNS over HTTPS in the picture?
Lars: DNS over HTTPS is a different beast to me. It will create a totally different set of challenges. We are going to see DNS queries go to different resolvers, depending on the application. So your web browser will go to one resolver to have its DNS names resolved, whilst your phone application or calendar will go to a different one. It will allow various organisations who want to influence the user in their daily internet to use a new tool. I do not know what will happen there, but it does not directly affect the root server operators. I think we are heading for a new internet and to me personally that is not a good development.
Kaveh: As root operators we deal with a wide variety of distributed systems. Some of those we serve send us tens of millions of queries a day, and then there are millions of other unique IP addresses with very low numbers of queries. At the root we deal with everyone. But generally top layer providers kind of dictate change and propagate it downwards.
If you look at the top five DNS software providers, nothing comes to us as a big surprise. As I see it, change comes from the top resolvers, propagates down to DNS software developers, and then to us. Our job is to make sure we are open enough that when change is demanded from stakeholders we can serve it.
CENTR: Lars, Kaveh, thank you very much.
***
This article is part of our RIPE 82 reporting.
