Authoritative DNS over IPv6 #341

Open
opened 2026-02-09 22:32:09 +01:00 by felixalb · 1 comment
Owner

We have been very good at maintaining feature parity between IPv4 and IPv6 for the absolute majority of services and hosts (except for #285), but there is at least one large gap: Authoritative DNS. This is politically important, and technically very easy to implement, but it might break backwards compatibility?

Note that this does not affect regular clients, as they can already use IPv6 to communicate with their DNS resolver of choice, that will in turn have to use IPv4 to talk to our NS in the backend.


Some history:

Traditionally, authoritative DNS has been done by dvask, who did not use IPv6 at all afaik (why? lacking support in the hardware nic? lacking support in software? I might have heard rumors that we disabled ipv6 when building the kernel to save on memory? ). For the past few years, ameno has been the temporary dvask-stand-in, it was set up in a hurry, with a plan to move back to dvask quite quickly. While ameno itself used IPv6 as well as IPv4, there has never been a AAAA record for "dvask.pvv.ntnu.no", so the resolver-to-ns communication has been over IPv4 only.

At this point, a lot of the DNS stack has been re-done and improved with new code generation and CI/CD, and both we and NTNU have quite good IPv6 support everywhere. If we add something like "dvask AAAA 2001:700:300:1900::211" to our zones, an IPv6-only DNS resolver/client can get the PVV zones, but we might not be able to go back to using dvask as our only NS without breaking some workflows.

One possible workaround is to keep the modern DNS server online when we resurrect dvask and use them in tandem, with the new one doing all the IPv6 work and dvask doing only most of the IPv4 work.


TLDR: Should the eventual plan to return to dvask stop us from adding IPv6 to our NS?

We have been very good at maintaining feature parity between IPv4 and IPv6 for the absolute majority of services and hosts (except for https://git.pvv.ntnu.no/Drift/issues/issues/285), but there is at least one large gap: Authoritative DNS. This is politically important, and technically very easy to implement, but it might break backwards compatibility? **Note** that this does not affect regular clients, as they can already use IPv6 to communicate with their DNS _resolver_ of choice, that will in turn have to use IPv4 to talk to our NS in the backend. --- Some history: Traditionally, authoritative DNS has been done by dvask, who did not use IPv6 at all afaik (why? lacking support in the hardware nic? lacking support in software? I might have heard rumors that we disabled ipv6 when building the kernel to save on memory? ). For the past few years, ameno has been the temporary dvask-stand-in, it was set up in a hurry, with a plan to move back to dvask quite quickly. While ameno itself used IPv6 as well as IPv4, there has never been a AAAA record for "dvask.pvv.ntnu.no", so the resolver-to-ns communication has been over IPv4 only. At this point, a lot of the DNS stack has been re-done and improved [with new code generation and CI/CD](https://git.pvv.ntnu.no/Drift/PVV-DNS/), and both we and NTNU have quite good IPv6 support everywhere. If we add something like "dvask AAAA 2001:700:300:1900::211" to our zones, an IPv6-only DNS resolver/client can get the PVV zones, but we might not be able to go back to using dvask as our only NS without breaking some workflows. One possible workaround is to keep the modern DNS server online when we resurrect dvask and use them in tandem, with the new one doing all the IPv6 work and dvask doing only most of the IPv4 work. --- **TLDR: Should the eventual plan to return to dvask stop us from adding IPv6 to our NS?**
felixalb added the questiondnsservers n' hardwarenetworking labels 2026-02-09 22:32:09 +01:00
felixalb self-assigned this 2026-02-09 22:32:09 +01:00
felixalb added this to the Kanban project 2026-02-09 22:32:09 +01:00
Owner

Worst case, we just have two machines hosting DNS if dvask only can take the IPv4 job, no? Probably fine.

Worst case, we just have two machines hosting DNS if dvask only can take the IPv4 job, no? Probably fine.
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Drift/issues#341