TrueCloudLab/coredns
16
0
Fork 2
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions

Try to clarify rewrite docs (#1795)

Browse source 
making response rewrites more prominent
This commit is contained in:
Chris O'Haver 2018-05-11 13:50:59 -04:00 • committed by GitHub
parent 940b7f2e8c
commit 2c04e72bdc
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 19 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
plugin/rewrite/README.md
View file

@ -11,24 +11,20 @@ Rewrites are invisible to the client. There are simple rewrites (fast) and compl
## Syntax ## Syntax
A simplified/easy to digest syntax for *rewrite* is...
~~~ ~~~
rewrite [continue|stop] FIELD FROM TO rewrite [continue|stop] FIELD FROM TO
~~~ ~~~
* **FIELD** is (`type`, `class`, `name`, ...) * **FIELD** indicates what part of the request/response is being re-written.
* **FROM** is the exact name of type to match * `type` - the type field of the request will be rewritten. FROM/TO must be a DNS record type (`A`, `MX`, etc);
* **TO** is the destination name or type to rewrite to
When the FIELD is `type` and FROM is (`A`, `MX`, etc.), the type of the message will be rewritten;
e.g., to rewrite ANY queries to HINFO, use `rewrite type ANY HINFO`. e.g., to rewrite ANY queries to HINFO, use `rewrite type ANY HINFO`.
* `class` - the class of the message will be rewritten. FROM/TO must be a DNS class type (`IN`, `CH`, or `HS`) e.g., to rewrite CH queries to IN use `rewrite class CH IN`.
When the FIELD is `class` and FROM is (`IN`, `CH`, or `HS`) the class of the message will be * `name` - the query name in the _request_ is rewritten; by default this is a full match of the name, e.g., `rewrite name miek.nl example.org`. Other match types are supported, see the **Name Field Rewrites** section below.
rewritten; e.g., to rewrite CH queries to IN use `rewrite class CH IN`. * `answer name` - the query name in the _response_ is rewritten. This option has special restrictions and requirements, in particular it must always combined with a `name` rewrite. See below in the **Response Rewrites** section.
* `edns0` - an EDNS0 option can be appended to the request as described below in the **EDNS0 Options** section.
When the FIELD is `name` the query name in the message is rewritten; this * **FROM** is the name or type to match
needs to be a full match of the name, e.g., `rewrite name miek.nl example.org`. * **TO** is the destination name or type to rewrite to
When the FIELD is `edns0` an EDNS0 option can be appended to the request as described below.
If you specify multiple rules and an incoming query matches on multiple rules, the rewrite If you specify multiple rules and an incoming query matches on multiple rules, the rewrite
will behave as following will behave as following
@ -235,3 +231,13 @@ rewrite edns0 subnet set 24 56
* If the query has source IP as IPv4, the first 24 bits in the IP will be the network subnet. * If the query has source IP as IPv4, the first 24 bits in the IP will be the network subnet.
* If the query has source IP as IPv6, the first 56 bits in the IP will be the network subnet. * If the query has source IP as IPv6, the first 56 bits in the IP will be the network subnet.
## Full Syntax
The full plugin usage syntax is harder to digest...
~~~
rewrite [continue|stop] {type|class|edns0|name [exact|prefix|suffix|substring|regex [FROM TO answer name]]} FROM TO
~~~
The syntax above doesn't cover the multi line block option for specifying a name request+response rewrite rule described in the **Response Rewrite** section.