2016-03-27 07:37:23 +01:00
|
|
|
# file
|
|
|
|
|
|
2016-08-22 14:12:03 -07:00
|
|
|
`file` enables serving zone data from an RFC 1035-style master file.
|
2016-03-27 07:37:23 +01:00
|
|
|
|
2016-08-22 14:12:03 -07:00
|
|
|
The file middleware is used for an "old-style" DNS server. It serves from a preloaded file that exists
|
2016-08-29 19:15:04 +01:00
|
|
|
on disk. If the zone file contains signatures (i.e. is signed, i.e. DNSSEC) correct DNSSEC answers
|
|
|
|
|
are returned. Only NSEC is supported! If you use this setup *you* are responsible for resigning the
|
|
|
|
|
zonefile.
|
2016-03-27 07:37:23 +01:00
|
|
|
|
|
|
|
|
## Syntax
|
|
|
|
|
|
|
|
|
|
~~~
|
|
|
|
|
file dbfile [zones...]
|
|
|
|
|
~~~
|
|
|
|
|
|
|
|
|
|
* `dbfile` the database file to read and parse.
|
2016-08-22 14:12:03 -07:00
|
|
|
* `zones` zones it should be authoritative for. If empty, the zones from the configuration block
|
2016-03-27 07:37:23 +01:00
|
|
|
are used.
|
|
|
|
|
|
2016-03-28 12:08:05 +01:00
|
|
|
If you want to round robin A and AAAA responses look at the `loadbalance` middleware.
|
2016-03-27 07:37:23 +01:00
|
|
|
|
2016-04-03 09:02:34 +01:00
|
|
|
TSIG key configuration is TODO; directive format for transfer will probably be extended with
|
2016-04-14 19:57:39 +01:00
|
|
|
TSIG key information, something like `transfer out [address...] key [name] [base64]`
|
2016-04-03 07:37:41 +01:00
|
|
|
|
2016-03-27 07:37:23 +01:00
|
|
|
~~~
|
2016-03-28 12:08:05 +01:00
|
|
|
file dbfile [zones... ] {
|
2016-04-14 19:57:39 +01:00
|
|
|
transfer to [address...]
|
2016-04-15 14:26:27 +01:00
|
|
|
no_reload
|
2016-03-27 07:37:23 +01:00
|
|
|
}
|
|
|
|
|
~~~
|
|
|
|
|
|
2016-04-03 09:02:34 +01:00
|
|
|
* `transfer` enables zone transfers. It may be specified multiples times. *To* or *from* signals
|
2016-09-18 09:32:06 +01:00
|
|
|
the direction. Addresses must be denoted in CIDR notation (127.0.0.1/32 etc.) or just as plain
|
|
|
|
|
addresses. The special wildcard `*` means: the entire internet (only valid for 'transfer to').
|
|
|
|
|
When an address is specified a notify message will be send whenever the zone is reloaded.
|
2016-04-15 14:26:27 +01:00
|
|
|
* `no_reload` by default CoreDNS will reload a zone from disk whenever it detects a change to the
|
|
|
|
|
file. This option disables that behavior.
|
2016-03-27 07:37:23 +01:00
|
|
|
|
|
|
|
|
## Examples
|
2016-04-03 09:02:34 +01:00
|
|
|
|
2016-09-18 09:32:06 +01:00
|
|
|
Load the `example.org` zone from `example.org.signed` and allow transfers to the internet, but send
|
|
|
|
|
notifies to 10.240.1.1
|
2016-04-03 09:02:34 +01:00
|
|
|
|
|
|
|
|
~~~
|
2016-09-18 09:32:06 +01:00
|
|
|
file example.org.signed example.org {
|
2016-04-03 09:02:34 +01:00
|
|
|
transfer to *
|
2016-09-18 09:32:06 +01:00
|
|
|
transfer to 10.240.1.1
|
2016-04-03 09:02:34 +01:00
|
|
|
}
|
|
|
|
|
~~~
|