The 4 Big Takeaways from DNS-OARC 45 in Stockholm
This article was written by Aman Grewal, Staff Engineer at Atakama
The other week, I had the chance to go to the DNS-OARC conference (OARC 45) in beautiful Stockholm. It was a fun time being able to talk with so many smart people about interesting DNS topics. Here are some takeaways I learned from my time in Sweden.
1) It's always DNS.
This is an oft-repeated saying, and only somewhat tongue-in-cheek. Because DNS is so low-level and fundamental to many other protocols, tiny degradations to DNS are acutely felt. As a result of this, DNS Operators frequently alert techs for issues in other systems even before those techs get any of their own alerts. I was discussing this with another attendee, and I had noticed this trend. He responded that he was awakened at 5 AM that morning because there was a "DNS issue". It turns out the issue was with a misconfigured mail server, but as we all know, it's always DNS.
2) Deployments are hard.
This is a universal truth. No matter the scale of the company or the amount of resources they have available, extensive testing and slow rollouts are still the two most important factors for stable deployments. Even with sufficient tests, issues slip through the cracks. For example, see these slides by Dejan Donin from Cisco https://indico.dns-oarc.net/event/55/contributions/1178/attachments/1130/2373/oarc 45_slides%20_v2.pdf. Despite extensive testing, they experienced DDoS attacks from unexpected vectors, and now they have many more tests to ensure it doesn't happen again. Sometimes, even when you do everything right, you still can't win. Take these slides by Klaus Darilion from nic. at https://indico.dns- oarc.net/event/55/contributions/1188/attachments/1125/2364/202 5-10-08%20DNS%20OARC%2045%20Anycast%20DNS%20Local%20 Nodes%20and%20Routing%20Problems%20due%20to%20Asym metric%20Routing%20on%20Internet%20Exchanges.pdf , and see all the hoops they jump through to make sure they handle responses correctly in spite of other entities' infrastructure issues.
3) Optimization is hard, but cheaper than you think.
DNS is extremely latency-sensitive. There's an impetus to have as many servers as possible in as many geographic regions as possible. But the research performed by Thijs van den Hout from Sidn Labs https://indico.dns-oarc.net/event/55/contributions/1189/attachments/1123/2360/202 51008_Autocast_OARC.pdf shows that the return rate diminishes much more quickly than expected. Of course, his research was specifically for his needs, but the methodology is impressive and quite cheap to reproduce for different needs.
4) DNS is not a stagnant system.
DNS is an old protocol. It was built at a time when the concept of internet security wasn't at the forefront of protocol designers' minds. Slowly, security measures have been added on top of the DNS protocol—all while maintaining backward compatibility and avoiding performance penalties, with the main ones being DNSSEC and alternate transport protocols. On the subject of DNSSEC, there was an interesting talk about post-quantum cryptography (PQC) presented by Joe Harvey from Verisign Labs https://indico.dns-oarc.net/event/55/contributions/1181/attachments/1136/2377/Post- Quantum%20Diversity%20for%20DNSSEC%20OARC%2045.pdf Even though there's still plenty of time before needing to implement PQC, it's important to know how to account for the performance aspects (both bandwidth and CPU) well ahead of the switchover. While there were no presentations on alternate transport protocols, there were many conversations around it. Protocols such as DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) are already in place from clients to recursive resolvers, so now the next step is securing the connections from the recursive resolvers to the authoritative name servers. This includes both upgrading old-school DNS (Do53) to use DoT or similar and upgrading DoT to authenticated DoT (ADot).
Overall, the conference was useful and productive. Everyone faces the same underlying problems, regardless of the size or age of the organization, and despite each organization having its own set of concerns and values, everyone is vested in making this chaotic distributed system work smoothly for all internet users.