1DNSSEC-TRUST-ANCHORS.D(5) dnssec-trust-anchors.d DNSSEC-TRUST-ANCHORS.D(5)
2
6 dnssec-trust-anchors.d, systemd.positive, systemd.negative - DNSSEC
7 trust anchor configuration files
8
10 /etc/dnssec-trust-anchors.d/*.positive
11 /run/dnssec-trust-anchors.d/*.positive
13 /usr/lib/dnssec-trust-anchors.d/*.positive
15 /etc/dnssec-trust-anchors.d/*.negative
17 /run/dnssec-trust-anchors.d/*.negative
19 /usr/lib/dnssec-trust-anchors.d/*.negative
21
23 The DNSSEC trust anchor configuration files define positive and
24 negative trust anchors systemd-resolved.service(8) bases DNSSEC
25 integrity proofs on.
26
28 Positive trust anchor configuration files contain DNSKEY and DS
29 resource record definitions to use as base for DNSSEC integrity proofs.
30 See RFC 4035, Section 4.4[1] for more information about DNSSEC trust
31 anchors.
32 Positive trust anchors are read from files with the suffix .positive
34 located in /etc/dnssec-trust-anchors.d/, /run/dnssec-trust-anchors.d/
35 and /usr/lib/dnssec-trust-anchors.d/. These directories are searched in
36 the specified order, and a trust anchor file of the same name in an
37 earlier path overrides a trust anchor files in a later path. To disable
38 a trust anchor file shipped in /usr/lib/dnssec-trust-anchors.d/ it is
39 sufficient to provide an identically-named file in
40 /etc/dnssec-trust-anchors.d/ or /run/dnssec-trust-anchors.d/ that is
41 either empty or a symlink to /dev/null ("masked").
42 Positive trust anchor files are simple text files resembling DNS zone
44 files, as documented in RFC 1035, Section 5[2]. One DS or DNSKEY
45 resource record may be listed per line. Empty lines and lines starting
46 with a semicolon (";") are ignored and considered comments. A DS
47 resource record is specified like in the following example:
48 . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
50 The first word specifies the domain, use "." for the root domain. The
52 domain may be specified with or without trailing dot, which is
53 considered equivalent. The second word must be "IN" the third word
54 "DS". The following words specify the key tag, signature algorithm,
55 digest algorithm, followed by the hex-encoded key fingerprint. See RFC
56 4034, Section 5[3] for details about the precise syntax and meaning of
57 these fields.
58 Alternatively, DNSKEY resource records may be used to define trust
60 anchors, like in the following example:
61 . IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
63 The first word specifies the domain again, the second word must be
65 "IN", followed by "DNSKEY". The subsequent words encode the DNSKEY
66 flags, protocol and algorithm fields, followed by the key data encoded
67 in Base64. See RFC 4034, Section 2[4] for details about the precise
68 syntax and meaning of these fields.
69 If multiple DS or DNSKEY records are defined for the same domain
71 (possibly even in different trust anchor files), all keys are used and
72 are considered equivalent as base for DNSSEC proofs.
73 Note that systemd-resolved will automatically use a built-in trust
75 anchor key for the Internet root domain if no positive trust anchors
76 are defined for the root domain. In most cases it is hence unnecessary
77 to define an explicit key with trust anchor files. The built-in key is
78 disabled as soon as at least one trust anchor key for the root domain
79 is defined in trust anchor files.
80 It is generally recommended to encode trust anchors in DS resource
82 records, rather than DNSKEY resource records.
83 If a trust anchor specified via a DS record is found revoked it is
85 automatically removed from the trust anchor database for the runtime.
86 See RFC 5011[5] for details about revoked trust anchors. Note that
87 systemd-resolved will not update its trust anchor database from DNS
88 servers automatically. Instead, it is recommended to update the
89 resolver software or update the new trust anchor via adding in new
90 trust anchor files.
91 The current DNSSEC trust anchor for the Internet's root domain is
93 available at the IANA Trust Anchor and Keys[6] page.
94
96 Negative trust anchors define domains where DNSSEC validation shall be
97 turned off. Negative trust anchor files are found at the same location
98 as positive trust anchor files, and follow the same overriding rules.
99 They are text files with the .negative suffix. Empty lines and lines
100 whose first character is ";" are ignored. Each line specifies one
101 domain name which is the root of a DNS subtree where validation shall
102 be disabled.
103 Negative trust anchors are useful to support private DNS subtrees that
105 are not referenced from the Internet DNS hierarchy, and not signed.
106 RFC 7646[7] for details on negative trust anchors.
108 If no negative trust anchor files are configured a built-in set of
110 well-known private DNS zone domains is used as negative trust anchors.
111 It is also possibly to define per-interface negative trust anchors
113 using the DNSSECNegativeTrustAnchors= setting in systemd.network(5)
114 files.
115
117 systemd(1), systemd-resolved.service(8), resolved.conf(5),
118 systemd.network(5)
119
121 1. RFC 4035, Section 4.4
122 https://tools.ietf.org/html/rfc4035#section-4.4
123 2. RFC 1035, Section 5
125 https://tools.ietf.org/html/rfc1035#section-5
126 3. RFC 4034, Section 5
128 https://tools.ietf.org/html/rfc4034#section-5
129 4. RFC 4034, Section 2
131 https://tools.ietf.org/html/rfc4034#section-2
132 5. RFC 5011
134 https://tools.ietf.org/html/rfc5011
135 6. IANA Trust Anchor and Keys
137 https://data.iana.org/root-anchors/root-anchors.xml
138 7. RFC 7646
140 https://tools.ietf.org/html/rfc7646
141systemd 245 DNSSEC-TRUST-ANCHORS.D(5)