Disable DNSSEC Validation Safely for a Private systemd-resolved Zone

You will configure a narrow DNSSEC negative trust anchor for an unsigned private DNS zone, then check that systemd-resolved is using the resolver configuration you expect. This is useful when a private zone is served by your own DNS infrastructure and cannot be authenticated through the public DNS hierarchy. Allow about fifteen minutes. You need root access to create the configuration file and a running systemd-resolved service.

The examples use systemd 255.4-1ubuntu8.17, whose installed manual page describes systemd.negative(5). A negative trust anchor turns DNSSEC validation off for the named domain and everything below it. It does not make the answers trustworthy, and it must not be used as a general fix for broken public DNSSEC.

1. Check the resolver before changing it

Use ordinary, read-only commands to establish which resolver is active and whether DNSSEC is currently available:

$ systemctl is-active systemd-resolved
active
$ resolvectl status
Global
         Protocols: ... DNSSEC=no/unsupported

Your output will differ. The useful checks are that the service is active and that resolvectl can display its global and per-link state. On the reference machine DNSSEC is unavailable because the configured DNS servers do not provide it, so adding a negative trust anchor cannot make validation appear. The setting matters when DNSSEC is enabled for the relevant link or globally.

Checkpoint: write down the exact private zone name, such as corp.example.test. Do not enter a public parent domain unless you deliberately intend to disable validation for that whole subtree.

2. Choose the configuration location

Negative trust anchor files use the .negative suffix and are read from these directories, in this order:

/etc/dnssec-trust-anchors.d/
/run/dnssec-trust-anchors.d/
/usr/lib/dnssec-trust-anchors.d/

A file in an earlier directory overrides a file with the same name in a later directory. Files supplied by a package belong under /usr/lib. Local administrator configuration belongs under /etc, while /run is appropriate for temporary, generated state. The examples use /etc so the exception survives a reboot and remains visible in the normal configuration tree.

Creating a negative trust anchor is security-sensitive: it deliberately removes an authentication check. Before continuing, confirm that the private zone is operated by people you trust and that its DNS server path is protected in some other way. Keep the exception as specific as possible.

3. Create one narrowly scoped negative trust anchor

Become root for the directory and file operation. Replace corp.example.test with the zone that really needs the exception:

$ sudo install -d -m 0755 /etc/dnssec-trust-anchors.d
$ printf '%s\n' 'corp.example.test' | sudo tee /etc/dnssec-trust-anchors.d/corp.negative
corp.example.test

Each non-empty line names the root of a DNS subtree where validation is disabled. A line beginning with ; is a comment. The manual's examples also show # comments, but its prose specifically guarantees that empty lines and semicolon-prefixed lines are ignored; use semicolons when you want the documented comment form. Do not add a trailing wildcard or a leading dot to the domain.

Inspect the result without changing it:

$ sudo sed -n 'l' /etc/dnssec-trust-anchors.d/corp.negative
corp.example.test$

The dollar sign shown by sed -n 'l' marks the end of the line. If you entered a parent zone by mistake, stop here and correct the file before asking the resolver to reload it.

4. Apply the change to systemd-resolved

Ask the service to reload its configuration:

$ sudo systemctl reload systemd-resolved
$ systemctl is-active systemd-resolved
active

The reload should not stop the service. If your unit does not support reload, the safe recovery path is to read the unit's status and journal before deciding whether a restart is necessary:

$ systemctl status --no-pager systemd-resolved
$ journalctl -u systemd-resolved -n 50 --no-pager

Do not restart a production resolver automatically just because a lookup still fails. A failed lookup can be caused by routing, the upstream server, the zone data or the network link rather than by DNSSEC.

5. Verify the scope and the lookup path

Review the active resolver state again, then query a name inside and outside the exception:

$ resolvectl status
$ resolvectl query host.corp.example.test
$ resolvectl query www.example.org

resolvectl status shows resolver state, not a complete list of file contents, so it is not by itself proof that every line in a trust-anchor file was accepted. The important operational check is that the private name reaches the intended DNS server and that unrelated public names still follow the normal resolver policy. Query output varies with your zone and upstream servers; do not treat a particular address as a universal expected result.

If the private lookup still fails, inspect the file name, permissions and exact domain first:

$ sudo ls -l /etc/dnssec-trust-anchors.d/corp.negative
$ sudo cat -A /etc/dnssec-trust-anchors.d/corp.negative
$ resolvectl status

Also confirm that DNSSEC is actually enabled for the interface serving the query. A negative trust anchor only changes authentication requirements. It does not add a DNS server, route a query to a link, create records or repair an unsigned zone's availability.

6. Undo the exception when it is no longer needed

Removing the file restores the previous configuration, but deletion changes resolver security policy. First preserve a copy if you may need to audit or restore the decision:

$ sudo cp --preserve=all /etc/dnssec-trust-anchors.d/corp.negative /root/corp.negative.backup
$ sudo rm /etc/dnssec-trust-anchors.d/corp.negative
$ sudo systemctl reload systemd-resolved

The backup is outside the resolver's configuration directory and is not active. Restore it with sudo cp --preserve=all /root/corp.negative.backup /etc/dnssec-trust-anchors.d/corp.negative if the exception was removed prematurely, then reload again. Do not leave duplicate files with different names while troubleshooting; that makes the effective policy harder to audit.

Per-interface alternative

A file under /etc/dnssec-trust-anchors.d is a system-wide exception for the resolver's trust-anchor database. If only one network interface should receive the exception, use DNSSECNegativeTrustAnchors= in that interface's systemd.network(5) file instead. Its value is a space-separated list of domains, and it applies to lookups made via that interface's DNS server when DNSSEC is enabled.

That alternative changes network configuration and may affect link management, so follow the existing .network file's deployment process. Do not add a second global file as a way to compensate for an uncertain per-interface setting.