mirror of
https://github.com/coredns/coredns.git
synced 2026-04-09 21:45:32 -04:00
chore(docs): regenerate man pages (#7971)
This commit is contained in:
Ville Vesilehto
GitHub
@@ -1,5 +1,5 @@
|
||||
.\" Generated by Mmark Markdown Processer - mmark.miek.nl
|
||||
.TH "COREDNS-REWRITE" 7 "March 2021" "CoreDNS" "CoreDNS Plugins"
|
||||
.TH "COREDNS-REWRITE" 7 "March 2026" "CoreDNS" "CoreDNS Plugins"
|
||||
|
||||
.SH "NAME"
|
||||
.PP
|
||||
@@ -18,7 +18,7 @@ A simplified/easy-to-digest syntax for \fIrewrite\fP is...
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite [continue|stop] FIELD [FROM TO|FROM TTL]
|
||||
rewrite [continue|stop] FIELD [TYPE] [(FROM TO)|TTL] [OPTIONS]
|
||||
|
||||
.fi
|
||||
.RE
|
||||
@@ -31,26 +31,52 @@ rewrite [continue|stop] FIELD [FROM TO|FROM TTL]
|
||||
\fB\fCtype\fR - the type field of the request will be rewritten. FROM/TO must be a DNS record type (\fB\fCA\fR, \fB\fCMX\fR, etc.);
|
||||
e.g., to rewrite ANY queries to HINFO, use \fB\fCrewrite type ANY HINFO\fR.
|
||||
.IP \(en 4
|
||||
\fB\fCclass\fR - the class of the message will be rewritten. FROM/TO must be a DNS class type (\fB\fCIN\fR, \fB\fCCH\fR, or \fB\fCHS\fR); e.g., to rewrite CH queries to IN use \fB\fCrewrite class CH IN\fR.
|
||||
.IP \(en 4
|
||||
\fB\fCname\fR - the query name in the \fIrequest\fP is rewritten; by default this is a full match of the
|
||||
name, e.g., \fB\fCrewrite name example.net example.org\fR. Other match types are supported, see the \fBName Field Rewrites\fP section below.
|
||||
.IP \(en 4
|
||||
\fB\fCanswer name\fR - the query name in the \fIresponse\fP is rewritten. This option has special restrictions and requirements, in particular it must always combined with a \fB\fCname\fR rewrite. See below in the \fBResponse Rewrites\fP section.
|
||||
\fB\fCclass\fR - the class of the message will be rewritten. FROM/TO must be a DNS class type (\fB\fCIN\fR, \fB\fCCH\fR, or \fB\fCHS\fR); e.g., to rewrite CH queries to IN use \fB\fCrewrite class CH IN\fR.
|
||||
.IP \(en 4
|
||||
\fB\fCedns0\fR - an EDNS0 option can be appended to the request as described below in the \fBEDNS0 Options\fP section.
|
||||
.IP \(en 4
|
||||
\fB\fCttl\fR - the TTL value in the \fIresponse\fP is rewritten.
|
||||
.IP \(en 4
|
||||
\fB\fCcname\fR - the CNAME target if the response has a CNAME record
|
||||
.IP \(en 4
|
||||
\fB\fCrcode\fR - the response code (RCODE) value in the \fIresponse\fP is rewritten.
|
||||
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBTYPE\fP this optional element can be specified for a \fB\fCname\fR or \fB\fCttl\fR field.
|
||||
If not given type \fB\fCexact\fR will be assumed. If options should be specified the
|
||||
type must be given.
|
||||
.IP \(bu 4
|
||||
\fBFROM\fP is the name (exact, suffix, prefix, substring, or regex) or type to match
|
||||
.IP \(bu 4
|
||||
\fBTO\fP is the destination name or type to rewrite to
|
||||
.IP \(bu 4
|
||||
\fBTTL\fP is the number of seconds to set the TTL value to
|
||||
\fBTTL\fP is the number of seconds to set the TTL value to (only for field \fB\fCttl\fR)
|
||||
.IP \(bu 4
|
||||
\fBOPTIONS\fP
|
||||
|
||||
|
||||
.PP
|
||||
for field \fB\fCname\fR further options are possible controlling the response rewrites.
|
||||
All name matching types support the following options
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
* `answer auto` \- the names in the \_response\_ is rewritten in a best effort manner.
|
||||
* `answer name FROM TO` \- the query name in the \_response\_ is rewritten matching the from regex pattern.
|
||||
* `answer value FROM TO` \- the names in the \_response\_ is rewritten matching the from regex pattern.
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
See below in the \fBResponse Rewrites\fP section for further details.
|
||||
|
||||
.PP
|
||||
If you specify multiple rules and an incoming query matches multiple rules, the rewrite
|
||||
will behave as follows:
|
||||
@@ -59,6 +85,8 @@ will behave as follows:
|
||||
\fB\fCcontinue\fR will continue applying the next rule in the rule list.
|
||||
.IP \(bu 4
|
||||
\fB\fCstop\fR will consider the current rule the last rule and will not continue. The default behaviour is \fB\fCstop\fR
|
||||
.IP \(bu 4
|
||||
When multiple rules are matched, the request rewrite follows the line order in the configuration, while the response rewrite(\fB\fCanswer\fR option) is executed in reverse order.
|
||||
|
||||
|
||||
.SH "EXAMPLES"
|
||||
@@ -76,7 +104,7 @@ The syntax for name rewriting is as follows:
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite [continue|stop] name [exact|prefix|suffix|substring|regex] STRING STRING
|
||||
rewrite [continue|stop] name [exact|prefix|suffix|substring|regex] STRING STRING [OPTIONS]
|
||||
|
||||
.fi
|
||||
.RE
|
||||
@@ -93,11 +121,13 @@ The match type, e.g., \fB\fCexact\fR, \fB\fCsubstring\fR, etc., triggers rewrite
|
||||
.IP \(bu 4
|
||||
\fBsuffix\fP: when the name ends with the matching string
|
||||
.IP \(bu 4
|
||||
\fBregex\fP: when the name in the question section of a request matches a regular expression
|
||||
\fBregex\fP: when the name in the question section of a request matches a regular expression.
|
||||
Regex patterns must not exceed 10000 characters.
|
||||
|
||||
|
||||
.PP
|
||||
If the match type is omitted, the \fB\fCexact\fR match type is assumed.
|
||||
If the match type is omitted, the \fB\fCexact\fR match type is assumed. If OPTIONS are
|
||||
given, the type must be specified.
|
||||
|
||||
.PP
|
||||
The following instruction allows rewriting names in the query that
|
||||
@@ -158,7 +188,8 @@ rewrite name suffix .schmoogle.com. .google.com.
|
||||
|
||||
.SS "RESPONSE REWRITES"
|
||||
.PP
|
||||
When rewriting incoming DNS requests' names, CoreDNS re-writes the \fB\fCQUESTION SECTION\fR
|
||||
When rewriting incoming DNS requests' names (field \fB\fCname\fR), CoreDNS re-writes
|
||||
the \fB\fCQUESTION SECTION\fR
|
||||
section of the requests. It may be necessary to rewrite the \fB\fCANSWER SECTION\fR of the
|
||||
requests, because some DNS resolvers treat mismatches between the \fB\fCQUESTION SECTION\fR
|
||||
and \fB\fCANSWER SECTION\fR as a man-in-the-middle attack (MITM).
|
||||
@@ -202,6 +233,43 @@ ftp.service.us\-west\-1.consul. 0 IN A 10.30.30.30
|
||||
.PP
|
||||
The above is a mismatch between the question asked and the answer provided.
|
||||
|
||||
.PP
|
||||
There are three possibilities to specify an answer rewrite:
|
||||
- A rewrite can request a best effort answer rewrite by adding the option \fB\fCanswer auto\fR.
|
||||
- A rewrite may specify a dedicated regex based response name rewrite with the
|
||||
\fB\fCanswer name FROM TO\fR option.
|
||||
- A regex based rewrite of record values like \fB\fCCNAME\fR, \fB\fCSRV\fR, etc, can be requested by
|
||||
an \fB\fCanswer value FROM TO\fR option.
|
||||
|
||||
.PP
|
||||
Hereby FROM/TO follow the rules for the \fB\fCregex\fR name rewrite syntax.
|
||||
|
||||
.SS "AUTO RESPONSE NAME REWRITE"
|
||||
.PP
|
||||
The following configuration snippet allows for rewriting of the
|
||||
\fB\fCANSWER SECTION\fR according to the rewrite of the \fB\fCQUESTION SECTION\fR:
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite stop {
|
||||
name suffix .coredns.rocks .service.consul answer auto
|
||||
}
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
Any occurrence of the rewritten question in the answer is mapped
|
||||
back to the original value before the rewrite.
|
||||
|
||||
.PP
|
||||
Please note that answers for rewrites of type \fB\fCexact\fR are always rewritten.
|
||||
For a \fB\fCsuffix\fR name rule \fB\fCauto\fR leads to a reverse suffix response rewrite,
|
||||
exchanging FROM and TO from the rewrite request.
|
||||
|
||||
.SS "EXPLICIT RESPONSE NAME REWRITE"
|
||||
.PP
|
||||
The following configuration snippet allows for rewriting of the
|
||||
\fB\fCANSWER SECTION\fR, provided that the \fB\fCQUESTION SECTION\fR was rewritten:
|
||||
@@ -238,17 +306,18 @@ ftp\-us\-west\-1.coredns.rocks. 0 IN A 10.30.30.30
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.SS "REWRITING OTHER RESPONSE VALUES"
|
||||
.PP
|
||||
It is also possible to rewrite other values returned in the DNS response records
|
||||
(e.g. the server names returned in \fB\fCSRV\fR and \fB\fCMX\fR records). This can be enabled by adding
|
||||
the \fB\fCanswer value\fR to a name regex rule as specified below. \fB\fCanswer value\fR takes a
|
||||
the \fB\fCanswer value FROM TO\fR option to a name rule as specified below. \fB\fCanswer value\fR takes a
|
||||
regular expression and a rewrite name as parameters and works in the same way as the
|
||||
\fB\fCanswer name\fR rule.
|
||||
|
||||
.PP
|
||||
Note that names in the \fB\fCAUTHORITY SECTION\fR and \fB\fCADDITIONAL SECTION\fR will also be
|
||||
rewritten following the specified rules. The names returned by the following
|
||||
record types: \fB\fCCNAME\fR, \fB\fCDNAME\fR, \fB\fCSOA\fR, \fB\fCSRV\fR, \fB\fCMX\fR, \fB\fCNAPTR\fR, \fB\fCNS\fR will be rewritten
|
||||
record types: \fB\fCCNAME\fR, \fB\fCDNAME\fR, \fB\fCSOA\fR, \fB\fCSRV\fR, \fB\fCMX\fR, \fB\fCNAPTR\fR, \fB\fCNS\fR, \fB\fCPTR\fR will be rewritten
|
||||
if the \fB\fCanswer value\fR rule is specified.
|
||||
|
||||
.PP
|
||||
@@ -269,27 +338,98 @@ rewrite [continue|stop] {
|
||||
|
||||
.PP
|
||||
Note that the above syntax is strict. For response rewrites, only \fB\fCname\fR
|
||||
rules are allowed to match the question section, and only by match type
|
||||
\fB\fCregex\fR. The answer rewrite must be after the name, as in the
|
||||
syntax example.
|
||||
rules are allowed to match the question section. The answer rewrite must be
|
||||
after the name, as in the syntax example.
|
||||
|
||||
.SS "EXAMPLE: PTR RESPONSE VALUE REWRITE"
|
||||
.PP
|
||||
An alternate syntax for rewriting a DNS request and response is as
|
||||
follows:
|
||||
The original response contains the domain \fB\fCservice.consul.\fR in the \fB\fCVALUE\fR part
|
||||
of the \fB\fCANSWER SECTION\fR
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite [continue|stop] name regex STRING STRING answer name STRING STRING [answer value STRING STRING]
|
||||
$ dig @10.1.1.1 30.30.30.10.in\-addr.arpa PTR
|
||||
|
||||
;; QUESTION SECTION:
|
||||
;30.30.30.10.in\-addr.arpa. IN PTR
|
||||
|
||||
;; ANSWER SECTION:
|
||||
30.30.30.10.in\-addr.arpa. 60 IN PTR ftp\-us\-west\-1.service.consul.
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
The following configuration snippet allows for rewriting of the value
|
||||
in the \fB\fCANSWER SECTION\fR:
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite stop {
|
||||
name suffix .arpa .arpa
|
||||
answer name auto
|
||||
answer value (.*)\\.service\\.consul\\. {1}.coredns.rocks.
|
||||
}
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
Now, the \fB\fCVALUE\fR in the \fB\fCANSWER SECTION\fR has been overwritten in the domain part:
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
$ dig @10.1.1.1 30.30.30.10.in\-addr.arpa PTR
|
||||
|
||||
;; QUESTION SECTION:
|
||||
;30.30.30.10.in\-addr.arpa. IN PTR
|
||||
|
||||
;; ANSWER SECTION:
|
||||
30.30.30.10.in\-addr.arpa. 60 IN PTR ftp\-us\-west\-1.coredns.rocks.
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.SS "MULTIPLE RESPONSE REWRITES"
|
||||
.PP
|
||||
\fB\fCname\fR and \fB\fCvalue\fR rewrites can be chained by appending multiple answer rewrite
|
||||
options. For all occurrences but the first one the keyword \fB\fCanswer\fR might be
|
||||
omitted.
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
answer (auto | (name|value FROM TO)) { [answer] (auto | (name|value FROM TO)) }
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
For example:
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite [continue|stop] name regex FROM TO answer name FROM TO [answer] value FROM TO
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
When using \fB\fCexact\fR name rewrite rules, the answer gets rewritten automatically,
|
||||
and there is no need to define \fB\fCanswer name\fR. The rule below
|
||||
rewrites the name in a request from \fB\fCRED\fR to \fB\fCBLUE\fR, and subsequently
|
||||
and there is no need to define \fB\fCanswer name auto\fR. But it is still possible to define
|
||||
additional \fB\fCanswer value\fR and \fB\fCanswer value\fR options.
|
||||
|
||||
.PP
|
||||
The rule below rewrites the name in a request from \fB\fCRED\fR to \fB\fCBLUE\fR, and subsequently
|
||||
rewrites the name in a corresponding response from \fB\fCBLUE\fR to \fB\fCRED\fR. The
|
||||
client in the request would see only \fB\fCRED\fR and no \fB\fCBLUE\fR.
|
||||
|
||||
@@ -330,19 +470,125 @@ setting the TTL value really low.
|
||||
.PP
|
||||
The syntax for the TTL rewrite rule is as follows. The meaning of
|
||||
\fB\fCexact|prefix|suffix|substring|regex\fR is the same as with the name rewrite rules.
|
||||
An omitted type is defaulted to \fB\fCexact\fR.
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite [continue|stop] ttl [exact|prefix|suffix|substring|regex] STRING SECONDS
|
||||
rewrite [continue|stop] ttl [exact|prefix|suffix|substring|regex] STRING [SECONDS|MIN\-MAX]
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
It is possible to supply a range of TTL values in the \fB\fCSECONDS\fR parameters instead of a single value.
|
||||
If a range is supplied, the TTL value is set to \fB\fCMIN\fR if it is below, or set to \fB\fCMAX\fR if it is above.
|
||||
The TTL value is left unchanged if it is already inside the provided range.
|
||||
The ranges can be unbounded on either side.
|
||||
|
||||
.PP
|
||||
TTL examples with ranges:
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite ttl example.com. 30\-300
|
||||
|
||||
rewrite ttl example.com. \-30 # equivalent to rewrite ttl example.com. 0\-30
|
||||
|
||||
rewrite ttl example.com. 30\-
|
||||
|
||||
rewrite ttl example.com. 30 # equivalent to rewrite ttl example.com. 30\-30
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.SS "RCODE FIELD REWRITES"
|
||||
.PP
|
||||
At times, the need to rewrite a RCODE value could arise. For example, a DNS server
|
||||
may respond with a SERVFAIL instead of NOERROR records when AAAA records are requested.
|
||||
|
||||
.PP
|
||||
In the below example, the rcode value the answer for \fB\fCcoredns.rocks\fR the replies with SERVFAIL
|
||||
is being switched to NOERROR.
|
||||
|
||||
.PP
|
||||
This example rewrites all the *.coredns.rocks domain SERVFAIL errors to NOERROR
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite continue {
|
||||
rcode regex (.*)\\.coredns\\.rocks SERVFAIL NOERROR
|
||||
}
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
The same result numeric values:
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite continue {
|
||||
rcode regex (.*)\\.coredns\\.rocks 2 0
|
||||
}
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
The syntax for the RCODE rewrite rule is as follows. The meaning of
|
||||
\fB\fCexact|prefix|suffix|substring|regex\fR is the same as with the name rewrite rules.
|
||||
An omitted type is defaulted to \fB\fCexact\fR.
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite [continue|stop] rcode [exact|prefix|suffix|substring|regex] STRING FROM TO
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
The values of FROM and TO can be any of the following, text value or numeric:
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
0 NOERROR
|
||||
1 FORMERR
|
||||
2 SERVFAIL
|
||||
3 NXDOMAIN
|
||||
4 NOTIMP
|
||||
5 REFUSED
|
||||
6 YXDOMAIN
|
||||
7 YXRRSET
|
||||
8 NXRRSET
|
||||
9 NOTAUTH
|
||||
10 NOTZONE
|
||||
16 BADSIG
|
||||
17 BADKEY
|
||||
18 BADTIME
|
||||
19 BADMODE
|
||||
20 BADNAME
|
||||
21 BADALG
|
||||
22 BADTRUNC
|
||||
23 BADCOOKIE
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.SH "EDNS0 OPTIONS"
|
||||
.PP
|
||||
Using the FIELD edns0, you can set, append, or replace specific EDNS0 options in the request.
|
||||
Using the FIELD edns0, you can set, append, replace, or unset specific EDNS0 options in the request.
|
||||
|
||||
.IP \(bu 4
|
||||
\fB\fCreplace\fR will modify any "matching" option with the specified option. The criteria for "matching" varies based on EDNS0 type.
|
||||
@@ -350,6 +596,8 @@ Using the FIELD edns0, you can set, append, or replace specific EDNS0 options in
|
||||
\fB\fCappend\fR will add the option only if no matching option exists
|
||||
.IP \(bu 4
|
||||
\fB\fCset\fR will modify a matching option or add one if none is found
|
||||
.IP \(bu 4
|
||||
\fB\fCunset\fR will remove the matching option if one exists
|
||||
|
||||
|
||||
.PP
|
||||
@@ -424,10 +672,23 @@ rewrite edns0 local set 0xffee {some\-plugin/some\-label}
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
A local option may be removed by unsetting its code. Example:
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite edns0 local unset 0xffee
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.SS "EDNS0_NSID"
|
||||
.PP
|
||||
This has no fields; it will add an NSID option with an empty string for the NSID. If the option already exists
|
||||
and the action is \fB\fCreplace\fR or \fB\fCset\fR, then the NSID in the option will be set to the empty string.
|
||||
The option can be removed with the \fB\fCunset\fR action.
|
||||
|
||||
.SS "EDNS0_SUBNET"
|
||||
.PP
|
||||
@@ -452,19 +713,125 @@ If the query's source IP address is an IPv4 address, the first 24 bits in the IP
|
||||
If the query's source IP address is an IPv6 address, the first 56 bits in the IP will be the network subnet.
|
||||
|
||||
|
||||
.SH "FULL SYNTAX"
|
||||
.PP
|
||||
The full plugin usage syntax is harder to digest...
|
||||
This option can be removed by using \fB\fCunset\fR:
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite [continue|stop] {type|class|edns0|name [exact|prefix|suffix|substring|regex [FROM TO answer name]]} FROM TO
|
||||
rewrite edns0 subnet unset
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.SS "EDNS0 REVERT"
|
||||
.PP
|
||||
Using the \fB\fCrevert\fR flag, you can revert the changes made by this rewrite call, so the response will not contain this option.
|
||||
|
||||
.PP
|
||||
This example sets option, but response will not contain it
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
\&. {
|
||||
rewrite edns0 local set 0xffee abcd revert
|
||||
}
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
The syntax above doesn't cover the multi-line block option for specifying a name request+response rewrite rule described in the \fBResponse Rewrite\fP section.
|
||||
If only some calls contain the \fB\fCrevert\fR flag, then the value in the response will be changed to the previous one. So, in this example, the response will contain \fB\fCabcd\fR data at \fB\fC0xffee\fR
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
\&. {
|
||||
rewrite continue {
|
||||
edns0 local set 0xffee abcd
|
||||
}
|
||||
|
||||
rewrite edns0 local replace 0xffee bcde revert
|
||||
}
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.SH "CNAME FIELD REWRITES"
|
||||
.PP
|
||||
There might be a scenario where you want the \fB\fCCNAME\fR target of the response to be rewritten. You can do this by using the \fB\fCCNAME\fR field rewrite. Answer records preceding the \fB\fCCNAME\fR target are kept unchanged, the \fB\fCCNAME\fR target is rewritten, and the subsequent records are replaced with the lookup result of the rewritten \fB\fCCNAME\fR target.
|
||||
|
||||
.PP
|
||||
The syntax for the \fB\fCCNAME\fR rewrite rule is as follows. The meaning of
|
||||
\fB\fCexact|prefix|suffix|substring|regex\fR is the same as with the name rewrite rules.
|
||||
An omitted type is defaulted to \fB\fCexact\fR.
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite [continue|stop] cname [exact|prefix|suffix|substring|regex] FROM TO
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
Consider the following \fB\fCCNAME\fR rewrite rule with regex type.
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
rewrite cname regex (.*).cdn.example.net. {1}.other.cdn.com.
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
If you were to send the following DNS request without the above rule, an example response would be:
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
$ dig @10.1.1.1 my\-app.com
|
||||
|
||||
;; QUESTION SECTION:
|
||||
;my\-app.com. IN A
|
||||
|
||||
;; ANSWER SECTION:
|
||||
my\-app.com. 200 IN CNAME my\-app.example.
|
||||
my\-app.example. 200 IN CNAME my\-app.com.cdn.example.net.
|
||||
my\-app.com.cdn.example.net. 300 IN A 20.2.0.1
|
||||
my\-app.com.cdn.example.net. 300 IN A 20.2.0.2
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
If you were to send the same DNS request with the above rule set up, an example response would be:
|
||||
|
||||
.PP
|
||||
.RS
|
||||
|
||||
.nf
|
||||
$ dig @10.1.1.1 my\-app.com
|
||||
|
||||
;; QUESTION SECTION:
|
||||
;my\-app.com. IN A
|
||||
|
||||
;; ANSWER SECTION:
|
||||
my\-app.com. 200 IN CNAME my\-app.example.
|
||||
my\-app.example. 200 IN CNAME my\-app.com.other.cdn.com.
|
||||
my\-app.com.other.cdn.com. 100 IN A 30.3.1.2
|
||||
|
||||
.fi
|
||||
.RE
|
||||
|
||||
.PP
|
||||
Note that the answer will contain a completely different set of answer records after rewriting the \fB\fCCNAME\fR target.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user