Mirrors/coredns
1
0
Fork 0
mirror of https://github.com/coredns/coredns.git synced 2025-11-02 02:03:13 -05:00
Code Issues Packages Projects Releases Wiki Activity

doc: make -f Makefile.doc (#2919)

Browse Source 
mechanical change: create the manual pages.

Signed-off-by: Miek Gieben <miek@miek.nl>
This commit is contained in:
Miek Gieben
2019-06-24 12:37:27 +01:00
committed by Yong Tang
parent e54b784a7e
commit 51cf388da2
36 changed files with 423 additions and 286 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
man/coredns-loop.7
View File

@@ -1,11 +1,11 @@
.\" Generated by Mmark Markdown Processer - mmark.nl
.TH "COREDNS-LOOP" "7" "April 2019" "CoreDNS" "CoreDNS Plugins"
.TH "COREDNS-LOOP" 7 "June 2019" "CoreDNS" "CoreDNS Plugins"
.SH NAME
.SH "NAME"
.PP
\fIloop\fP - detect simple forwarding loops and halt the server.
.SH DESCRIPTION
.SH "DESCRIPTION"
.PP
The \fIloop\fP plugin will send a random probe query to ourselves and will then keep track of how many times
we see it. If we see it more than twice, we assume CoreDNS has seen a forwarding loop and we halt the process.
@@ -18,7 +18,7 @@ death.
.PP
The query sent is \fB\fC<random number>.<random number>.zone\fR with type set to HINFO.
.SH SYNTAX
.SH "SYNTAX"
.PP
.RS
@@ -28,7 +28,7 @@ loop
.fi
.RE
.SH EXAMPLES
.SH "EXAMPLES"
.PP
Start a server on the default port and load the \fIloop\fP and \fIforward\fP plugins. The \fIforward\fP plugin
forwards to it self.
@@ -57,7 +57,7 @@ plugin/loop: Loop (127.0.0.1:55953 \-> :1053) detected for zone ".", see https:/
.fi
.RE
.SH LIMITATIONS
.SH "LIMITATIONS"
.PP
This plugin only attempts to find simple static forwarding loops at start up time. To detect a loop,
the following must be true:
@@ -68,7 +68,7 @@ the loop must be present at start up time.
the loop must occur for the \fB\fCHINFO\fR query type.
.SH TROUBLESHOOTING
.SH "TROUBLESHOOTING"
.PP
When CoreDNS logs contain the message \fB\fCLoop ... detected ...\fR, this means that the \fB\fCloop\fR detection
plugin has detected an infinite forwarding loop in one of the upstream DNS servers. This is a fatal
@@ -90,7 +90,7 @@ in which the loop was detected. Make sure that they are not forwarding to a loc
to another DNS server that is forwarding requests back to CoreDNS. If \fB\fCforward\fR is
using a file (e.g. \fB\fC/etc/resolv.conf\fR), make sure that file does not contain local addresses.
.SS TROUBLESHOOTING LOOPS IN KUBERNETES CLUSTERS
.SS "TROUBLESHOOTING LOOPS IN KUBERNETES CLUSTERS"
.PP
When a CoreDNS Pod deployed in Kubernetes detects a loop, the CoreDNS Pod will start to "CrashLoopBackOff".
This is because Kubernetes will try to restart the Pod every time CoreDNS detects the loop and exits.
@@ -108,7 +108,7 @@ requests to itself.
There are many ways to work around this issue, some are listed here:
.IP \(bu 4
Add the following to \fB\fCkubelet\fR: \fB\fC--resolv-conf <path-to-your-real-resolv-conf-file>\fR. Your "real"
Add the following to your \fB\fCkubelet\fR config yaml: \fB\fCresolvConf: <path-to-your-real-resolv-conf-file>\fR (or via command line flag \fB\fC--resolv-conf\fR deprecated in 1.10). Your "real"
\fB\fCresolv.conf\fR is the one that contains the actual IPs of your upstream servers, and no local/loopback address.
This flag tells \fB\fCkubelet\fR to pass an alternate \fB\fCresolv.conf\fR to Pods. For systems using \fB\fCsystemd-resolved\fR,
\fB\fC/run/systemd/resolve/resolv.conf\fR is typically the location of the "real" \fB\fCresolv.conf\fR,