Update docs around DNSSEC #345
Conversation
…with bind9 Validating Resolver and sytemd-resolved local stub resolver
| ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 | ||
| ``` | ||
|
|
||
| Should authenticity of DNS records be a concern to you, it's advised to override the default DNSSEC validation settings through an additional drop-in configuration in `/etc/systemd/resolved.conf.d/10-dnssec.conf`, which would reject any unsigned records, after reloading the configuration: |
There was a problem hiding this comment.
The reject any unsigned records part is a bit misleading as that's not what DNSSEC=yes does. It insists on valid signatures for records that are supposed to be signed. Domains not signed remain resolvable.
There was a problem hiding this comment.
I agree that this needs clarification. The manpage uses the expression "support DNSSEC properly", and that leaves a lot of room for interpretation, both in the context of documentation, but also in what the correct response of the service is. For the "yes" value, it says "If the DNS server does not properly support DNSSEC all validations will fail.".
Similarly, the "allow-downgrade" option also uses the "support DNSSEC properly" expression.
I guess the behavior we all want is: if records are signed on the server, we want that signature to be valid, and reject if not. If records are not signed (or not supposed to be signed), then we won't require a signature.
And finally, there might be systems out there that definitely want to only deal with signed records, and reject any DNS response that is not authenticated. Is that what "yes" means here?
explanation/dnssec/dnssec.md
Outdated
|
|
||
| In general, local DNSSEC validation is only required in more specific secure environments. | ||
| In general, local DNSSEC validation is still the most secure approach, validating the records end-to-end, without the need to trust any DNS server along the way. |
There was a problem hiding this comment.
Since systemd-resolved supports DoT, it might be worth adding a quick note that this could also be used to secure the resolver <-> client path if the resolver is trusted.
There was a problem hiding this comment.
This is a generic note, so we could even mention DoH, too. As both DoT and DoH could be used to increase privacy.
explanation/dnssec/dnssec.md
Outdated
| $ systemctl reload systemd-resolved.service | ||
| ``` | ||
| ```{warning} | ||
| Be aware that enforcing DNSSEC can lead to errors like `DNS_PROBE_FINISHED_NXDOMAIN` in your browser, especially for local, unsigned domains and you would only be able to reach such services by accessing them through their IP address directly. |
There was a problem hiding this comment.
Why single out the browser? You could get errors everywhere, no?
explanation/dnssec/dnssec.md
Outdated
| * https://wander.science/projects/dns/dnssec-resolver-test/ | ||
|
|
||
| ```{note} | ||
| In case of issues with Domain Name resolution, make sure to remove any drop-in configs for **systemd-resolved**, execute `systemctl reload systemd-resolved.service` and `apt remove systemd-resolved-dnssec`. This will reset any DNSSEC configuration to `DNSSEC=no` and can be confirmed by executing `resolvectl dnssec`. |
There was a problem hiding this comment.
There could also be drop-in configs for resolved.conf, right?
There was a problem hiding this comment.
Isn't it easier to also, or perhaps instead of, instruct to remove the systemd-resolved-dnssec package?
There was a problem hiding this comment.
In fact, those are only drop-ins for resolved.conf.
And I need to re-phrase this whole section, as the systemd-resolved-dnssec package is now gone again.
Description
As of Ubuntu 25.10, we're shipping the
systemd-resolved-dnssecpackage, enabling local DNSSEC in systemd-resolved by default (still in fallback mode). Update the DNSSEC docs around that change in default configuration, better separation of remote validating resolvers & local stub resolvers, and extend it wrt. troubleshooting of local DNSSEC validation.Related Issue
SD-2170
Contributor License Agreement (CLA)
By contributing to this project, you agree to the terms of
the Canonical Contributor License Agreement (CLA).
If you have not already signed the CLA, please do so here.
Commit Message for Squash Merge
Checklist
Additional Notes (Optional)
N/A