Talk:DNSSEC
easy way: systemd-resolved supports DNSSEC
IIUIC it is fairly easy to use DNSSEC system-wide via systemd-resolved.service. One has to use a DNS server which supports DNSSEC of course (like 8.8.8.8 or 9.9.9.9 [1]) and set DNSSEC to "true" or "allow-downgrade". resolved.conf(5) describes the DNSSEC option.
It can be configured globally in /etc/systemd/resolved.conf or per link if using Systemd-networkd in the corresponding /etc/systemd/network/*.network files.
By default, systemd-resolved.service does also DNS caching, which is useful when using DNSSEC because of the additional lookup delay.
Possible caveats:
- From resolved.conf(5): "In effect, when the built-in trust anchor is revoked and DNSSEC= is true, all further lookups will fail, as it cannot be proved anymore whether lookups are correctly signed, or validly unsigned." So keep your system up-to-date ;)
- There are three ways for dealing with
/etc/resolv.conf. If one wants system-wide DNSSEC validation, one should probably opt for the first option, since the second and third one expose the configured DNS servers via/etc/resolv.confto clients which may bypass any local DNS API.
I'm still learing about DNS/DNSSEC and I'm not sure if the above is correct or I missed something. But from my understanding it should work and would fit very well into DNSSEC.
—This unsigned comment is by Mearon (talk) 17:15, 16 November 2017. Please sign your posts with ~~~~!
Testing section is misleading
Currently in the #Testing section the user is instructed to try drill -DT {sigok,sigfail}.verteiltesysteme.net for "testing" purposes, but I don't think these are useful tests.
What I mean is: drill -DT does all the queries and validation itself, so these tests only serve to verify that the sigok and sigfail domains have the DNSSEC configuration they are reported to have. They test nothing about the user's resolver. It looks like in previous versions of this page that was more clear, but now it is not.
Depending on the intended purpose of this section, it should probably either:
1. Inform the user they should substitute the domains(s) they actually want to validate the DNSSEC configuration of.
2. Supply alternative instructions that test the user's locally configured resolver's DNSSEC behavior.
3. Link to instructions like (2) in the relevant sections of pages for different setups i.e resolved/dnsmasq/unbound etc.
4. Be removed.