Understanding Trust Key Management for DNSSEC in PowerDNS Recursor

[ryhoofr]

Hello,

I am in the process of implementing DNSSEC on an Internet resolver using PowerDNS Recursor. I noticed in your documentation that you state you do not support RFC 5011, which concerns the automatic update of trust keys for DNSSEC.

However, when I activate DNSSEC on my resolver, it seems to work correctly and is able to validate the root servers of the Internet.

Could you explain how PowerDNS Recursor manages trust keys for DNSSEC without the support of RFC 5011? Does the resolver use another method to obtain and update trust keys?

; <<>> DiG XX <<>> @xx.xx.xx.xx iana.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58479
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;iana.org.                      IN      A

;; ANSWER SECTION:
iana.org.               3600    IN      A       192.0.43.8

;; Query time: 712 msec
;; SERVER: xx.xx.xx.xx#53(xx.xx.xx.xx) (UDP)
;; WHEN: Mon Jun 03 17:02:53 CEST 2024
;; MSG SIZE  rcvd: 53

The "ad" field for authentic data is indeed present.

Thank you in advance for your help.

Best regards,
Ryhoo

[Habbie]

The trust anchors for the root are shipped as part of:

• our git tree
• and thus, our source tarballs
• and thus, the packages we build for various distributions, and that various distributions build from our source tarballs
• and also, the Debian/Ubuntu dns-root-data package

You should also be aware that 5011 does not solve the problem of initial discovery; it only solves the problem of following the path from an old key to a new key while it is happening.

My personal opinion is that 5011 was a mistake and we should let other distribution methods handle the problem, just like we all do for the CA/WebPKI system.

[ryhoofr]

Thank you for your response. If I understand correctly, if I leave the configuration as is (docker), the keys will expire? So, it would be necessary to find an external method to retrieve the keys from a trusted source and install them? Then, I would need to restart pdns, is that correct? For instance, I could retrieve the keys from this link IANA Then, I could use the "readTrustAnchorsFromFile" option to use them?
Thank you again for your prompt response :-)

[mnordhoff]

If you leave a system completely alone with absolutely no updates, DNSSEC validation will start to fail after the next root KSK rollover, yes.

If you install routine updates to Recursor and your OS, the root keys should be updated along with everything else (though it's prudent to make sure).

Depending on your OS, the Recursor package may be set up to use readTrustAnchorsFromFile with the OS's packaged root keys by default.

[Habbie]

If you leave a system completely alone with absolutely no updates, DNSSEC validation will start to fail after the next root KSK rollover, yes.

and also, your software will go EOL, perhaps even before the KSK failure

[Habbie]

Depending on your OS, the Recursor package may be set up to use readTrustAnchorsFromFile with the OS's packaged root keys by default.

the Debian and Ubuntu packages do this. The docker image, while Debian based, does not currently do this.

[ryhoofr]

Thank you for your responses. Normally, we update our PDNS Recursor containers regularly, several times a year. However, I have also created a script that retrieves the KSKs from the IANA website and uses the dig trustanchor.server CH TXT command to get the key tag to check if it is about to expire. If that's the case, it triggers an alert.

[omoerbeek]

The root key lifecycle is very long. Once the new key data is released in 2025 by ICANN, we will start including the corresponding trust anchor (in addition to the existing one) in the recursor. It wil then take at least two years before the new key actually gets used.

https://www.icann.org/en/announcements/details/icann-to-generate-new-dns-cryptographic-key-at-april-2024-ceremony-28-02-2024-en