惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
I
InfoQ
H
Help Net Security
GbyAI
GbyAI
博客园 - 叶小钗
Recent Announcements
Recent Announcements
Engineering at Meta
Engineering at Meta
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
爱范儿
爱范儿
Y
Y Combinator Blog
L
LangChain Blog
腾讯CDC
酷 壳 – CoolShell
酷 壳 – CoolShell
WordPress大学
WordPress大学
Stack Overflow Blog
Stack Overflow Blog
F
Fortinet All Blogs
G
Google Developers Blog
Apple Machine Learning Research
Apple Machine Learning Research
The GitHub Blog
The GitHub Blog
T
The Blog of Author Tim Ferriss
博客园 - Franky
D
Docker
Jina AI
Jina AI
罗磊的独立博客

CoreDNS: DNS and Service Discovery

CoreDNS-1.14.2 Release CoreDNS-1.14.1 Release CoreDNS-1.14.0 Release CoreDNS-1.13.2 Release CoreDNS-1.13.1 Release CoreDNS-1.13.0 Release CoreDNS-1.12.4 Release CoreDNS-1.12.3 Release CoreDNS-1.12.2 Release CoreDNS-1.12.1 Release CoreDNS-1.12.0 Release CoreDNS-1.11.4 Release CoreDNS-1.11.3 Release k8s_cache CoreDNS-1.11.2 Release CoreDNS-1.11.1 Release CoreDNS-1.11.0 Release CoreDNS-1.10.1 Release CoreDNS-1.10.0 Release CoreDNS-1.9.4 Release CoreDNS-1.9.3 Release CoreDNS-1.9.2 Release CoreDNS-1.9.1 Release CoreDNS and Apache APISIX open new doors for Service Discovery? Trail Of Bits Security Review CoreDNS-1.9.0 Release CoreDNS-1.8.7 Release CoreDNS-1.8.6 Release CoreDNS-1.8.5 Release CoreDNS-1.8.4 Release
tls
2024-11-22 · via CoreDNS: DNS and Service Discovery

Description

CoreDNS supports queries that are encrypted using TLS (DNS over Transport Layer Security, RFC 7858) 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 tls “plugin” allows you to configure the cryptographic keys that are needed for both DNS-over-TLS and DNS-over-gRPC. If the tls plugin is omitted, then no encryption takes place.

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.

Syntax

Parameter CA is optional. If not set, system CAs can be used to verify the client certificate

tls CERT KEY [CA] {
    client_auth nocert|request|require|verify_if_given|require_and_verify
}

If client_auth option is specified, it controls the client authentication policy. The option value corresponds to the ClientAuthType values of the Go tls package: NoClientCert, RequestClientCert, RequireAnyClientCert, VerifyClientCertIfGiven, and RequireAndVerifyClientCert, respectively. 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.

Examples

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.

tls://.:5553 {
	tls cert.pem key.pem ca.pem
	forward . /etc/resolv.conf
}

Start a DNS-over-gRPC server that is similar to the previous example, but using DNS-over-gRPC for incoming queries.

grpc://. {
	tls cert.pem key.pem ca.pem
	forward . /etc/resolv.conf
}

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
}

Only Knot DNS’ kdig supports DNS-over-TLS queries, no command line client supports gRPC making debugging these transports harder than it should be.

See Also

RFC 7858 and https://grpc.io.