Mirrors/coredns
1
0
Fork 0
mirror of https://github.com/coredns/coredns.git synced 2026-10-27 12:45:43 -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

69
man/coredns-hosts.7
View File

@@ -1,5 +1,5 @@
.\" Generated by Mmark Markdown Processer - mmark.miek.nl
.TH "COREDNS-HOSTS" 7 "March 2026" "CoreDNS" "CoreDNS Plugins"
.TH "COREDNS-HOSTS" 7 "October 2026" "CoreDNS" "CoreDNS Plugins"
.SH "NAME"
.PP
@@ -45,6 +45,41 @@ fdfc:a744:27b5:3b0e::1 example.com example
.fi
.RE
.SS "WILDCARD RECORDS"
.PP
Owner names may use a \fB\fC*\fR as the leftmost label to match one additional label below
that name. This follows the same wildcard semantics as the \fIfile\fP plugin.
.PP
Examples:
.PP
.RS
.nf
192.168.1.10 *.example.com
192.168.1.11 a.example.com
192.168.1.12 b.example.com
.fi
.RE
.PP
With the entries above:
.IP \(bu 4
\fB\fCa.example.com\fR and \fB\fCb.example.com\fR resolve to their explicit addresses.
.IP \(bu 4
\fB\fCapps.example.com\fR resolves to \fB\fC192.168.1.10\fR.
.IP \(bu 4
\fB\fCexample.com\fR does not match the wildcard (the zone apex is excluded).
.IP \(bu 4
\fB\fCdeep.apps.example.com\fR does not match \fB\fC*.example.com\fR (only one label is matched).
.PP
Wildcard entries do not generate PTR records.
.SS "PTR RECORDS"
.PP
PTR records for reverse lookups are generated automatically by CoreDNS (based on the hosts file
@@ -61,6 +96,7 @@ hosts [FILE [ZONES...]] {
no\_reverse
reload DURATION
fallthrough [ZONES...]
fallthrough\_unsupported
}
.fi
@@ -91,6 +127,13 @@ time
If \fB[ZONES...]\fP is omitted, then fallthrough happens for all zones for which the plugin
is authoritative. If specific zones are listed (for example \fB\fCin-addr.arpa\fR and \fB\fCip6.arpa\fR), then only
queries for those zones will be subject to fallthrough.
By default, queries for unsupported record types return an authoritative NODATA response when
the queried name has an A or AAAA entry in the hosts data.
.IP \(bu 4
\fB\fCfallthrough_unsupported\fR extends \fB\fCfallthrough\fR to unsupported query types when the queried name
exists in the hosts data. For example, TXT, HTTPS, and SVCB queries for a name with an A or AAAA
entry are passed to the next plugin. If that plugin is \fIforward\fP, these queries are sent upstream.
This option requires \fB\fCfallthrough\fR and uses the same zone scope.
.SH "METRICS"
@@ -167,9 +210,29 @@ example.hosts example.org {
.fi
.RE
.PP
Resolve all single-label subdomains of \fB\fCexample.com\fR to one address, with explicit
exceptions, and fall through for everything else under \fB\fCexample.com\fR.
.PP
.RS
.nf
\&. {
hosts example.hosts example.com {
192.168.1.10 *.example.com
192.168.1.11 www.example.com
fallthrough example.com
}
forward . 8.8.8.8
}
.fi
.RE
.SH "SEE ALSO"
.PP
The form of the entries in the \fB\fC/etc/hosts\fR file are based on IETF RFC 952
\[la]https://tools.ietf.org/html/rfc952\[ra] which was updated by IETF RFC 1123
\[la]https://tools.ietf.org/html/rfc1123\[ra].
\[la]https://www.rfc-editor.org/info/rfc952/\[ra] which was updated by IETF RFC 1123
\[la]https://www.rfc-editor.org/info/rfc1123/\[ra].