mirror of
https://github.com/coredns/coredns.git
synced 2025-11-03 10:43:20 -05:00
168 lines
3.3 KiB
Groff
168 lines
3.3 KiB
Groff
.\" Generated by Mmark Markdown Processer - mmark.miek.nl
|
|
.TH "COREDNS-FILE" 7 "March 2021" "CoreDNS" "CoreDNS Plugins"
|
|
|
|
.SH "NAME"
|
|
.PP
|
|
\fIfile\fP - enables serving zone data from an RFC 1035-style master file.
|
|
|
|
.SH "DESCRIPTION"
|
|
.PP
|
|
The \fIfile\fP plugin is used for an "old-style" DNS server. It serves from a preloaded file that exists
|
|
on disk contained RFC 1035 styled data. If the zone file contains signatures (i.e., is signed using
|
|
DNSSEC), correct DNSSEC answers are returned. Only NSEC is supported! If you use this setup \fIyou\fP
|
|
are responsible for re-signing the zonefile.
|
|
|
|
.SH "SYNTAX"
|
|
.PP
|
|
.RS
|
|
|
|
.nf
|
|
file DBFILE [ZONES...]
|
|
|
|
.fi
|
|
.RE
|
|
|
|
.IP \(bu 4
|
|
\fBDBFILE\fP the database file to read and parse. If the path is relative, the path from the \fIroot\fP
|
|
plugin will be prepended to it.
|
|
.IP \(bu 4
|
|
\fBZONES\fP zones it should be authoritative for. If empty, the zones from the configuration block
|
|
are used.
|
|
|
|
|
|
.PP
|
|
If you want to round-robin A and AAAA responses look at the \fIloadbalance\fP plugin.
|
|
|
|
.PP
|
|
.RS
|
|
|
|
.nf
|
|
file DBFILE [ZONES... ] {
|
|
reload DURATION
|
|
}
|
|
|
|
.fi
|
|
.RE
|
|
|
|
.IP \(bu 4
|
|
\fB\fCreload\fR interval to perform a reload of the zone if the SOA version changes. Default is one minute.
|
|
Value of \fB\fC0\fR means to not scan for changes and reload. For example, \fB\fC30s\fR checks the zonefile every 30 seconds
|
|
and reloads the zone when serial changes.
|
|
|
|
|
|
.PP
|
|
If you need outgoing zone transfers, take a look at the \fItransfer\fP plugin.
|
|
|
|
.SH "EXAMPLES"
|
|
.PP
|
|
Load the \fB\fCexample.org\fR zone from \fB\fCdb.example.org\fR and allow transfers to the internet, but send
|
|
notifies to 10.240.1.1
|
|
|
|
.PP
|
|
.RS
|
|
|
|
.nf
|
|
example.org {
|
|
file db.example.org
|
|
transfer {
|
|
to * 10.240.1.1
|
|
}
|
|
}
|
|
|
|
.fi
|
|
.RE
|
|
|
|
.PP
|
|
Where \fB\fCdb.example.org\fR would contain RRSets (https://tools.ietf.org/html/rfc7719#section-4
|
|
\[la]https://tools.ietf.org/html/rfc7719#section-4\[ra]) in the
|
|
(text) presentation format from RFC 1035:
|
|
|
|
.PP
|
|
.RS
|
|
|
|
.nf
|
|
$ORIGIN example.org.
|
|
@ 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2017042745 7200 3600 1209600 3600
|
|
3600 IN NS a.iana\-servers.net.
|
|
3600 IN NS b.iana\-servers.net.
|
|
|
|
www IN A 127.0.0.1
|
|
IN AAAA ::1
|
|
|
|
.fi
|
|
.RE
|
|
|
|
.PP
|
|
Or use a single zone file for multiple zones:
|
|
|
|
.PP
|
|
.RS
|
|
|
|
.nf
|
|
\&. {
|
|
file example.org.signed example.org example.net
|
|
transfer example.org example.net {
|
|
to * 10.240.1.1
|
|
}
|
|
}
|
|
|
|
.fi
|
|
.RE
|
|
|
|
.PP
|
|
Note that if you have a configuration like the following you may run into a problem of the origin
|
|
not being correctly recognized:
|
|
|
|
.PP
|
|
.RS
|
|
|
|
.nf
|
|
\&. {
|
|
file db.example.org
|
|
}
|
|
|
|
.fi
|
|
.RE
|
|
|
|
.PP
|
|
We omit the origin for the file \fB\fCdb.example.org\fR, so this references the zone in the server block,
|
|
which, in this case, is the root zone. Any contents of \fB\fCdb.example.org\fR will then read with that
|
|
origin set; this may or may not do what you want.
|
|
It's better to be explicit here and specify the correct origin. This can be done in two ways:
|
|
|
|
.PP
|
|
.RS
|
|
|
|
.nf
|
|
\&. {
|
|
file db.example.org example.org
|
|
}
|
|
|
|
.fi
|
|
.RE
|
|
|
|
.PP
|
|
Or
|
|
|
|
.PP
|
|
.RS
|
|
|
|
.nf
|
|
example.org {
|
|
file db.example.org
|
|
}
|
|
|
|
.fi
|
|
.RE
|
|
|
|
.SH "SEE ALSO"
|
|
.PP
|
|
See the \fIloadbalance\fP plugin if you need simple record shuffling. And the \fItransfer\fP plugin for zone
|
|
transfers. Lastly the \fIroot\fP plugin can help you specify the location of the zone files.
|
|
|
|
.PP
|
|
See RFC 1035
|
|
\[la]https://www.rfc-editor.org/rfc/rfc1035.txt\[ra] for more info on how to structure zone
|
|
files.
|
|
|