forked from coredns/coredns
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathcoredns-grpc.7
205 lines (157 loc) · 4.37 KB
/
coredns-grpc.7
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
.\" Generated by Mmark Markdown Processer - mmark.nl
.TH "COREDNS-GRPC" "7" "April 2019" "CoreDNS" "CoreDNS Plugins"
.SH NAME
.PP
\fIgrpc\fP - facilitates proxying DNS messages to upstream resolvers via gRPC protocol.
.SH DESCRIPTION
.PP
The \fIgrpc\fP plugin supports gRPC and TLS.
.PP
This plugin can only be used once per Server Block.
.SH SYNTAX
.PP
In its most basic form:
.PP
.RS
.nf
grpc FROM TO...
.fi
.RE
.IP \(bu 4
\fBFROM\fP is the base domain to match for the request to be proxied.
.IP \(bu 4
\fBTO...\fP are the destination endpoints to proxy to. The number of upstreams is
limited to 15.
.PP
Multiple upstreams are randomized (see \fB\fCpolicy\fR) on first use. When a proxy returns an error
the next upstream in the list is tried.
.PP
Extra knobs are available with an expanded syntax:
.PP
.RS
.nf
grpc FROM TO... {
except IGNORED\_NAMES...
tls CERT KEY CA
tls\_servername NAME
policy random|round\_robin|sequential
}
.fi
.RE
.IP \(bu 4
\fBFROM\fP and \fBTO...\fP as above.
.IP \(bu 4
\fBIGNORED_NAMES\fP in \fB\fCexcept\fR is a space-separated list of domains to exclude from proxying.
Requests that match none of these names will be passed through.
.IP \(bu 4
\fB\fCtls\fR \fBCERT\fP \fBKEY\fP \fBCA\fP define the TLS properties for TLS connection. From 0 to 3 arguments can be
provided with the meaning as described below
.RS
.IP \(en 4
\fB\fCtls\fR - no client authentication is used, and the system CAs are used to verify the server certificate
.IP \(en 4
\fB\fCtls\fR \fBCA\fP - no client authentication is used, and the file CA is used to verify the server certificate
.IP \(en 4
\fB\fCtls\fR \fBCERT\fP \fBKEY\fP - client authentication is used with the specified cert/key pair.
The server certificate is verified with the system CAs
.IP \(en 4
\fB\fCtls\fR \fBCERT\fP \fBKEY\fP \fBCA\fP - client authentication is used with the specified cert/key pair.
The server certificate is verified using the specified CA file
.RE
.IP \(bu 4
\fB\fCtls_servername\fR \fBNAME\fP allows you to set a server name in the TLS configuration; for instance 9.9.9.9
needs this to be set to \fB\fCdns.quad9.net\fR. Multiple upstreams are still allowed in this scenario,
but they have to use the same \fB\fCtls_servername\fR. E.g. mixing 9.9.9.9 (QuadDNS) with 1.1.1.1
(Cloudflare) will not work.
.IP \(bu 4
\fB\fCpolicy\fR specifies the policy to use for selecting upstream servers. The default is \fB\fCrandom\fR.
.PP
Also note the TLS config is "global" for the whole grpc proxy if you need a different
\fB\fCtls-name\fR for different upstreams you're out of luck.
.SH METRICS
.PP
If monitoring is enabled (via the \fIprometheus\fP directive) then the following metric are exported:
.IP \(bu 4
\fB\fCcoredns_grpc_request_duration_seconds{to}\fR - duration per upstream interaction.
.IP \(bu 4
\fB\fCcoredns_grpc_request_count_total{to}\fR - query count per upstream.
.IP \(bu 4
\fB\fCcoredns_grpc_response_rcode_total{to, rcode}\fR - count of RCODEs per upstream.
and we are randomly (this always uses the \fB\fCrandom\fR policy) spraying to an upstream.
.SH EXAMPLES
.PP
Proxy all requests within \fB\fCexample.org.\fR to a nameserver running on a different port:
.PP
.RS
.nf
example.org {
grpc . 127.0.0.1:9005
}
.fi
.RE
.PP
Load balance all requests between three resolvers, one of which has a IPv6 address.
.PP
.RS
.nf
\&. {
grpc . 10.0.0.10:53 10.0.0.11:1053 [2003::1]:53
}
.fi
.RE
.PP
Forward everything except requests to \fB\fCexample.org\fR
.PP
.RS
.nf
\&. {
grpc . 10.0.0.10:1234 {
except example.org
}
}
.fi
.RE
.PP
Proxy everything except \fB\fCexample.org\fR using the host's \fB\fCresolv.conf\fR's nameservers:
.PP
.RS
.nf
\&. {
grpc . /etc/resolv.conf {
except example.org
}
}
.fi
.RE
.PP
Proxy all requests to 9.9.9.9 using the TLS protocol, and cache every answer for up to 30
seconds. Note the \fB\fCtls_servername\fR is mandatory if you want a working setup, as 9.9.9.9 can't be
used in the TLS negotiation.
.PP
.RS
.nf
\&. {
grpc . 9.9.9.9 {
tls\_servername dns.quad9.net
}
cache 30
}
.fi
.RE
.PP
Or with multiple upstreams from the same provider
.PP
.RS
.nf
\&. {
grpc . 1.1.1.1 1.0.0.1 {
tls\_servername cloudflare\-dns.com
}
cache 30
}
.fi
.RE
.SH BUGS
.PP
The TLS config is global for the whole grpc proxy if you need a different \fB\fCtls_servername\fR for
different upstreams you're out of luck.