github/coredns.io
4
0
Fork 0
mirror of https://github.com/coredns/coredns.io.git synced 2026-10-19 16:15:37 +00:00
Code Issues Releases Wiki Activity

Perform make sync

Browse Source 
Signed-off-by: Miek Gieben <miek@miek.nl>
This commit is contained in:
Miek Gieben
2019-03-16 09:31:17 +00:00
parent 423abdcf46
commit 6bf13fd2b6
38 changed files with 301 additions and 289 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/plugins/auto.md
+1 -1
View File
@@ -4,7 +4,7 @@ description = "*auto* enables serving zone data from an RFC 1035-style master fi
weight = 1
tags = [ "plugin", "auto" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.601042"
date = "2019-03-16T09:30:30.535429"
+++
## Description
content/plugins/autopath.md
+1 -1
View File
@@ -4,7 +4,7 @@ description = "*autopath* allows for server-side search path completion."
weight = 2
tags = [ "plugin", "autopath" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.601271"
date = "2019-03-16T09:30:30.535607"
+++
## Description
content/plugins/bind.md
+1 -1
View File
@@ -4,7 +4,7 @@ description = "*bind* overrides the host to which the server should bind."
weight = 3
tags = [ "plugin", "bind" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.601427"
date = "2019-03-16T09:30:30.535705"
+++
## Description
content/plugins/cache.md
+4 -3
View File
@@ -4,7 +4,7 @@ description = "*cache* enables a frontend cache."
weight = 4
tags = [ "plugin", "cache" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.601576"
date = "2019-03-16T09:30:30.535806"
+++
## Description
@@ -91,13 +91,14 @@ Proxy to Google Public DNS and only cache responses for example.org (or below).
~~~ corefile
. {
proxy . 8.8.8.8:53
forward . 8.8.8.8:53
cache example.org
}
~~~
Enable caching for all zones, keep a positive cache size of 5000 and a negative cache size of 2500:
~~~ corefile
~~~ corefile
. {
cache {
success 5000
content/plugins/chaos.md
+1 -1
View File
@@ -4,7 +4,7 @@ description = "*chaos* allows for responding to TXT queries in the CH class."
weight = 5
tags = [ "plugin", "chaos" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.601704"
date = "2019-03-16T09:30:30.535889"
+++
## Description
content/plugins/debug.md
+1 -1
View File
@@ -4,7 +4,7 @@ description = "*debug* disables the automatic recovery upon a crash so that you'
weight = 6
tags = [ "plugin", "debug" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.601808"
date = "2019-03-16T09:30:30.535959"
+++
## Description
content/plugins/dnssec.md
+1 -1
View File
@@ -4,7 +4,7 @@ description = "*dnssec* enable on-the-fly DNSSEC signing of served data."
weight = 7
tags = [ "plugin", "dnssec" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.601956"
date = "2019-03-16T09:30:30.536061"
+++
## Description
content/plugins/dnstap.md
+1 -1
View File
@@ -4,7 +4,7 @@ description = "*dnstap* enable logging to dnstap."
weight = 8
tags = [ "plugin", "dnstap" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.602107"
date = "2019-03-16T09:30:30.536147"
+++
## Description
content/plugins/erratic.md
+3 -3
View File
@@ -4,7 +4,7 @@ description = "*erratic* a plugin useful for testing client behavior."
weight = 9
tags = [ "plugin", "erratic" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.602228"
date = "2019-03-16T09:30:30.536230"
+++
## Description
@@ -36,9 +36,9 @@ erratic {
In case of a zone transfer and truncate the final SOA record *isn't* added to the response.
## Health
## Ready
This plugin implements dynamic health checking. For every dropped query it turns unhealthy.
This plugin reports readiness to the ready plugin.
## Examples
content/plugins/errors.md
+1 -1
View File
@@ -4,7 +4,7 @@ description = "*errors* enable error logging."
weight = 10
tags = [ "plugin", "errors" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.602358"
date = "2019-03-16T09:30:30.536304"
+++
## Description
content/plugins/etcd.md
+5 -5
View File
@@ -4,7 +4,7 @@ description = "*etcd* enables reading zone data from an etcd version 3 instance.
weight = 11
tags = [ "plugin", "etcd" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.602538"
date = "2019-03-16T09:30:30.536446"
+++
## Description
@@ -13,7 +13,7 @@ The data in etcd instance has to be encoded as
a [message](https://github.com/skynetservices/skydns/blob/2fcff74cdc9f9a7dd64189a447ef27ac354b725f/msg/service.go#L26)
like [SkyDNS](https://github.com/skynetservices/skydns). It should also work just like SkyDNS.
The etcd plugin makes extensive use of the proxy plugin to forward and query other servers in the
The etcd plugin makes extensive use of the forward plugin to forward and query other servers in the
network.
## Syntax
@@ -49,7 +49,7 @@ etcd [ZONES...] {
* `credentials` is used to set the **USERNAME** and **PASSWORD** for accessing the etcd cluster.
* `upstream` upstream resolvers to be used resolve external names found in etcd (think CNAMEs)
pointing to external names. If you want CoreDNS to act as a proxy for clients, you'll need to add
the proxy plugin. If no **ADDRESS** is given, CoreDNS will resolve CNAMEs against itself.
the *forward* plugin. If no **ADDRESS** is given, CoreDNS will resolve CNAMEs against itself.
**ADDRESS** can be an IP address, and IP:port or a string pointing to a file that is structured
as /etc/resolv.conf.
* `tls` followed by:
@@ -88,7 +88,7 @@ This is the default SkyDNS setup, with everything specified in full:
prometheus
cache 160 skydns.local
loadbalance
proxy . 8.8.8.8:53 8.8.4.4:53
forward . 8.8.8.8:53 8.8.4.4:53
}
~~~
@@ -102,7 +102,7 @@ when resolving external pointing CNAMEs.
upstream
}
cache 160 skydns.local
proxy . /etc/resolv.conf
forward . /etc/resolv.conf
}
~~~
content/plugins/federation.md
+1 -1
View File
@@ -4,7 +4,7 @@ description = "*federation* enables federated queries to be resolved via the kub
weight = 12
tags = [ "plugin", "federation" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.602659"
date = "2019-03-16T09:30:30.536530"
+++
## Description
content/plugins/file.md
+1 -1
View File
@@ -4,7 +4,7 @@ description = "*file* enables serving zone data from an RFC 1035-style master fi
weight = 13
tags = [ "plugin", "file" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.602768"
date = "2019-03-16T09:30:30.536621"
+++
## Description
content/plugins/forward.md
+1 -1
View File
@@ -4,7 +4,7 @@ description = "*forward* facilitates proxying DNS messages to upstream resolvers
weight = 14
tags = [ "plugin", "forward" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.602920"
date = "2019-03-16T09:30:30.536747"
+++
## Description
content/plugins/grpc.md
+138
View File
@@ -0,0 +1,138 @@
+++
title = "grpc"
description = "*grpc* facilitates proxying DNS messages to upstream resolvers via gRPC protocol."
weight = 15
tags = [ "plugin", "grpc" ]
categories = [ "plugin" ]
date = "2019-03-16T09:30:30.536860"
+++
## Description
The *grpc* plugin supports gRPC and TLS.
This plugin can only be used once per Server Block.
## Syntax
In its most basic form:
~~~
grpc FROM TO...
~~~
* **FROM** is the base domain to match for the request to be proxied.
* **TO...** are the destination endpoints to proxy to. The number of upstreams is
limited to 15.
Multiple upstreams are randomized (see `policy`) on first use. When a proxy returns an error
the next upstream in the list is tried.
Extra knobs are available with an expanded syntax:
~~~
grpc FROM TO... {
except IGNORED_NAMES...
tls CERT KEY CA
tls_servername NAME
policy random|round_robin|sequential
}
~~~
* **FROM** and **TO...** as above.
* **IGNORED_NAMES** in `except` is a space-separated list of domains to exclude from proxying.
Requests that match none of these names will be passed through.
* `tls` **CERT** **KEY** **CA** define the TLS properties for TLS connection. From 0 to 3 arguments can be
provided with the meaning as described below
* `tls` - no client authentication is used, and the system CAs are used to verify the server certificate
* `tls` **CA** - no client authentication is used, and the file CA is used to verify the server certificate
* `tls` **CERT** **KEY** - client authentication is used with the specified cert/key pair.
The server certificate is verified with the system CAs
* `tls` **CERT** **KEY** **CA** - client authentication is used with the specified cert/key pair.
The server certificate is verified using the specified CA file
* `tls_servername` **NAME** allows you to set a server name in the TLS configuration; for instance 9.9.9.9
needs this to be set to `dns.quad9.net`. Multiple upstreams are still allowed in this scenario,
but they have to use the same `tls_servername`. E.g. mixing 9.9.9.9 (QuadDNS) with 1.1.1.1
(Cloudflare) will not work.
* `policy` specifies the policy to use for selecting upstream servers. The default is `random`.
Also note the TLS config is "global" for the whole grpc proxy if you need a different
`tls-name` for different upstreams you're out of luck.
## Metrics
If monitoring is enabled (via the *prometheus* directive) then the following metric are exported:
* `coredns_grpc_request_duration_seconds{to}` - duration per upstream interaction.
* `coredns_grpc_request_count_total{to}` - query count per upstream.
* `coredns_grpc_response_rcode_total{to, rcode}` - count of RCODEs per upstream.
and we are randomly (this always uses the `random` policy) spraying to an upstream.
## Examples
Proxy all requests within `example.org.` to a nameserver running on a different port:
~~~ corefile
example.org {
grpc . 127.0.0.1:9005
}
~~~
Load balance all requests between three resolvers, one of which has a IPv6 address.
~~~ corefile
. {
grpc . 10.0.0.10:53 10.0.0.11:1053 [2003::1]:53
}
~~~
Forward everything except requests to `example.org`
~~~ corefile
. {
grpc . 10.0.0.10:1234 {
except example.org
}
}
~~~
Proxy everything except `example.org` using the host's `resolv.conf`'s nameservers:
~~~ corefile
. {
grpc . /etc/resolv.conf {
except example.org
}
}
~~~
Proxy all requests to 9.9.9.9 using the TLS protocol, and cache every answer for up to 30
seconds. Note the `tls_servername` is mandatory if you want a working setup, as 9.9.9.9 can't be
used in the TLS negotiation.
~~~ corefile
. {
grpc . 9.9.9.9 {
tls_servername dns.quad9.net
}
cache 30
}
~~~
Or with multiple upstreams from the same provider
~~~ corefile
. {
grpc . 1.1.1.1 1.0.0.1 {
tls_servername cloudflare-dns.com
}
cache 30
}
~~~
## Bugs
The TLS config is global for the whole grpc proxy if you need a different `tls_servername` for
different upstreams you're out of luck.
content/plugins/health.md
+12 -31
View File
@@ -1,17 +1,16 @@
+++
title = "health"
description = "*health* enables a health check endpoint."
weight = 15
weight = 16
tags = [ "plugin", "health" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.603066"
date = "2019-03-16T09:30:30.536940"
+++
## Description
By enabling *health* any plugin that implements
[health.Healther interface](https://godoc.org/github.com/coredns/coredns/plugin/health#Healther)
will be queried for it's health. The combined health is exported, by default, on port 8080/health .
Enabled process wide health endpoint. When CoreDNS is up and running this returns a 200 OK http
status code. The health is exported, by default, on port 8080/health .
## Syntax
@@ -20,12 +19,9 @@ health [ADDRESS]
~~~
Optionally takes an address; the default is `:8080`. The health path is fixed to `/health`. The
health endpoint returns a 200 response code and the word "OK" when this server is healthy. It returns
a 503. *health* periodically (1s) polls plugins that exports health information. If any of the
plugins signals that it is unhealthy, the server will go unhealthy too. Each plugin that supports
health checks has a section "Health" in their README.
health endpoint returns a 200 response code and the word "OK" when this server is healthy.
More options can be set with this extended syntax:
An extra option can be set with this extended syntax:
~~~
health [ADDRESS] {
@@ -36,8 +32,8 @@ health [ADDRESS] {
* Where `lameduck` will make the process unhealthy then *wait* for **DURATION** before the process
shuts down.
If you have multiple Server Blocks and need to export health for each of the plugins, you must run
health endpoints on different ports:
If you have multiple Server Blocks, *health* should only be enabled in one of them (as it is process
wide). If you really need multiple endpoints, you must run health endpoints on different ports:
~~~ corefile
com {
@@ -51,21 +47,6 @@ net {
}
~~~
Note that if you format this in one server block you will get an error on startup, that the second
server can't setup the health plugin (on the same port).
~~~ txt
com net {
whoami
erratic
health :8080
}
~~~
## Plugins
Any plugin that implements the Healther interface will be used to report health.
## Metrics
If monitoring is enabled (via the *prometheus* directive) then the following metric is exported:
@@ -99,7 +80,7 @@ Set a lameduck duration of 1 second:
## Bugs
When reloading, the Health handler is stopped before the new server instance is started.
If that new server fails to start, then the initial server instance is still available and DNS queries still served,
but Health handler stays down.
Health will not reply HTTP request until a successful reload or a complete restart of CoreDNS.
When reloading, the health handler is stopped before the new server instance is started. If that
new server fails to start, then the initial server instance is still available and DNS queries still
served, but health handler stays down. Health will not reply HTTP request until a successful reload
or a complete restart of CoreDNS.
content/plugins/hosts.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "hosts"
description = "*hosts* enables serving zone data from a `/etc/hosts` style file."
weight = 16
weight = 17
tags = [ "plugin", "hosts" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.603190"
date = "2019-03-16T09:30:30.537034"
+++
## Description
content/plugins/import.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "import"
description = "*import* include files or reference snippets from a Corefile."
weight = 17
weight = 18
tags = [ "plugin", "import" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.603300"
date = "2019-03-16T09:30:30.537117"
+++
## Description
content/plugins/k8s_external.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "k8s_external"
description = "*k8s_external* resolve load balancer and external IPs from outside kubernetes clusters."
weight = 18
weight = 19
tags = [ "plugin", "k8s_external" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.603412"
date = "2019-03-16T09:30:30.537196"
+++
## Description
content/plugins/kubernetes.md
+16 -17
View File
@@ -1,10 +1,10 @@
+++
title = "kubernetes"
description = "*kubernetes* enables the reading zone data from a Kubernetes cluster."
weight = 19
weight = 20
tags = [ "plugin", "kubernetes" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.603587"
date = "2019-03-16T09:30:30.537337"
+++
## Description
@@ -17,7 +17,7 @@ cluster. See the [deployment](https://github.com/coredns/deployment) repository
to deploy CoreDNS in Kubernetes](https://github.com/coredns/deployment/tree/master/kubernetes).
[stubDomains and upstreamNameservers](https://kubernetes.io/blog/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes/)
are implemented via the *proxy* plugin and kubernetes *upstream*. See example below.
are implemented via the *forward* plugin and kubernetes *upstream*. See the examples below.
This plugin can only be used once per Server Block.
@@ -110,11 +110,6 @@ kubernetes [ZONES...] {
This allows the querying pod to continue searching for the service in the search path.
The search path could, for example, include another Kubernetes cluster.
## Health
This plugin implements dynamic health checking. Currently this is limited to reporting healthy when
the API has synced.
## Examples
Handle all queries in the `cluster.local` zone. Connect to Kubernetes in-cluster. Also handle all
@@ -147,31 +142,35 @@ kubernetes cluster.local {
}
~~~
## stubDomains and upstreamNameservers
Here we use the *proxy* plugin to implement a stubDomain that forwards `example.local` to the nameserver `10.100.0.10:53`.
Here we use the *forward* plugin to implement a stubDomain that forwards `example.local` to the nameserver `10.100.0.10:53`.
The *upstream* option in the *kubernetes* plugin means that ExternalName services (CNAMEs) will be resolved using the respective proxy.
Also configured is an upstreamNameserver `8.8.8.8:53` that will be used for resolving names that do not fall in `cluster.local`
or `example.local`.
~~~ txt
.:53 {
cluster.local:53 {
kubernetes cluster.local {
upstream
}
proxy example.local 10.100.0.10:53
proxy . 8.8.8.8:53
}
example.local {
forward . 10.100.0.10:53
}
. {
forward . 8.8.8.8:53
}
~~~
The configuration above represents the following Kube-DNS stubDomains and upstreamNameservers configuration.
~~~ txt
stubDomains: |
{“example.local”: [“10.100.0.10:53”]}
upstreamNameservers: |
[“8.8.8.8:53”]
stubDomains: |
{“example.local”: [“10.100.0.10:53”]}
upstreamNameservers: |
[“8.8.8.8:53”]
~~~
## AutoPath
content/plugins/loadbalance.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "loadbalance"
description = "*loadbalance* randomize the order of A, AAAA and MX records."
weight = 20
weight = 21
tags = [ "plugin", "loadbalance" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.603695"
date = "2019-03-16T09:30:30.537414"
+++
## Description
content/plugins/log.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "log"
description = "*log* enables query logging to standard output."
weight = 21
weight = 22
tags = [ "plugin", "log" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.603834"
date = "2019-03-16T09:30:30.537522"
+++
## Description
content/plugins/loop.md
+8 -8
View File
@@ -1,10 +1,10 @@
+++
title = "loop"
description = "*loop* detect simple forwarding loops and halt the server."
weight = 22
weight = 23
tags = [ "plugin", "loop" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.603973"
date = "2019-03-16T09:30:30.537620"
+++
## Description
@@ -63,10 +63,10 @@ A forwarding loop is usually caused by:
* Most commonly, CoreDNS forwarding requests directly to itself. e.g. via a loopback address such as `127.0.0.1`, `::1` or `127.0.0.53`
* Less commonly, CoreDNS forwarding to an upstream server that in turn, forwards requests back to CoreDNS.
To troubleshoot this problem, look in your Corefile for any `proxy` or `forward` to the zone
To troubleshoot this problem, look in your Corefile for any `forward`s to the zone
in which the loop was detected. Make sure that they are not forwarding to a local address or
to another DNS server that is forwarding requests back to CoreDNS. If `proxy` or `forward` are
using a file (e.g. `/etc/resolv.conf`), make sure that file does not contain local addresses.
to another DNS server that is forwarding requests back to CoreDNS. If `forward` is
using a file (e.g. `/etc/resolv.conf`), make sure that file does not contain local addresses.
### Troubleshooting Loops In Kubernetes Clusters
@@ -78,7 +78,7 @@ on the host node (e.g. `systemd-resolved`). For example, in certain configurati
put the loopback address `127.0.0.53` as a nameserver into `/etc/resolv.conf`. Kubernetes (via `kubelet`) by default
will pass this `/etc/resolv.conf` file to all Pods using the `default` dnsPolicy rendering them
unable to make DNS lookups (this includes CoreDNS Pods). CoreDNS uses this `/etc/resolv.conf`
as a list of upstreams to proxy/forward requests to. Since it contains a loopback address, CoreDNS ends up forwarding
as a list of upstreams to forward requests to. Since it contains a loopback address, CoreDNS ends up forwarding
requests to itself.
There are many ways to work around this issue, some are listed here:
@@ -89,6 +89,6 @@ There are many ways to work around this issue, some are listed here:
`/run/systemd/resolve/resolv.conf` is typically the location of the "real" `resolv.conf`,
although this can be different depending on your distribution.
* Disable the local DNS cache on host nodes, and restore `/etc/resolv.conf` to the original.
* A quick and dirty fix is to edit your Corefile, replacing `proxy . /etc/resolv.conf` with
the ip address of your upstream DNS, for example `proxy . 8.8.8.8`. But this only fixes the issue for CoreDNS,
* A quick and dirty fix is to edit your Corefile, replacing `forward . /etc/resolv.conf` with
the ip address of your upstream DNS, for example `forward . 8.8.8.8`. But this only fixes the issue for CoreDNS,
kubelet will continue to forward the invalid `resolv.conf` to all `default` dnsPolicy Pods, leaving them unable to resolve DNS.
content/plugins/metadata.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "metadata"
description = "*metadata* enable a meta data collector."
weight = 23
weight = 24
tags = [ "plugin", "metadata" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.604079"
date = "2019-03-16T09:30:30.537691"
+++
## Description
content/plugins/metrics.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "prometheus"
description = "*prometheus* enables [Prometheus](https://prometheus.io/) metrics."
weight = 24
weight = 25
tags = [ "plugin", "metrics" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.604191"
date = "2019-03-16T09:30:30.537771"
+++
## Description
content/plugins/nsid.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "nsid"
description = "*nsid* adds an identifier of this server to each reply."
weight = 25
weight = 26
tags = [ "plugin", "nsid" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.604305"
date = "2019-03-16T09:30:30.537851"
+++
## Description
content/plugins/pprof.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "pprof"
description = "*pprof* publishes runtime profiling data at endpoints under `/debug/pprof`."
weight = 26
weight = 27
tags = [ "plugin", "pprof" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.604429"
date = "2019-03-16T09:30:30.537938"
+++
## Description
content/plugins/proxy.md
-163
View File
@@ -1,163 +0,0 @@
+++
title = "proxy"
description = "*proxy* facilitates both a basic reverse proxy and a robust load balancer."
weight = 27
tags = [ "plugin", "proxy" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.604581"
+++
## Description
The proxy has support for multiple backends. The load balancing features include multiple policies,
health checks, and failovers. If all hosts fail their health check the proxy plugin will fail
back to randomly selecting a target and sending packets to it.
## Syntax
In its most basic form, a simple reverse proxy uses this syntax:
~~~
proxy FROM TO
~~~
* **FROM** is the base domain to match for the request to be proxied.
* **TO** is the destination endpoint to proxy to.
However, advanced features including load balancing can be utilized with an expanded syntax:
~~~
proxy FROM TO... {
policy random|least_conn|round_robin|sequential
fail_timeout DURATION
max_fails INTEGER
health_check PATH:PORT [DURATION]
except IGNORED_NAMES...
spray
protocol [dns [force_tcp]|grpc [insecure|CACERT|KEY CERT|KEY CERT CACERT]]
}
~~~
* **FROM** is the name to match for the request to be proxied.
* **TO** is the destination endpoint to proxy to. At least one is required, but multiple may be
specified. **TO** may be an IP:Port pair, or may reference a file in resolv.conf format
* `policy` is the load balancing policy to use; applies only with multiple backends. May be one of
random, least_conn, round_robin or sequential. Default is random.
* `fail_timeout` specifies how long to consider a backend as down after it has failed. While it is
down, requests will not be routed to that backend. A backend is "down" if CoreDNS fails to
communicate with it. The default value is 2 seconds ("2s").
* `max_fails` is the number of failures within fail_timeout that are needed before considering
a backend to be down. If 0, the backend will never be marked as down. Default is 1.
* `health_check` will check **PATH** (on **PORT**) on each backend. If a backend returns a status code of
200-399, then that backend is marked healthy for double the healthcheck duration. If it doesn't,
it is marked as unhealthy and no requests are routed to it. If this option is not provided then
health checks are disabled. The default duration is 4 seconds ("4s").
* **IGNORED_NAMES** in `except` is a space-separated list of domains to exclude from proxying.
Requests that match none of these names will be passed through.
* `spray` when all backends are unhealthy, randomly pick one to send the traffic to. (This is
a failsafe.)
* `protocol` specifies what protocol to use to speak to an upstream, `dns` (the default) is plain
old DNS. The `grpc` option will talk to a server that has implemented
the [DnsService](https://github.com/coredns/coredns/blob/master/pb/dns.proto).
## Policies
There are four load-balancing policies available:
* `random` (default) - Randomly select a backend
* `least_conn` - Select the backend with the fewest active connections
* `round_robin` - Select the backend in round-robin fashion
* `sequential` - Select the first available backend looking by order of declaration from left to right
* `first` - Deprecated. Use sequential instead
All polices implement randomly spraying packets to backend hosts when *no healthy* hosts are
available. This is to preempt the case where the healthchecking (as a mechanism) fails.
## Upstream Protocols
`dns`
: uses the standard DNS exchange. You can pass `force_tcp` to make sure that the proxied connection is performed
over TCP, regardless of the inbound request's protocol.
`grpc`
: extra options are used to control how the TLS connection is made to the gRPC server.
* None - No client authentication is used, and the system CAs are used to verify the server certificate.
* `insecure` - TLS is not used, the connection is made in plaintext (not good in production).
* **CACERT** - No client authentication is used, and the file **CACERT** is used to verify the server certificate.
* **KEY** **CERT** - Client authentication is used with the specified key/cert pair. The server
certificate is verified with the system CAs.
* **KEY** **CERT** **CACERT** - Client authentication is used with the specified key/cert pair. The
server certificate is verified using the **CACERT** file.
## Metrics
If monitoring is enabled (via the *prometheus* directive) then the following metric is exported:
* `coredns_proxy_request_duration_seconds{server, proto, proto_proxy, family, to}` - duration per
upstream interaction.
* `coredns_proxy_request_count_total{server, proto, proto_proxy, family, to}` - query count per
upstream.
Where `proxy_proto` is the protocol used (`dns` or `grpc`) and `to` is **TO**
specified in the config, `proto` is the protocol used by the incoming query ("tcp" or "udp"), family
the transport family ("1" for IPv4, and "2" for IPv6). `Server` is the server responsible for the
request (and metric). See the documentation in the metrics plugin.
## Examples
Proxy all requests within example.org. to a backend system:
~~~
proxy example.org 127.0.0.1:9005
~~~
Load-balance all requests between three backends (using random policy):
~~~ corefile
. {
proxy . 10.0.0.10:53 10.0.0.11:1053 10.0.0.12
}
~~~
Same as above, but round-robin style:
~~~ corefile
. {
proxy . 10.0.0.10:53 10.0.0.11:1053 10.0.0.12 {
policy round_robin
}
}
~~~
With health checks and proxy headers to pass hostname, IP, and scheme upstream:
~~~ corefile
. {
proxy . 10.0.0.11:53 10.0.0.11:53 10.0.0.12:53 {
policy round_robin
health_check /health:8080
}
}
~~~
Proxy everything except requests to miek.nl or example.org
~~~
. {
proxy . 10.0.0.10:1234 {
except miek.nl example.org
}
}
~~~
Proxy everything except `example.org` using the host's `resolv.conf`'s nameservers:
~~~ corefile
. {
proxy . /etc/resolv.conf {
except example.org
}
}
~~~
content/plugins/ready.md
+59
View File
@@ -0,0 +1,59 @@
+++
title = "ready"
description = "*ready* enables a readiness check HTTP endpoint."
weight = 28
tags = [ "plugin", "ready" ]
categories = [ "plugin" ]
date = "2019-03-16T09:30:30.538007"
+++
## Description
By enabling *ready* an HTTP endpoint on port 8181 will return 200 OK, when all plugins that are able
to signal readiness have done so. If some are not ready yet the endpoint will return a 503 with the
body containing the list of plugins that are not ready. Once a plugin has signaled it is ready it
will not be queried again.
Each Server Block that enables the *ready* plugin will have the plugins *in that server block*
report readiness into the /ready endpoint that runs on the same port.
## Syntax
~~~
ready [ADDRESS]
~~~
*ready* optionally takes an address; the default is `:8181`. The path is fixed to `/ready`. The
readiness endpoint returns a 200 response code and the word "OK" when this server is ready. It
returns a 503 otherwise.
## Plugins
Any plugin wanting to signal readiness will need to implement the `ready.Readiness` interface by
implementing a method `Ready() bool` that returns true when the plugin is ready and false otherwise.
## Examples
Let *ready* report readiness for both the `.` and `example.org` servers (assuming the *whois*
plugin also exports readiness):
~~~ txt
. {
ready
erratic
}
example.org {
ready
whoami
}
~~~
Run *ready* on a different port.
~~~ txt
. {
ready localhost:8091
}
~~~
content/plugins/reload.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "reload"
description = "*reload* allows automatic reload of a changed Corefile."
weight = 28
weight = 29
tags = [ "plugin", "reload" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.604709"
date = "2019-03-16T09:30:30.538095"
+++
## Description
content/plugins/rewrite.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "rewrite"
description = "*rewrite* performs internal message rewriting."
weight = 29
weight = 30
tags = [ "plugin", "rewrite" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.604906"
date = "2019-03-16T09:30:30.538261"
+++
## Description
content/plugins/root.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "root"
description = "*root* simply specifies the root of where to find (zone) files."
weight = 30
weight = 31
tags = [ "plugin", "root" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.605014"
date = "2019-03-16T09:30:30.538338"
+++
## Description
content/plugins/route53.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "route53"
description = "*route53* enables serving zone data from AWS route53."
weight = 31
weight = 32
tags = [ "plugin", "route53" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.605135"
date = "2019-03-16T09:30:30.538426"
+++
## Description
content/plugins/secondary.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "secondary"
description = "*secondary* enables serving a zone retrieved from a primary server."
weight = 32
weight = 33
tags = [ "plugin", "secondary" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.605236"
date = "2019-03-16T09:30:30.538503"
+++
## Description
content/plugins/template.md
+9 -9
View File
@@ -1,10 +1,10 @@
+++
title = "template"
description = "*template* allows for dynamic responses based on the incoming query."
weight = 33
weight = 34
tags = [ "plugin", "template" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.605422"
date = "2019-03-16T09:30:30.538652"
+++
## Description
@@ -95,7 +95,7 @@ The `.invalid` domain is a reserved TLD (see [RFC 2606 Reserved Top Level DNS Na
~~~ corefile
. {
proxy . 8.8.8.8
forward . 8.8.8.8
template ANY ANY invalid {
rcode NXDOMAIN
@@ -119,7 +119,7 @@ path (`dc1.example.com`) added.
~~~ corefile
. {
proxy . 8.8.8.8
forward . 8.8.8.8
template IN ANY example.com.dc1.example.com {
rcode NXDOMAIN
@@ -132,7 +132,7 @@ A more verbose regex based equivalent would be
~~~ corefile
. {
proxy . 8.8.8.8
forward . 8.8.8.8
template IN ANY example.com {
match "example\.com\.(dc1\.example\.com\.)$"
@@ -149,7 +149,7 @@ The regex-based version can do more complex matching/templating while zone-based
~~~ corefile
. {
proxy . 8.8.8.8
forward . 8.8.8.8
# ip-a-b-c-d.example A a.b.c.d
@@ -181,7 +181,7 @@ Fallthrough is needed for mixed domains where only some responses are templated.
~~~ corefile
. {
proxy . 8.8.8.8
forward . 8.8.8.8
template IN A example {
match "^ip-(?P<a>10)-(?P<b>[0-9]*)-(?P<c>[0-9]*)-(?P<d>[0-9]*)[.]dc[.]example[.]$"
@@ -198,7 +198,7 @@ Named capture groups can be used to template one response for multiple patterns.
~~~ corefile
. {
proxy . 8.8.8.8
forward . 8.8.8.8
template IN A example {
match ^ip-10-(?P<b>[0-9]*)-(?P<c>[0-9]*)-(?P<d>[0-9]*)[.]example[.]$
@@ -218,7 +218,7 @@ Named capture groups can be used to template one response for multiple patterns.
~~~ corefile
. {
proxy . 8.8.8.8
forward . 8.8.8.8
template IN A example {
match ^ip-10-(?P<b>[0-9]*)-(?P<c>[0-9]*)-(?P<d>[0-9]*)[.]example[.]$
content/plugins/tls.md
+4 -7
View File
@@ -1,10 +1,10 @@
+++
title = "tls"
description = "*tls* allows you to configure the server certificates for the TLS and gRPC servers."
weight = 34
weight = 35
tags = [ "plugin", "tls" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.605544"
date = "2019-03-16T09:30:30.538742"
+++
## Description
@@ -13,9 +13,6 @@ CoreDNS supports queries that are encrypted using TLS (DNS over Transport Layer
or are using gRPC (https://grpc.io/, not an IETF standard). Normally DNS traffic isn't encrypted at
all (DNSSEC only signs resource records).
The *proxy* plugin also support gRPC (`protocol gRPC`), meaning you can chain CoreDNS servers
using this protocol.
The *tls* "plugin" allows you to configure the cryptographic keys that are needed for both
DNS-over-TLS and DNS-over-gRPC. If the `tls` directive is omitted, then no encryption takes place.
@@ -38,7 +35,7 @@ nameservers defined in `/etc/resolv.conf` to resolve the query. This proxy path
~~~
tls://.:5553 {
tls cert.pem key.pem ca.pem
proxy . /etc/resolv.conf
forward . /etc/resolv.conf
}
~~~
@@ -48,7 +45,7 @@ incoming queries.
~~~
grpc://. {
tls cert.pem key.pem ca.pem
proxy . /etc/resolv.conf
forward . /etc/resolv.conf
}
~~~
content/plugins/trace.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "trace"
description = "*trace* enables OpenTracing-based tracing of DNS requests as they go through the plugin chain."
weight = 35
weight = 36
tags = [ "plugin", "trace" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.605663"
date = "2019-03-16T09:30:30.538824"
+++
## Description
content/plugins/whoami.md
+2 -2
View File
@@ -1,10 +1,10 @@
+++
title = "whoami"
description = "*whoami* returns your resolver's local IP address, port and transport."
weight = 36
weight = 37
tags = [ "plugin", "whoami" ]
categories = [ "plugin" ]
date = "2019-03-03T14:11:50.605766"
date = "2019-03-16T09:30:30.538897"
+++
## Description