Mirrors/coredns
1
0
Fork 0
mirror of https://github.com/coredns/coredns.git synced 2026-10-28 05:05:44 -04:00
Code Issues Packages Projects Releases Wiki Activity

Improve RFC links (#8612)

Browse Source 
The `tools.ietf.org` site now redirects to `www.rfc-editor.org`.
* Update various URLs to the new site.
* Make links to `www.rfc-editor.org` consistent.

Signed-off-by: SuperQ <superq@gmail.com>
This commit is contained in:
Ben Kochie
2026-10-08 10:21:06 +02:00
committed by GitHub
parent 763bdb9b76
commit 311a9915da
60 changed files with 1006 additions and 215 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
man/coredns-secondary.7
View File

@@ -1,5 +1,5 @@
.\" Generated by Mmark Markdown Processer - mmark.miek.nl
.TH "COREDNS-SECONDARY" 7 "March 2026" "CoreDNS" "CoreDNS Plugins"
.TH "COREDNS-SECONDARY" 7 "October 2026" "CoreDNS" "CoreDNS Plugins"
.SH "NAME"
.PP
@@ -39,6 +39,8 @@ A working syntax would be:
.nf
secondary [zones...] {
transfer from ADDRESS [ADDRESS...]
catalog [MEMBER\-ZONES...]
fallthrough [ZONES...]
}
.fi
@@ -48,6 +50,21 @@ secondary [zones...] {
\fB\fCtransfer from\fR specifies from which \fBADDRESS\fP to fetch the zone. It can be specified multiple
times; if one does not work, another will be tried. Transferring this zone outwards again can be
done by enabling the \fItransfer\fP plugin.
.IP \(bu 4
\fB\fCcatalog\fR treats the transferred zone as an RFC 9432 catalog zone. After each successful catalog
transfer, CoreDNS adds and removes the catalog member zones and transfers those member zones from
the same primary servers. Optional \fBMEMBER-ZONES\fP restrict which member zone names are accepted;
each name also matches its subdomains. With no \fBMEMBER-ZONES\fP, all member zones are accepted for
backward compatibility. RFC 9432 Section 7 recommends configuring this restriction because a
catalog producer otherwise controls which zones the consumer serves. A member in another catalog
remains a name clash unless the current catalog's \fB\fCcoo\fR property points to the newly updated
catalog. During that ownership migration, CoreDNS preserves the current zone data only when both
catalogs use the same member node label.
.IP \(bu 4
\fB\fCfallthrough\fR If a query for a record in the zone results in NXDOMAIN, the query will be passed
to the next plugin in the chain. If \fB[ZONES...]\fP are listed, then only queries for those zones
will be subject to fallthrough. This can be useful in split DNS setups where the secondary zone
contains only partial records.
.PP
@@ -91,6 +108,23 @@ example.net {
.fi
.RE
.PP
Restrict a catalog consumer to member zones at or below \fB\fCexample.org\fR and \fB\fCinternal.example\fR.
.PP
.RS
.nf
catalog.example {
secondary {
transfer from 10.1.2.1
catalog example.org internal.example
}
}
.fi
.RE
.SH "BUGS"
.PP
Only AXFR is supported and the retrieved zone is not committed to disk.
@@ -98,5 +132,5 @@ Only AXFR is supported and the retrieved zone is not committed to disk.
.SH "SEE ALSO"
.PP
See the \fItransfer\fP plugin to enable zone transfers \fIto\fP other servers.
And RFC 5936 detailing the AXFR protocol.
RFC 5936 details the AXFR protocol, and RFC 9432 defines DNS catalog zones.