On a current Fedora server, /etc/resolv.conf is a symlink, and the one nameserver in it is 127.0.0.53 (an address that looks like a typing error and is in fact the whole design). Behind it sits systemd-resolved, which caches what it learns and passes everything else to the servers it was given. Ask it how careful it is, with resolvectl status, and it answers in two words: DNSSEC setting: no.
Nobody forgot to switch it on. Fedora wrote the decision down in 2020, in the change that made systemd-resolved its default for Fedora 33, and the paragraph is unusually candid: "We anticipate that enabling DNSSEC by default will not be possible in the foreseeable future, or perhaps ever."
The habit
systemd-resolved earns its place, and the Fedora change says why. It caches, and it gives every network link its own DNS servers, so a company VPN receives only the questions about the company's own names and the rest of the traffic stops leaking to the wrong place. resolvectl query shows where an answer came from. Ubuntu made it the default in 16.10, and Fedora followed with release 33 in 2020.
DNSSEC is the part of DNS that lets a resolver check, along a chain of signatures reaching up to the root zone, that an answer really came from the owner of the name. systemd-resolved can do that, and upstream builds it to try: the build option default-dnssec defaults to allow-downgrade. Its own manual explains the word. Validation "is attempted, but if the server does not support DNSSEC properly, DNSSEC mode is automatically disabled", and the next sentence is spot on about the cost: "this mode makes DNSSEC validation vulnerable to "downgrade" attacks, where an attacker might be able to trigger a downgrade to non-DNSSEC mode by synthesizing a DNS response that suggests DNSSEC was not supported."
The distributions went a step further and switched it off themselves. I read their build files this morning, 10 November 2026. Fedora's systemd.spec for systemd 262.2 passes -Ddefault-dnssec=no. In 2020 the same Fedora change had expected DNS over TLS to arrive "in the near future"; the next line of the spec reads -Ddefault-dns-over-tls=no. Debian's debian/rules passes -Ddefault-dnssec=no as well, and Ubuntu's packaging for 26.04 has carried the same line since Ubuntu 17.04. Red Hat Enterprise Linux 9 lists systemd-resolved as an unsupported Technology Preview and leaves the matter to whoever enables it.
The reason is a real one. Ubuntu's bug report of 2017 says that DNSSEC in systemd-resolved "prevents network access in certain intra and extra net cases", and Fedora pointed to access points that mangle DNS. A distribution that validates by default receives the bug reports of every hotel router and every badly signed company zone, and Fedora said plainly that it was "not prepared to handle an influx of DNSSEC-related bug reports". So the habit on a Linux server today is a resolver that caches well and believes what it is told.
The same job on FreeBSD
On FreeBSD 15.0 the job is one line in /etc/rc.conf and one command:
local_unbound_enable="YES"service local_unbound startThe installer offers the same thing as a tick box, under the description "Local caching validating resolver".
Whether it checks can be asked at the prompt. drill, the lookup tool that came into the base system with the same library, requests DNSSEC with -D:
drill -D example.comRFC 4035 allows a resolver to set the flag ad, for authenticated data, only when it "considers all RRsets in the Answer and Authority sections of the response to be authentic". example.com is signed, Unbound has followed the signatures from the root down to it, and the flags line of the answer includes ad. Every lookup on the machine passes the same check, whether or not the program that made it ever looks at the flag.
What the start does is worth reading, because the script that does it is short. On the first start, /etc/rc.d/local_unbound runs local-unbound-setup, written by Dag-Erling Smørgrav in 2013. It takes the nameservers from /etc/resolv.conf as forwarders, or lets Unbound resolve from the root itself when there are none ("Forwarding disabled, unbound will recurse"). It writes a configuration that runs the daemon as its own user in a chroot and sets auto-trust-anchor-file, so the root zone's key is fetched by unbound-anchor and then tracked with the probes of RFC 5011 as the root rolls its keys. Finally it points resolv.conf at 127.0.0.1 and tells resolvconf to feed new upstream servers into Unbound's own list of forwarders and to leave resolv.conf alone. After that every program on the machine asks a validating resolver, and nothing else.
That last step was deliberate. When FreeBSD 10 replaced BIND with Unbound, Smørgrav gave DNSSEC as one of the two reasons, since it "requires a caching DNSSEC-aware resolver both for performance reasons (DNSSEC validation is time-consuming) and to avoid having to implement DNSSEC validation in the libc resolver". And he closed the side door in the same breath: resolvconf was "blocked from updating /etc/resolv.conf to avoid failing over from the DNSSEC-aware local resolver to a potentially non-DNSSEC-aware remote resolver in the event of a request returning an invalid record". In 2013, then, FreeBSD ruled out by design the very fallback that allow-downgrade performs on purpose.
Unbound holds the same line inside the daemon. FreeBSD 15.0 ships Unbound 1.24.1, and its manual sets harden-dnssec-stripped to yes by default: a zone that should be signed and arrives without its signatures "becomes bogus", and the application is told that the lookup failed, so the forgery never reaches it. The same paragraph warns that turning the option off means you "run the risk of a downgrade attack that disables security for a zone", which is the sentence systemd's manual prints under allow-downgrade, seen from the other side.
The resolver also arrived with a library that the rest of the base system uses. Unbound needs LDNS, and FreeBSD's OpenSSH is built against the same LDNS (getrrsetbyname-ldns.c in secure/lib/libssh), so ssh can check a server's key fingerprint in an SSHFP record and trust it when the local validator vouches for it. The validator and the SSH client came out of one tree, and each of them knows the other is there.
The difference
Like for Like Fedora, Debian, Ubuntu FreeBSD 15.0
systemd-resolved local_unbound
DNSSEC as shipped no validating
Upstream default allow-downgrade harden-dnssec-stripped: yes
Signatures stripped answer delivered zone marked bogus
Fallback to a resolver allowed (allow-downgrade) blocked since 2013
that does not validate
Root key built into the program fetched, tracked by RFC 5011
Switching it on a drop-in, DNSSEC=yes local_unbound_enable="YES"Both systems switch their resolver's behaviour with one line, so the effort is a wash. The difference lies in what the line means and who answers for it. On Fedora the administrator who writes DNSSEC=yes overrules a decision the distribution took on purpose, and inherits the bug reports the distribution declined. On FreeBSD the administrator turns on a resolver whose validation the project chose in 2013 and has shipped in every release since 10.0.
The limit
The laptop is resolved's home ground. A machine that moves between hotel Wi-Fi and two VPNs in a day profits from resolved's per-link servers, and FreeBSD has no single command for that. Unbound handles the VPN case with a forward-zone for the company's domain in /var/unbound/conf.d, and the hotel portal with a minute of patience. The piece is about servers, where the network stays put for years.
Strict validation breaks broken zones. A badly signed domain stops resolving through local_unbound, which is the purpose of validation and occasionally a nuisance. Unbound's answer is a named exception, domain-insecure: "example.com", for the one zone that needs it, while every other zone keeps its check.
FreeBSD also waits for the administrator. local_unbound is off until rc.conf or the installer says otherwise. Once it is on, validation needs no further word.
Unbound runs on Linux as well. Fedora and Debian package it, and an administrator can put it in front of everything. Then it is that administrator's resolver, kept by hand, and it shares the machine with a systemd-resolved that still wants 127.0.0.53. On FreeBSD the job is sorted by the release itself.
A resolver that agrees to stop checking whenever someone asks it nicely is, in the end, a cache with good manners.