2017-03-13 20:24:37 +00:00
# tls
2018-01-04 12:53:07 +00:00
## Name
2021-11-23 14:03:26 +01:00
*tls* - allows you to configure the server certificates for the TLS, gRPC, DoH servers.
2018-01-04 12:53:07 +00:00
## Description
2017-03-13 20:24:37 +00:00
2017-09-12 14:54:26 +01:00
CoreDNS supports queries that are encrypted using TLS (DNS over Transport Layer Security, RFC 7858)
2024-03-08 04:24:38 +09:00
or are using gRPC (https://grpc.io/ , not an IETF standard). Normally DNS traffic isn't encrypted at
2017-09-12 14:54:26 +01:00
all (DNSSEC only signs resource records).
2017-09-14 09:36:06 +01:00
The * tls * "plugin" allows you to configure the cryptographic keys that are needed for both
2019-10-08 10:20:48 +01:00
DNS-over-TLS and DNS-over-gRPC. If the * tls * plugin is omitted, then no encryption takes place.
2017-09-12 14:54:26 +01:00
The gRPC protobuffer is defined in `pb/dns.proto` . It defines the proto as a simple wrapper for the
wire data of a DNS message.
2017-03-13 20:24:37 +00:00
## Syntax
~~~ txt
2018-05-15 19:53:46 +03:00
tls CERT KEY [CA]
2017-03-13 20:24:37 +00:00
~~~
2018-05-15 19:53:46 +03:00
Parameter CA is optional. If not set, system CAs can be used to verify the client certificate
2019-05-31 09:30:15 -07:00
~~~ txt
tls CERT KEY [CA] {
client_auth nocert|request|require|verify_if_given|require_and_verify
2026-03-27 12:10:13 -07:00
keylog FILE
2019-05-31 09:30:15 -07:00
}
~~~
2019-12-29 13:35:17 +01:00
If client\_auth option is specified, it controls the client authentication policy.
2019-05-31 09:30:15 -07:00
The option value corresponds to the [ClientAuthType values of the Go tls package ](https://golang.org/pkg/crypto/tls/#ClientAuthType ): NoClientCert, RequestClientCert, RequireAnyClientCert, VerifyClientCertIfGiven, and RequireAndVerifyClientCert, respectively.
2019-12-29 13:35:17 +01:00
The default is "nocert". Note that it makes no sense to specify parameter CA unless this option is
set to verify\_if\_given or require\_and\_verify.
2019-05-31 09:30:15 -07:00
2026-03-27 12:10:13 -07:00
The keylog can be specified to export TLS master secrets in key log format to allow external programs
to decrypt TLS connections. It compromises security and should only be used for debugging!
2017-03-13 20:24:37 +00:00
## Examples
2017-04-19 17:43:10 -04:00
2017-09-12 14:54:26 +01:00
Start a DNS-over-TLS server that picks up incoming DNS-over-TLS queries on port 5553 and uses the
nameservers defined in `/etc/resolv.conf` to resolve the query. This proxy path uses plain old DNS.
2017-04-19 17:43:10 -04:00
~~~
2017-09-12 14:54:26 +01:00
tls://.:5553 {
2017-04-19 17:43:10 -04:00
tls cert.pem key.pem ca.pem
2019-03-03 23:32:38 -08:00
forward . /etc/resolv.conf
2017-04-19 17:43:10 -04:00
}
~~~
2017-09-12 14:54:26 +01:00
Start a DNS-over-gRPC server that is similar to the previous example, but using DNS-over-gRPC for
incoming queries.
2017-04-19 17:43:10 -04:00
~~~
2017-09-12 14:54:26 +01:00
grpc://. {
2017-04-19 17:43:10 -04:00
tls cert.pem key.pem ca.pem
2019-03-03 23:32:38 -08:00
forward . /etc/resolv.conf
2017-04-19 17:43:10 -04:00
}
~~~
2017-09-12 14:54:26 +01:00
2021-11-23 14:03:26 +01:00
Start a DoH server on port 443 that is similar to the previous example, but using DoH for incoming queries.
~~~
https://. {
tls cert.pem key.pem ca.pem
forward . /etc/resolv.conf
}
~~~
2017-09-12 14:54:26 +01:00
Only Knot DNS' `kdig` supports DNS-over-TLS queries, no command line client supports gRPC making
debugging these transports harder than it should be.
2020-10-28 18:56:35 +01:00
## See Also
2017-09-12 14:54:26 +01:00
RFC 7858 and https://grpc.io.