#1150960 all DNSSEC-enabled resolvers must depend on dns-root-data

#1150960#5
Date:
2026-10-15 09:28:09 UTC
From:
To:
DNSSEC-enabled DNS resolvers must depend on the dns-root-data package
instead of shipping built-in trust anchors.
The dns-root-data is a trivial, arch:all package whose only purpose is
to provide a current DNS root zone and DNSSEC trust anchors, even for
end of support Debian releases.

Short summary for people who are not familiar with DNSSEC: domains
resolution will stop working if the trust anchors are not up to date.
There is a mechanism (RFC 5011) to update them automatically in band,
but it requires that the resolver was working *before* the rollover.

Due to complex reasons (pandemic, end of life HSMs...) only three root
zone KSKs have been deployed so far[1] since 2010, the most recent one
last Sunday, but the current IANA plan[1] is to rotate the root KSK
every 3 years.  This means that this failure will be much more frequent
in the future.

Most important DNS resolvers already depend on dns-root-data: bind9,
pdns-recursor, knot-resolver6.
Some important DNS resolvers only recommend dns-root-data: unbound,
dnsmasq-base.
Only one important DNS resolver does not use dns-root-data (but AFAICT
could with just a symlink): systemd-resolved.

Embarrassing failures:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1150730
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2170538

[1] https://www.iana.org/dnssec/files
[2] https://www.icann.org/en/system/files/files/proposal-future-rz-ksk-rollovers-01nov19-en.pdf

#1150960#10
Date:
2026-10-15 09:50:20 UTC
From:
To:
Marco d'Itri [15/Oct 11:28am +02] wrote:

Sounds reasonable, patches welcome please.

#1150960#15
Date:
2026-10-17 16:33:20 UTC
From:
To:
I thought about this for unbound resolver.  And decided not to go with
a strong dependency but with a recommends instead.  The thing is: for
unbound in particular, these files are just a hint which gets copied
to an unbound dir, and there, unbound keeps it current by its own.
So the package - dns-root-data - is not used and not needed after
install.

Additionally, unbound itself ships a copy of root anchor, - this too
can be used by a non-default configuration when not enabling the
root-auto-trust-anchor-file.conf snippet.  The default config relies
on dns-root-data files at least initially present, but it is not
mandatory.

I don't think it's viable to disable root anchor embedded in the
upstream unbound sources.

If the decision is "must" I can change this dependency from Recommends
to Depends for sure, but for now I don't see a reason to.

Thanks,

/mjt

#1150960#20
Date:
2026-10-21 09:18:58 UTC
From:
To:
Hello,

unbound actually fails to startup on both bookwork and trixie, when
installing without recommends:

This is on a fresh bookworm install after a "apt-get install unbound":

Oct 21 08:26:44 debian-4gb-hel1-1 systemd[1]: Starting unbound.service
- Unbound DNS server...
Oct 21 08:26:44 debian-4gb-hel1-1 unbound[1032]: [1032:0] notice: init
module 0: subnetcache
Oct 21 08:26:44 debian-4gb-hel1-1 unbound[1032]: [1032:0] notice: init
module 1: validator
Oct 21 08:26:44 debian-4gb-hel1-1 unbound[1032]: [1032:0] error:
unable to open /var/lib/unbound/root.key for reading: No such file or
directory
Oct 21 08:26:44 debian-4gb-hel1-1 unbound[1032]: [1032:0] error: error
reading auto-trust-anchor-file: /var/lib/unbound/root.key
Oct 21 08:26:44 debian-4gb-hel1-1 unbound[1032]: [1032:0] error:
validator: error in trustanchors config
Oct 21 08:26:44 debian-4gb-hel1-1 unbound[1032]: [1032:0] error:
validator: could not apply configuration settings.
Oct 21 08:26:44 debian-4gb-hel1-1 unbound[1032]: [1032:0] error:
module init for module validator failed
Oct 21 08:26:44 debian-4gb-hel1-1 unbound[1032]: [1032:0] fatal error:
failed to setup modules
Oct 21 08:26:44 debian-4gb-hel1-1 systemd[1]: unbound.service: Main
process exited, code=exited, status=1/FAILURE
Oct 21 08:26:44 debian-4gb-hel1-1 systemd[1]: unbound.service: Failed
with result 'exit-code'.
Oct 21 08:26:44 debian-4gb-hel1-1 systemd[1]: Failed to start
unbound.service - Unbound DNS server.
Oct 21 08:26:44 debian-4gb-hel1-1 systemd[1]: unbound.service:
Scheduled restart job, restart counter is at 5.
Oct 21 08:26:44 debian-4gb-hel1-1 systemd[1]: Stopped unbound.service
- Unbound DNS server.
Oct 21 08:26:44 debian-4gb-hel1-1 systemd[1]: unbound.service: Start
request repeated too quickly.
Oct 21 08:26:44 debian-4gb-hel1-1 systemd[1]: unbound.service: Failed
with result 'exit-code'.
Oct 21 08:26:44 debian-4gb-hel1-1 systemd[1]: Failed to start
unbound.service - Unbound DNS server.


