DNSSEC-TRUST-ANCHORS.D(5)

🦋 DNSSEC-TRUST-ANCHORS.D — ok bestie come get ur trust anchors 💅

So like, this is the manual page for dnssec-trust-anchors.d (section 5 of the manuals, iykyk) — and it's also the page that covers systemd.positive and systemd.negative, which are literally just the two flavors of trust anchor config files. Yes queen, we're doing DNSSEC today. Sit down, hydrate, let's go. 🍓

---

✨ NAME ✨

dnssec-trust-anchors.d, systemd.positive, systemd.negative — the DNSSEC trust anchor configuration files. That's it, that's the name, no notes. 💖

---

🌸 SYNOPSIS 🌸

/etc/dnssec-trust-anchors.d/*.positive
/run/dnssec-trust-anchors.d/*.positive
/usr/local/lib/dnssec-trust-anchors.d/*.positive
/usr/lib/dnssec-trust-anchors.d/*.positive
/etc/dnssec-trust-anchors.d/*.negative
/run/dnssec-trust-anchors.d/*.negative
/usr/local/lib/dnssec-trust-anchors.d/*.negative
/usr/lib/dnssec-trust-anchors.d/*.negative

Look at all those paths. A whole buffet. 🫶

---

💫 DESCRIPTION 💫

Okay so the DNSSEC trust anchor configuration files are the ones that define positive and negative trust anchors — and systemd-resolved.service(8) is the one that bases all its DNSSEC integrity proofs on them. Main character service, honestly. 👑

---

🎀 POSITIVE TRUST ANCHORS 🎀

Positive trust anchor config files hold DNSKEY and DS resource record definitions, and those are what get used as the base for DNSSEC integrity proofs. If you wanna go deep, RFC 4035, Section 4.4[1] has the lore on DNSSEC trust anchors. 📚

Positive trust anchors get read from files with the .positive suffix, and they live in /etc/dnssec-trust-anchors.d/, /run/dnssec-trust-anchors.d/ and /usr/lib/dnssec-trust-anchors.d/. These directories get searched in that exact order, and a trust anchor file with the same name in an earlier path overrides a trust anchor file in a later path. So earlier wins, periodt. 💅

And listen — to disable a trust anchor file that shipped in /usr/lib/dnssec-trust-anchors.d/, all you gotta do is drop an identically-named file into /etc/dnssec-trust-anchors.d/ or /run/dnssec-trust-anchors.d/ that's either empty or a symlink to /dev/null. That's what "masked" means, bestie. It's giving stealth mode. 🙈

Positive trust anchor files are just simple text files that look like DNS zone files, as documented in RFC 1035, Section 5[2]. You can list one DS or DNSKEY resource record per line. Empty lines and lines that start with # or ; get ignored — that's your commenting situation. A DS resource record looks like this:

. IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5

Let's break it down because I know you wanna know. 🧚

• The first word specifies the domain — use . for the root domain. The domain can be written with or without a trailing dot, and those two are considered equivalent. No dot-shaming here.
• The second word must be IN.
• The third word must be DS.
• The words after that specify the key tag, signature algorithm, digest algorithm, and then the hex-encoded key fingerprint.
• For the precise syntax and meaning of these fields, see RFC 4034, Section 5[3].

Alternatively — plot twist — you can use DNSKEY resource records to define trust anchors, like so:

. IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

Decoding that:

• The first word specifies the domain again.
• The second word must be IN, followed by DNSKEY.
• The subsequent words encode the DNSKEY flags, protocol and algorithm fields, followed by the key data encoded in Base64.
• For the precise syntax and meaning of these fields, see RFC 4034, Section 2[4].

If multiple DS or DNSKEY records are defined for the same domain — and yes, that includes records spread across different trust anchor files — then all the keys are used and they're all considered equivalent as a base for DNSSEC proofs. Sharing is caring. 🌈

Heads up bestie: systemd-resolved will automatically use a built-in trust anchor key for the Internet root domain if no positive trust anchors are defined for the root domain. So in most cases you literally don't need to define an explicit key with trust anchor files. That built-in key gets disabled the moment at least one trust anchor key for the root domain is defined in trust anchor files. It's giving "I'll handle it until you say otherwise." 😌

It is generally recommended to encode trust anchors in DS resource records rather than DNSKEY resource records. That's the recommendation, I'm just the messenger. 💌

If a trust anchor specified via a DS record is found to be revoked, it is automatically removed from the trust anchor database for the runtime. See RFC 5011[5] for the details on revoked trust anchors. And ngl, important: systemd-resolved will not update its trust anchor database from DNS servers automatically. Instead, it's recommended that you update the resolver software, or add the new trust anchor via adding in new trust anchor files. Manual labor, unfortunately. 😭

The current DNSSEC trust anchor for the Internet's root domain is available at the IANA Trust Anchor and Keys[6] page. Go get it. 🏃‍♀️

---

💜 NEGATIVE TRUST ANCHORS 💜

Negative trust anchors define domains where DNSSEC validation shall be turned off. Not on my watch — except, okay, yes, actually on my watch, that's literally the point.

Negative trust anchor files are found at the same location as positive trust anchor files, and they follow the same overriding rules. They're text files with the .negative suffix. Empty lines, and lines whose first character is ;, are ignored. Each line specifies one domain name, which is the root of a DNS subtree where validation shall be disabled. For example:

# Reverse IPv4 mappings
10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
...
# Some custom domains
prod
stag

Negative trust anchors are useful for supporting private DNS subtrees that aren't referenced from the Internet DNS hierarchy and aren't signed. Your little private kingdom, unbothered. 👑

RFC 7646[7] for the details on negative trust anchors.

If no negative trust anchor files are configured, a built-in set of well-known private DNS zone domains is used as negative trust anchors. Default behavior, we love her. ✨

It's also possible to define per-interface negative trust anchors using the DNSSECNegativeTrustAnchors= setting in systemd.network(5) files. Fancy. 🎀

---

👀 SEE ALSO 👀

systemd(1), systemd-resolved.service(8), resolved.conf(5), systemd.network(5)

---

📎 NOTES 📎

1. RFC 4035, Section 4.4 https://tools.ietf.org/html/rfc4035#section-4.4
2. RFC 1035, Section 5 https://tools.ietf.org/html/rfc1035#section-5
3. RFC 4034, Section 5 https://tools.ietf.org/html/rfc4034#section-5
4. RFC 4034, Section 2 https://tools.ietf.org/html/rfc4034#section-2
5. RFC 5011 https://tools.ietf.org/html/rfc5011
6. IANA Trust Anchor and Keys https://data.iana.org/root-anchors/root-anchors.xml
7. RFC 7646 https://tools.ietf.org/html/rfc7646

---

k bye that's the whole page bestie 💖 this one's from systemd 262.1 — yes, systemd 262.1, that's the version, and it's the DNSSEC-TRUST-ANCHORS.D(5) page, so you already know where to find it again. go forth and validate responsibly, mwah 🫶✨