Disable DNSSEC for One Private DNS Zone

A negative trust anchor tells systemd-resolved to stop demanding DNSSEC proof for one named zone. That matters for a private zone served by your own DNS, since it can never be authenticated through the public 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). Turning this on disables validation for the named domain and everything below it. It does not make the answers trustworthy, and it must never be reached for as a general fix when public DNSSEC is broken.

1. Check the resolver before changing it

Use ordinary, read-only commands to see which resolver is active and whether DNSSEC is even available right now:

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

Your output will differ. What matters is that the service is active and resolvectl can show 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 there cannot make validation appear from nowhere. The setting only matters once DNSSEC is enabled for the relevant link or globally.

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 same-named file in a later one. Package-supplied files belong under /usr/lib, local administrator configuration belongs under /etc, and /run suits temporary, generated state. The examples use /etc so the exception survives a reboot and stays visible in the normal configuration tree.

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

3. Create one narrowly scoped negative trust anchor

Become root for the directory and file operation. Replace corp.example.test with the zone that genuinely 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 switched off. A line starting with ; is a comment. The manual's examples also show # comments, but its prose specifically guarantees only that empty lines and semicolon-prefixed lines are ignored, so use semicolons if you want the documented comment form. Do not add a trailing wildcard or a leading dot to the domain.

Inspect the result without touching it:

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

That dollar sign from sed -n 'l' marks the end of the line. If you typed a parent zone by mistake, stop here and fix 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

A reload should not stop the service. If your unit does not support reload, the safer recovery path is reading its status and journal before deciding a restart is actually necessary:

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

Do not restart a production resolver on reflex just because a lookup still fails. A failed lookup can just as easily be routing, the upstream server, the zone data or the network link, not DNSSEC at all.

5. Verify the scope and the lookup path

Check 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 listing of file contents, so it is not by itself proof every line in a trust-anchor file was accepted. What actually matters operationally is that the private name reaches the intended DNS server while unrelated public names still follow normal resolver policy. Query output varies with your zone and upstream servers, so do not treat any particular address as a universal expected result.

If the private lookup still fails, check 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 DNSSEC is actually enabled for the interface serving the query. A negative trust anchor only changes authentication requirements: it adds no DNS server, routes no query to a link, creates no records, and repairs nothing about an unsigned zone's availability.

6. Undo the exception when it is no longer needed

Removing the file restores the previous configuration, but deletion is itself a resolver security policy change. Keep a copy first in case you need to audit or restore the decision later:

$ 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

That backup sits 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 you removed the exception prematurely, then reload again. Do not leave duplicate files under different names while you troubleshoot; that only 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 get the exception, use DNSSECNegativeTrustAnchors= in that interface's systemd.network(5) file instead. Its value is a space-separated list of domains, applied to lookups made via that interface's DNS server when DNSSEC is enabled there.

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