Pi-Hole/dnsmasq
1
0
Fork 0
mirror of https://github.com/pi-hole/dnsmasq.git synced 2025-12-19 18:28:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

Man page entries for DNSSEC flags.

Browse Source
This commit is contained in:
Simon Kelley
2014-01-27 22:38:48 +00:00
parent 7c28612a59
commit 70b4a818ef
1 changed files with 22 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
man/dnsmasq.8
View File

@@ -579,19 +579,29 @@ Set the maximum number of concurrent DNS queries. The default value is
where this needs to be increased is when using web-server log file where this needs to be increased is when using web-server log file
resolvers, which can generate large numbers of concurrent queries. resolvers, which can generate large numbers of concurrent queries.
.TP .TP
.B --dnssec
Validate DNS replies and cache DNSSEC data. When forwarding DNS queries, dnsmasq requests the
DNSSEC records needed to validate the replies. The replies are validated and the result returned as
the Authenticated Data bit in the DNS packet. In addition the DNSSEC records are stored in the cache, making
validation by clients more efficient. Note that validation by clients is the most secure DNSSEC mode, but for
clients unable to do validation, use of the AD bit set by dnsmasq is useful, provided that the network between
the dnsmasq server and the client is trusted. Dnsmasq must be compiled with HAVE_DNSSEC enabled, and DNSSEC
trust anchors provided, see
.B --dnsskey.
Because the DNSSEC validation process uses the cache, it is not permitted to reduce the cache size below the default when DNSSEC is enabled.
.TP
.B --dnskey=[<class>],<domain>,<flags>,<algorithm>,<base64-key>
Provide DNSKEY records to act a trust anchors for DNSSEC validation. Typically these will be the keys for root zone,
but trust anchors for limited domains are also possible.
.TP
.B --proxy-dnssec .B --proxy-dnssec
A resolver on a client machine can do DNSSEC validation in two ways: it Copy the DNSSEC Authenticated Data bit from upstream servers to downstream clients and cache it. This is an
can perform the cryptograhic operations on the reply it receives, or alternative to having dnsmasq validate DNSSEC, but it depends on the security of the network between
it can rely on the upstream recursive nameserver to do the validation dnsmasq and the upstream servers, and the trustworthiness of the upstream servers.
and set a bit in the reply if it succeeds. Dnsmasq is not a DNSSEC .TP
validator, so it cannot perform the validation role of the recursive nameserver, .B --dnssec-debug
but it can pass through the validation results from its own upstream Set debugging mode for the DNSSEC validation, set the Checking Disabled bit on upstream queries,
nameservers. This option enables this behaviour. You should only do and don't convert BOGUS replies to SERVFAIL responses.
this if you trust all the configured upstream nameservers
.I and the network between you and them.
If you use the first DNSSEC mode, validating resolvers in clients,
this option is not required. Dnsmasq always returns all the data
needed for a client to do validation itself.
.TP .TP
.B --auth-zone=<domain>[,<subnet>[/<prefix length>][,<subnet>[/<prefix length>].....]] .B --auth-zone=<domain>[,<subnet>[/<prefix length>][,<subnet>[/<prefix length>].....]]
Define a DNS zone for which dnsmasq acts as authoritative server. Locally defined DNS records which are in the domain Define a DNS zone for which dnsmasq acts as authoritative server. Locally defined DNS records which are in the domain