At Canonical, we are committed to enhancing security for our user base. We believe in providing a securely designed foundation that empowers our users, and sometimes, this means pushing the boundaries and testing new features. DNSSEC, a security extension for DNS, is one such feature that we are keen to make more accessible. Our goal was to enable it by default in Ubuntu 25.10 ‘Questing Quokka’ to provide a higher level of security with no user intervention.
Issues we discovered
However, the rollout in the development release of Ubuntu revealed some issues. The change, which involved installing the systemd-resolved-dnssec package by default, led to DNS failures for users leveraging LXD containers. The problem stemmed from a conflict between the DNSSEC validation and the dnsmasq server configured for LXD. Despite a fallback logic (DNSSEC=allow-downgrade), the validation errors broke name resolution for local domains, leaving containers without a properly working network connection [lxd].
Besides this, enabling DNSSEC by default had the potential to break name resolution on a distro level. We wanted to avoid any possible issues, even in specific environments where the upstream DNS servers are not fully behaving according to the specification. DNSSEC validation rejects DNS resource records, originating from a DNS resolver that indicates DNSSEC support through the EDNS0 “DNSSEC OK” (DO) flag [rfc3225], but at the same time does not properly respond to DNSSEC queries (e.g. missing “authenticated data” = AD flag or missing RRSIG or NSEC records).
The commitment to our users means we are ready to accept when an experiment doesn’t work as planned. We listened to the community feedback from the development release, reviewed the bug reports, and made the decision to roll back the change. The systemd-resolved-dnssec package was dropped, ensuring DNSSEC is no longer enabled by default [rollback]. This action restored stability for our user base, kudos to our systemd maintainer Nick Rosbrook (@enr0n ) for his analysis, support and quick action!
Upstream systemd developers performed a similar experiment 5 years ago and found issues with DNSSEC akin to the ones described above, especially when edge routers are involved, e.g. those provided by ISPs for home connectivity [upstream]. Unfortunately, many of those small upstream DNS servers still don’t support the DNSSEC specification and oftentimes define their own private DNS names (e.g. “fritz.box”), which cannot possibly be validated via any DNSSEC trust anchor, because they are local. The upstream DNS servers are outside of Ubuntu’s control and cannot be fixed from within the distribution, therefore DNSSEC can only be enabled in controlled environments for the foreseeable future, where the upstream DNS server is correctly configured to handle DNSSEC queries.
This does not mean we have given up on DNSSEC. In fact, we decided to make DNSSEC an opt-in feature for Ubuntu 25.10 Questing Quokka for those who want to test it and see if they can benefit. DNSSEC can easily be enabled, enhancing authenticity in supported environments.
How to enable DNSSEC
You can see if DNSSEC is enabled on your system by running resolvectl status. If it’s disabled, you’ll see DNSSEC=no. To enable DNSSEC without editing the main system file, create a new drop-in configuration in /etc/systemd/resolved.conf.d/10-dnssec.conf. The DNSSEC=yes option will enable strict validation, which blocks name resolution for unsigned domains. Once you’ve saved the file, you need to reload the systemd-resolved service to apply the changes.
$ sudo mkdir -p /etc/systemd/resolved.conf.d
$ sudo tee /etc/systemd/resolved.conf.d/10-dnssec.conf >/dev/null <<EOF
[Resolve]
DNSSEC=yes
EOF
$ sudo systemctl reload systemd-resolved.service
Documentation
The updated Ubuntu Server Documentation provides additional background information on how to enable and validate DNSSEC as an opt-in feature, empowering users to take further control of their security: DNS Security Extensions (DNSSEC)
In addition to the example above which explains how to enable DNSSEC in the base configuration, the documentation explains what DNSSEC is and which problems it solves, such as integrity and authenticity of name resolution. It provides a general overview of the supported DNS daemons that are available in Ubuntu and describes the new DNS Resource Records needed for DNSSEC, like RRSIG, DS or NSEC.
Finally, it presents ways to validate the correct functionality of a DNS resolver and shows common pitfalls (e.g. private domains in virtualization environments or custom domains by the local router), for users to confirm the security of their own systems. Users will also find further information, such as troubleshooting for DNS resolvers and standard DNSSEC functionality, in case something does work as expected.
Verdict
The outcome of this process is a testament to our open development model. We are not afraid to be transparent about our experiments, and more importantly, we are dedicated to course correcting when necessary. Local and end-to-end DNSSEC validation increases authenticity, without the need to trust any 3rd party. Enabling DNSSEC should be considered when used in a controlled environment (e.g. a datacenter or company network and workstations) or when using capable upstream DNSSEC enabled DNS-servers, such as Google-DNS, Cloudflare or Quad9 (amongst others).