DNSKEY trust anchors fail DNSSEC validation while equivalent DS trust anchors work #44145

systemd version the issue has been seen with

255.4-1ubuntu8.17

Used distribution

Ubuntu 24.04

Linux kernel version used

7.1.0-seblu

CPU architectures issue was seen on

x86_64

Component

resolvectl, systemd-resolved

Expected behaviour you didn't see

DNSSEC validation should work with either DS or DNSKEY records configured as positive trust anchors.

When the root KSKs (key tags 20326 and 38696) are configured as DNSKEY trust anchors, systemd-resolved should be able to authenticate the root DNSKEY RRset, including the root ZSK (key tag 8763), and subsequently validate signed delegations such as .net.

Unexpected behaviour you saw

Following the root KSK rollover on October 11, 2026, DNSSEC resolution stopped working with DNSSEC=allow-downgrade.

The initially configured root trust anchors resulted in:

DNSSEC validation failed for question . IN DNSKEY: missing-key
DNSSEC validation failed for question net IN DS: missing-key

Explicitly configuring both root KSKs as DS trust anchors fixes the issue.

However, replacing those DS records with their equivalent DNSKEY records causes DNSSEC validation to fail again, despite both DNSKEY records being successfully loaded as positive trust anchors.

The failure occurs while validating net IN DS, which is signed by the root ZSK (key tag 8763).

Steps to reproduce the problem

1. Configure systemd-resolved with:

   [Resolve]
   DNSSEC=allow-downgrade

2. Create /etc/dnssec-trust-anchors.d/root.positive containing the current root DS trust anchors:

   . IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
   . IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
   

   These records are also provided by Ubuntu in /usr/share/dns/root.ds.

3. Restart the resolver and query a DNSSEC-signed domain:

   systemctl restart systemd-resolved
   resolvectl query seblu.net

   Result: DNS resolution works.

4. Replace the DS trust anchors with the equivalent DNSKEY trust anchors shipped by Ubuntu:

   cat /usr/share/dns/root.key 
   . IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ; keytag 20326
   . IN DNSKEY 257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc= ; keytag 38696
   cp /usr/share/dns/root.key /etc/dnssec-trust-anchors.d/root.positive
   systemctl restart systemd-resolved
   resolvectl query seblu.net

   Result: DNSSEC validation fails with missing-key.

   Both root KSKs (key tags 20326 and 38696) are correctly loaded as positive trust anchors, as confirmed by the systemd-resolved startup logs.

5. Restart and query again:

   systemctl restart systemd-resolved
   resolvectl log-level debug
   resolvectl flush-caches
   resolvectl query seblu.net

   Result: DNSSEC validation fails with missing-key.

6. Restore the DS records and restart systemd-resolved.

   Result: DNS resolution works again.

Additional program output to the terminal or log subsystem illustrating the issue

With DNSKEY trust anchors, both root KSKs (20326 and 38696) are correctly loaded:

Positive Trust Anchors:
. IN DNSKEY 257 3 RSASHA256 ...
        -- Flags: SEP ZONE_KEY
        -- Key tag: 20326
. IN DNSKEY 257 3 RSASHA256 ...
        -- Flags: SEP ZONE_KEY
        -- Key tag: 38696

DNSSEC validation then fails:

Requesting DNSKEY to validate transaction 1248 (seblu.net, RRSIG with key tag: 33302).
Requesting DNSKEY to validate transaction 64116 (seblu.net, RRSIG with key tag: 33302).
Requesting DS to validate transaction 59793 (seblu.net, DNSKEY with key tag: 33302).
Requesting DNSKEY to validate transaction 2723 (seblu.net, RRSIG with key tag: 7272).
Requesting DS to validate transaction 59791 (net, DNSKEY with key tag: 37331).
Requesting DS to validate transaction 59791 (net, DNSKEY with key tag: 3840).
Requesting DS to validate transaction 59791 (net, DNSKEY with key tag: 7272).
Requesting DNSKEY to validate transaction 56044 (net, RRSIG with key tag: 8763).
Validating response from transaction 56044 (net IN DS).
Looking at net IN DS 37331 13 2 2f0bec2d6f79dfbd1d08fd21a3af92d0e39a4b9ef1e3f4111fff282490da453b: missing-key
Found verdict for lookup net IN DS: indeterminate
DNSSEC validation failed for question net IN DS: missing-key
Auxiliary DNSSEC RR query failed validation: missing-key
DNSSEC validation failed for question net IN DNSKEY: missing-key
Auxiliary DNSSEC RR query failed validation: missing-key
DNSSEC validation failed for question seblu.net IN DS: missing-key
Auxiliary DNSSEC RR query failed validation: missing-key
DNSSEC validation failed for question seblu.net IN DNSKEY: missing-key
Auxiliary DNSSEC RR query failed validation: missing-key
DNSSEC validation failed for question seblu.net IN A: missing-key
Auxiliary DNSSEC RR query failed validation: missing-key
DNSSEC validation failed for question seblu.net IN AAAA: missing-key

Unlike with DS trust anchors, no transaction fetching . IN DNSKEY appears in the debug trace.

The issue appears related to how systemd-resolved handles DNSKEY trust anchors. It seems to skip fetching the complete root DNSKEY RRset, leaving the root ZSK (8763) unavailable for validating signed delegations.

A preliminary review of the upstream code suggests that the relevant logic has not significantly changed in the latest main branch, although this has not been tested.