This is on a fresh trixie install after a "apt-get install unbound":

Oct 21 08:41:38 debian-4gb-hel1-1 systemd[1]: Starting unbound.service
- Unbound DNS server...
Oct 21 08:41:38 debian-4gb-hel1-1 unbound[1405]: [1405:0] notice: init
module 0: validator
Oct 21 08:41:38 debian-4gb-hel1-1 unbound[1405]: [1405:0] error:
unable to open /var/lib/unbound/root.key for reading: No such file or
directory
Oct 21 08:41:38 debian-4gb-hel1-1 unbound[1405]: [1405:0] error: error
reading auto-trust-anchor-file: /var/lib/unbound/root.key
Oct 21 08:41:38 debian-4gb-hel1-1 unbound[1405]: [1405:0] error:
validator: error in trustanchors config
Oct 21 08:41:38 debian-4gb-hel1-1 unbound[1405]: [1405:0] error:
validator: could not apply configuration settings.
Oct 21 08:41:38 debian-4gb-hel1-1 unbound[1405]: [1405:0] error:
module init for module validator failed
Oct 21 08:41:38 debian-4gb-hel1-1 unbound[1405]: [1405:0] fatal error:
failed to init modules
Oct 21 08:41:38 debian-4gb-hel1-1 systemd[1]: unbound.service: Main
process exited, code=exited, status=1/FAILURE
Oct 21 08:41:39 debian-4gb-hel1-1 systemd[1]: unbound.service: Failed
with result 'exit-code'.
Oct 21 08:41:39 debian-4gb-hel1-1 systemd[1]: Failed to start
unbound.service - Unbound DNS server.
Oct 21 08:41:39 debian-4gb-hel1-1 systemd[1]: unbound.service:
Scheduled restart job, restart counter is at 5.
Oct 21 08:41:39 debian-4gb-hel1-1 systemd[1]: unbound.service: Start
request repeated too quickly.
Oct 21 08:41:39 debian-4gb-hel1-1 systemd[1]: unbound.service: Failed
with result 'exit-code'.
Oct 21 08:41:39 debian-4gb-hel1-1 systemd[1]: Failed to start
unbound.service - Unbound DNS server.


So for this reason alone I think dns-root-data should be a strong dependency.

I do agree that when dns-root-data data is only *copied* *during
install*,it  is less useful for future updates. It would need symbolic
links and maybe restart triggers instead. I don't know what the best
way to achieve this is.


Regards,
Lukas

#1150960#25
Date:
2026-10-21 09:40:50 UTC
From:
To:
Yes I know. Exactly as I wrote before, -- dns-root-data is needed only
for the first start, when its file is copied to unbound dir.  It is not
used anymore after the first startup, - it is used only as initial seed,
unbound keeps it updated internally.

  > So for this reason alone I think dns-root-data should be a strong dependency.

yeah, I had a bug about this already.

I'll think about it more.

Note that unbound itself has built-in copy of the root key, and effectively
I force-replace it with dns-root-data.

Thanks,

/mjt