Mirrors/coredns
1
0
Fork 0
mirror of https://github.com/coredns/coredns.git synced 2025-10-27 00:04:15 -04:00
Code Issues Packages Projects Releases Wiki Activity

doc: regen man-pages (#3725)

Browse Source 
Mechanical change: make -f Makefile.doc

Signed-off-by: Miek Gieben <miek@miek.nl>
This commit is contained in:
Miek Gieben
2020-03-06 11:11:45 +00:00
committed by GitHub
parent 116bda4d27
commit e2515fe0e3
10 changed files with 54 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
man/coredns-forward.7
View File

@@ -1,5 +1,5 @@
.\" Generated by Mmark Markdown Processer - mmark.miek.nl
.TH "COREDNS-FORWARD" 7 "January 2020" "CoreDNS" "CoreDNS Plugins"
.TH "COREDNS-FORWARD" 7 "March 2020" "CoreDNS" "CoreDNS Plugins"
.SH "NAME"
.PP
@@ -11,12 +11,14 @@ The \fIforward\fP plugin re-uses already opened sockets to the upstreams. It sup
DNS-over-TLS and uses in band health checking.
.PP
When it detects an error a health check is performed. This checks runs in a loop, every \fI0.5s\fP, for
as long as the upstream reports unhealthy. Once healthy we stop health checking (until the next
error). The health checks use a recursive DNS query (\fB\fC. IN NS\fR) to get upstream health. Any response
that is not a network error (REFUSED, NOTIMPL, SERVFAIL, etc) is taken as a healthy upstream. The
health check uses the same protocol as specified in \fBTO\fP. If \fB\fCmax_fails\fR is set to 0, no checking
is performed and upstreams will always be considered healthy.
When it detects an error a health check is performed. This checks runs in a loop, starting with
a \fI0.5s\fP interval and exponentially backing off with randomized intervals up to \fI15s\fP for as long
as the upstream reports unhealthy. The exponential backoff will reset to \fI0.5s\fP after 2 minutes.
Once healthy we stop health checking (until the next error). The health checks use a recursive
DNS query (\fB\fC. IN NS\fR) to get upstream health. Any response that is not a network error (REFUSED,
NOTIMPL, SERVFAIL, etc) is taken as a healthy upstream. The health check uses the same protocol as
specified in \fBTO\fP. If \fB\fCmax_fails\fR is set to 0, no checking is performed and upstreams will always
be considered healthy.
.PP
When \fIall\fP upstreams are down it assumes health checking as a mechanism has failed and will try to
@@ -66,7 +68,8 @@ forward FROM TO... {
tls CERT KEY CA
tls\_servername NAME
policy random|round\_robin|sequential
health\_check DURATION
health\_check DURATION [no\_rec]
max\_concurrent MAX
}
.fi
@@ -124,7 +127,22 @@ but they have to use the same \fB\fCtls_servername\fR. E.g. mixing 9.9.9.9 (Quad
.RE
.IP \(bu 4
\fB\fChealth_check\fR, use a different \fBDURATION\fP for health checking, the default duration is 0.5s.
\fB\fChealth_check\fR configure the behaviour of health checking of the upstream servers
.RS
.IP \(en 4
\fB\fC<duration>\fR - use a different duration for health checking, the default duration is 0.5s.
.IP \(en 4
\fB\fCno_rec\fR - optional argument that sets the RecursionDesired-flag of the dns-query used in health checking to \fB\fCfalse\fR.
The flag is default \fB\fCtrue\fR.
.RE
.IP \(bu 4
\fB\fCmax_concurrent\fR \fBMAX\fP will limit the number of concurrent queries to \fBMAX\fP. Any new query that would
raise the number of concurrent queries above the \fBMAX\fP will result in a SERVFAIL response. This
response does not count as a health failure. When choosing a value for \fBMAX\fP, pick a number
at least greater than the expected \fIupstream query rate\fP * \fIlatency\fP of the upstream servers.
As an upper bound for \fBMAX\fP, consider that each concurrent query will use about 2kb of memory.
.PP
@@ -155,12 +173,13 @@ If monitoring is enabled (via the \fIprometheus\fP plugin) then the following me
.IP \(bu 4
\fB\fCcoredns_forward_healthcheck_broken_count_total{}\fR - counter of when all upstreams are unhealthy,
and we are randomly (this always uses the \fB\fCrandom\fR policy) spraying to an upstream.
.PP
.IP \(bu 4
\fB\fCmax_concurrent_reject_count_total{}\fR - counter of the number of queries rejected because the
number of concurrent queries were at maximum.
Where \fB\fCto\fR is one of the upstream servers (\fBTO\fP from the config), \fB\fCrcode\fR is the returned RCODE
from the upstream.
.SH "EXAMPLES"
.PP
Proxy all requests within \fB\fCexample.org.\fR to a nameserver running on a different port: