From 4160043a0fac8b812905b7502ce34adf3af538f1 Mon Sep 17 00:00:00 2001 From: Luke Shumaker Date: Tue, 6 Sep 2016 02:27:18 -0400 Subject: move man pages to appropriate directories --- .../systemd-resolved/dnssec-trust-anchors.d.xml | 200 +++++++++++++++++++ src/grp-resolve/systemd-resolved/resolved.conf.xml | 219 +++++++++++++++++++++ .../systemd-resolved/systemd-resolved.service.xml | 163 +++++++++++++++ 3 files changed, 582 insertions(+) create mode 100644 src/grp-resolve/systemd-resolved/dnssec-trust-anchors.d.xml create mode 100644 src/grp-resolve/systemd-resolved/resolved.conf.xml create mode 100644 src/grp-resolve/systemd-resolved/systemd-resolved.service.xml (limited to 'src/grp-resolve/systemd-resolved') diff --git a/src/grp-resolve/systemd-resolved/dnssec-trust-anchors.d.xml b/src/grp-resolve/systemd-resolved/dnssec-trust-anchors.d.xml new file mode 100644 index 0000000000..4bdc167f79 --- /dev/null +++ b/src/grp-resolve/systemd-resolved/dnssec-trust-anchors.d.xml @@ -0,0 +1,200 @@ + + + + + + + + dnssec-trust-anchors.d + systemd + + + + Developer + Lennart + Poettering + lennart@poettering.net + + + + + + dnssec-trust-anchors.d + 5 + + + + dnssec-trust-anchors.d + systemd.positive + systemd.negative + DNSSEC trust anchor configuration files + + + + /etc/dnssec-trust-anchors.d/*.positive + /run/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/lib/dnssec-trust-anchors.d/*.negative + + + + Description + + The DNSSEC trust anchor configuration files define positive + and negative trust anchors + systemd-resolved.service8 + bases DNSSEC integrity proofs on. + + + + Positive Trust Anchors + + Positive trust anchor configuration files contain DNSKEY and + DS resource record definitions to use as base for DNSSEC integrity + proofs. See RFC 4035, + Section 4.4 for more information about DNSSEC trust + anchors. + + Positive trust anchors are read from files with the suffix + .positive located in + /etc/dnssec-trust-anchors.d/, + /run/dnssec-trust-anchors.d/ and + /usr/lib/dnssec-trust-anchors.d/. These + directories are searched in the specified order, and a trust + anchor file of the same name in an earlier path overrides a trust + anchor files in a later path. To disable a trust anchor file + shipped in /usr/lib/dnssec-trust-anchors.d/ + it is sufficient to provide an identically-named file in + /etc/dnssec-trust-anchors.d/ or + /run/dnssec-trust-anchors.d/ that is either + empty or a symlink to /dev/null ("masked"). + + Positive trust anchor files are simple text files resembling + DNS zone files, as documented in RFC 1035, Section + 5. One DS or DNSKEY resource record may be listed per + line. Empty lines and lines starting with a semicolon + (;) are ignored and considered comments. A DS + resource record is specified like in the following example: + + . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 + + The first word specifies the domain, use + . for the root domain. The domain may be + specified with or without trailing dot, which is considered + equivalent. The second word must be IN the + third word DS. The following words specify the + key tag, signature algorithm, digest algorithm, followed by the + hex-encoded key fingerprint. See RFC 4034, + Section 5 for details about the precise syntax and meaning + of these fields. + + Alternatively, DNSKEY resource records may be used to define + trust anchors, like in the following example: + + . IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= + + 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. See RFC 4034, + Section 2 for details about the precise syntax and meaning + of these fields. + + If multiple DS or DNSKEY records are defined for the same + domain (possibly even in different trust anchor files), all keys + are used and are considered equivalent as base for DNSSEC + proofs. + + Note that 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. In most cases it is hence unnecessary to define an + explicit key with trust anchor files. The built-in key is disabled + as soon as at least one trust anchor key for the root domain is + defined in trust anchor files. + + It is generally recommended to encode trust anchors in DS + resource records, rather than DNSKEY resource records. + + If a trust anchor specified via a DS record is found revoked + it is automatically removed from the trust anchor database for the + runtime. See RFC + 5011 for details about revoked trust anchors. Note that + systemd-resolved will not update its trust + anchor database from DNS servers automatically. Instead, it is + recommended to update the resolver software or update the new + trust anchor via adding in new trust anchor files. + + The current DNSSEC trust anchor for the Internet's root + domain is available at the IANA + Trust Anchor and Keys page. + + + + Negative Trust Anchors + + Negative trust anchors define domains where DNSSEC + validation shall be turned off. Negative trust anchor files are + found at the same location as positive trust anchor files, and + follow the same overriding rules. They are text files with the + .negative suffix. Empty lines and lines whose + first character is ; are ignored. Each line + specifies one domain name where DNSSEC validation shall be + disabled on. + + Negative trust anchors are useful to support private DNS + subtrees that are not referenced from the Internet DNS hierarchy, + and not signed. + + RFC + 7646 for 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. + + It is also possibly to define per-interface negative trust + anchors using the DNSSECNegativeTrustAnchors= + setting in + systemd.network5 + files. + + + + See Also + + systemd1, + systemd-resolved.service8, + resolved.conf5, + systemd.network5 + + + + diff --git a/src/grp-resolve/systemd-resolved/resolved.conf.xml b/src/grp-resolve/systemd-resolved/resolved.conf.xml new file mode 100644 index 0000000000..920ce9e89b --- /dev/null +++ b/src/grp-resolve/systemd-resolved/resolved.conf.xml @@ -0,0 +1,219 @@ + + + + + + + + resolved.conf + systemd + + + + Developer + Tom + Gundersen + teg@jklm.no + + + + + + resolved.conf + 5 + + + + resolved.conf + resolved.conf.d + Network Name Resolution configuration files + + + + /etc/systemd/resolved.conf + /etc/systemd/resolved.conf.d/*.conf + /run/systemd/resolved.conf.d/*.conf + /usr/lib/systemd/resolved.conf.d/*.conf + + + + Description + + These configuration files control local DNS and LLMNR + name resolution. + + + + + + + Options + + The following options are available in the [Resolve] section: + + + + + DNS= + A space-separated list of IPv4 and IPv6 addresses to use as system DNS servers. DNS requests + are sent to one of the listed DNS servers in parallel to suitable per-link DNS servers acquired from + systemd-networkd.service8 or + set at runtime by external applications. For compatibility reasons, if this setting is not specified, the DNS + servers listed in /etc/resolv.conf are used instead, if that file exists and any servers + are configured in it. This setting defaults to the empty list. + + + + FallbackDNS= + A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers. Any + per-link DNS servers obtained from + systemd-networkd.service8 + take precedence over this setting, as do any servers set via DNS= above or + /etc/resolv.conf. This setting is hence only used if no other DNS server information is + known. If this option is not given, a compiled-in list of DNS servers is used instead. + + + + Domains= + A space-separated list of domains. These domains are used as search suffixes when resolving + single-label host names (domain names which contain no dot), in order to qualify them into fully-qualified + domain names (FQDNs). Search domains are strictly processed in the order they are specified, until the name + with the suffix appended is found. For compatibility reasons, if this setting is not specified, the search + domains listed in /etc/resolv.conf are used instead, if that file exists and any domains + are configured in it. This setting defaults to the empty list. + + Specified domain names may optionally be prefixed with ~. In this case they do not + define a search path, but preferably direct DNS queries for the indicated domains to the DNS servers configured + with the system DNS= setting (see above), in case additional, suitable per-link DNS servers + are known. If no per-link DNS servers are known using the ~ syntax has no effect. Use the + construct ~. (which is composed of ~ to indicate a routing domain and + . to indicate the DNS root domain that is the implied suffix of all DNS domains) to use the + system DNS server defined with DNS= preferably for all domains. + + + + LLMNR= + Takes a boolean argument or + resolve. Controls Link-Local Multicast Name + Resolution support (RFC 4794) on + the local host. If true, enables full LLMNR responder and + resolver support. If false, disables both. If set to + resolve, only resolution support is enabled, + but responding is disabled. Note that + systemd-networkd.service8 + also maintains per-link LLMNR settings. LLMNR will be + enabled on a link only if the per-link and the + global setting is on. + + + + DNSSEC= + Takes a boolean argument or + allow-downgrade. If true all DNS lookups are + DNSSEC-validated locally (excluding LLMNR and Multicast + DNS). If the response to a lookup request is detected to be invalid + a lookup failure is returned to applications. Note that + this mode requires a DNS server that supports DNSSEC. If the + DNS server does not properly support DNSSEC all validations + will fail. If set to allow-downgrade DNSSEC + validation is attempted, but if the server does not support + DNSSEC properly, DNSSEC mode is automatically disabled. Note + that 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. If set to + false, DNS lookups are not DNSSEC validated. + + Note that DNSSEC validation requires retrieval of + additional DNS data, and thus results in a small DNS look-up + time penalty. + + DNSSEC requires knowledge of "trust anchors" to prove + data integrity. The trust anchor for the Internet root domain + is built into the resolver, additional trust anchors may be + defined with + dnssec-trust-anchors.d5. + Trust anchors may change at regular intervals, and old trust + anchors may be revoked. In such a case DNSSEC validation is + not possible until new trust anchors are configured locally or + the resolver software package is updated with the new root + trust anchor. In effect, when the built-in trust anchor is + revoked and DNSSEC= is true, all further + lookups will fail, as it cannot be proved anymore whether + lookups are correctly signed, or validly unsigned. If + DNSSEC= is set to + allow-downgrade the resolver will + automatically turn off DNSSEC validation in such a case. + + Client programs looking up DNS data will be informed + whether lookups could be verified using DNSSEC, or whether the + returned data could not be verified (either because the data + was found unsigned in the DNS, or the DNS server did not + support DNSSEC or no appropriate trust anchors were known). In + the latter case it is assumed that client programs employ a + secondary scheme to validate the returned DNS data, should + this be required. + + It is recommended to set DNSSEC= to + true on systems where it is known that the DNS server supports + DNSSEC correctly, and where software or trust anchor updates + happen regularly. On other systems it is recommended to set + DNSSEC= to + allow-downgrade. + + In addition to this global DNSSEC setting + systemd-networkd.service8 + also maintains per-link DNSSEC settings. For system DNS + servers (see above), only the global DNSSEC setting is in + effect. For per-link DNS servers the per-link + setting is in effect, unless it is unset in which case the + global setting is used instead. + + Site-private DNS zones generally conflict with DNSSEC + operation, unless a negative (if the private zone is not + signed) or positive (if the private zone is signed) trust + anchor is configured for them. If + allow-downgrade mode is selected, it is + attempted to detect site-private DNS zones using top-level + domains (TLDs) that are not known by the DNS root server. This + logic does not work in all private zone setups. + + Defaults to off. + + + + + + + + See Also + + systemd1, + systemd-resolved.service8, + systemd-networkd.service8, + dnssec-trust-anchors.d5, + resolv.conf4 + + + + diff --git a/src/grp-resolve/systemd-resolved/systemd-resolved.service.xml b/src/grp-resolve/systemd-resolved/systemd-resolved.service.xml new file mode 100644 index 0000000000..829729ca09 --- /dev/null +++ b/src/grp-resolve/systemd-resolved/systemd-resolved.service.xml @@ -0,0 +1,163 @@ + + + + + + + + + systemd-resolved.service + systemd + + + + Developer + Tom + Gundersen + teg@jklm.no + + + + + + systemd-resolved.service + 8 + + + + systemd-resolved.service + systemd-resolved + Network Name Resolution manager + + + + systemd-resolved.service + /usr/lib/systemd/systemd-resolved + + + + Description + + systemd-resolved is a system service that provides network name resolution to local + applications. It implements a caching and validating DNS/DNSSEC stub resolver, as well as an LLMNR resolver and + responder. In addition it maintains the /run/systemd/resolve/resolv.conf file for + compatibility with traditional Linux programs. This file may be symlinked from + /etc/resolv.conf. + + The glibc NSS module + nss-resolve8 is required to + permit glibc's NSS resolver functions to resolve host names via systemd-resolved. + + The DNS servers contacted are determined from the global + settings in /etc/systemd/resolved.conf, the + per-link static settings in /etc/systemd/network/*.network files, + and the per-link dynamic settings received over DHCP. See + resolved.conf5 + and + systemd.network5 + for details. To improve compatibility, + /etc/resolv.conf is read in order to discover + configured system DNS servers, but only if it is not a symlink + to /run/systemd/resolve/resolv.conf (see above). + + systemd-resolved synthesizes DNS RRs for the following cases: + + + The local, configured hostname is resolved to + all locally configured IP addresses ordered by their scope, or + — if none are configured — the IPv4 address 127.0.0.2 (which + is on the local loopback) and the IPv6 address ::1 (which is the + local host). + + The hostnames localhost and + localhost.localdomain (as well as any hostname + ending in .localhost or .localhost.localdomain) + are resolved to the IP addresses 127.0.0.1 and ::1. + + The hostname gateway is + resolved to all current default routing gateway addresses, + ordered by their metric. This assigns a stable hostname to the + current gateway, useful for referencing it independently of the + current network configuration state. + + The mappings defined in /etc/hosts are resolved to their configured + addresses and back. + + + Lookup requests are routed to the available DNS servers + and LLMNR interfaces according to the following rules: + + + Lookups for the special hostname + localhost are never routed to the + network. (A few other, special domains are handled the same way.) + + Single-label names are routed to all local + interfaces capable of IP multicasting, using the LLMNR + protocol. Lookups for IPv4 addresses are only sent via LLMNR on + IPv4, and lookups for IPv6 addresses are only sent via LLMNR on + IPv6. Lookups for the locally configured host name and the + gateway host name are never routed to + LLMNR. + + Multi-label names are routed to all local + interfaces that have a DNS sever configured, plus the globally + configured DNS server if there is one. Address lookups from the + link-local address range are never routed to + DNS. + + + If lookups are routed to multiple interfaces, the first + successful response is returned (thus effectively merging the + lookup zones on all matching interfaces). If the lookup failed on + all interfaces, the last failing response is returned. + + Routing of lookups may be influenced by configuring + per-interface domain names. See + systemd.network5 + for details. Lookups for a hostname ending in one of the + per-interface domains are exclusively routed to the matching + interfaces. + + Note that /run/systemd/resolve/resolv.conf should not be used directly by applications, + but only through a symlink from /etc/resolv.conf. + + See the resolved D-Bus API + Documentation for information about the APIs systemd-resolved provides. + + + + + See Also + + systemd1, + resolved.conf5, + dnssec-trust-anchors.d5, + nss-resolve8, + systemd-resolve1, + resolv.conf5, + hosts5, + systemd.network5, + systemd-networkd.service8 + + + + -- cgit v1.2.3-54-g00ecf