2016-04-03 09:02:34 +01:00
|
|
|
# secondary
|
|
|
|
|
|
2018-01-04 12:53:07 +00:00
|
|
|
## Name
|
2016-04-03 09:02:34 +01:00
|
|
|
|
2018-01-04 12:53:07 +00:00
|
|
|
*secondary* - enables serving a zone retrieved from a primary server.
|
|
|
|
|
|
|
|
|
|
## Description
|
|
|
|
|
|
|
|
|
|
With *secondary* you can transfer (via AXFR) a zone from another server. The retrieved zone is
|
|
|
|
|
*not committed* to disk (a violation of the RFC). This means restarting CoreDNS will cause it to
|
2019-12-29 13:35:17 +01:00
|
|
|
retrieve all secondary zones.
|
2016-04-03 09:02:34 +01:00
|
|
|
|
2021-06-11 19:54:49 +02:00
|
|
|
If the primary server(s) don't respond when CoreDNS is starting up, the AXFR will be retried
|
|
|
|
|
indefinitely every 10s.
|
|
|
|
|
|
2020-01-31 12:37:24 +01:00
|
|
|
## Syntax
|
|
|
|
|
|
2016-04-03 09:02:34 +01:00
|
|
|
~~~
|
2016-10-10 20:13:22 +01:00
|
|
|
secondary [ZONES...]
|
2016-04-03 09:02:34 +01:00
|
|
|
~~~
|
|
|
|
|
|
2016-10-10 20:13:22 +01:00
|
|
|
* **ZONES** zones it should be authoritative for. If empty, the zones from the configuration block
|
2016-08-22 14:40:24 -07:00
|
|
|
are used. Note that without a remote address to *get* the zone from, the above is not that useful.
|
2016-04-03 09:02:34 +01:00
|
|
|
|
|
|
|
|
A working syntax would be:
|
|
|
|
|
|
|
|
|
|
~~~
|
|
|
|
|
secondary [zones...] {
|
2021-01-10 11:06:28 +01:00
|
|
|
transfer from ADDRESS [ADDRESS...]
|
2026-07-30 09:11:36 +08:00
|
|
|
catalog [MEMBER-ZONES...]
|
2026-05-20 10:13:03 +03:00
|
|
|
fallthrough [ZONES...]
|
2016-04-03 09:02:34 +01:00
|
|
|
}
|
|
|
|
|
~~~
|
|
|
|
|
|
2021-01-10 11:06:28 +01:00
|
|
|
* `transfer from` specifies from which **ADDRESS** to fetch the zone. It can be specified multiple
|
2021-04-05 21:34:25 +08:00
|
|
|
times; if one does not work, another will be tried. Transferring this zone outwards again can be
|
2021-01-10 11:06:28 +01:00
|
|
|
done by enabling the *transfer* plugin.
|
2016-04-03 09:02:34 +01:00
|
|
|
|
2026-07-10 08:42:30 +08:00
|
|
|
* `catalog` 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
|
2026-07-30 09:11:36 +08:00
|
|
|
the same primary servers. Optional **MEMBER-ZONES** restrict which member zone names are accepted;
|
|
|
|
|
each name also matches its subdomains. With no **MEMBER-ZONES**, 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 `coo` 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.
|
2026-07-05 08:06:05 +08:00
|
|
|
|
2026-05-20 10:13:03 +03:00
|
|
|
* `fallthrough` 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 **[ZONES...]** 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.
|
|
|
|
|
|
2021-01-10 11:06:28 +01:00
|
|
|
When a zone is due to be refreshed (refresh timer fires) a random jitter of 5 seconds is applied,
|
|
|
|
|
before fetching. In the case of retry this will be 2 seconds. If there are any errors during the
|
|
|
|
|
transfer in, the transfer fails; this will be logged.
|
2018-01-23 10:35:10 +00:00
|
|
|
|
2016-04-03 09:02:34 +01:00
|
|
|
## Examples
|
|
|
|
|
|
2017-09-10 19:52:15 +01:00
|
|
|
Transfer `example.org` from 10.0.1.1, and if that fails try 10.1.2.1.
|
|
|
|
|
|
|
|
|
|
~~~ corefile
|
|
|
|
|
example.org {
|
|
|
|
|
secondary {
|
2020-09-24 11:30:39 -07:00
|
|
|
transfer from 10.0.1.1 10.1.2.1
|
2017-09-10 19:52:15 +01:00
|
|
|
}
|
|
|
|
|
}
|
2016-04-03 09:02:34 +01:00
|
|
|
~~~
|
2017-09-10 19:52:15 +01:00
|
|
|
|
|
|
|
|
Or re-export the retrieved zone to other secondaries.
|
|
|
|
|
|
|
|
|
|
~~~ corefile
|
2020-09-24 11:30:39 -07:00
|
|
|
example.net {
|
|
|
|
|
secondary {
|
2017-09-10 19:52:15 +01:00
|
|
|
transfer from 10.1.2.1
|
2020-09-24 11:30:39 -07:00
|
|
|
}
|
|
|
|
|
transfer {
|
|
|
|
|
to *
|
2017-09-10 19:52:15 +01:00
|
|
|
}
|
2016-04-03 09:02:34 +01:00
|
|
|
}
|
|
|
|
|
~~~
|
2018-01-04 12:53:07 +00:00
|
|
|
|
2026-07-30 09:11:36 +08:00
|
|
|
Restrict a catalog consumer to member zones at or below `example.org` and `internal.example`.
|
|
|
|
|
|
|
|
|
|
~~~ corefile
|
|
|
|
|
catalog.example {
|
|
|
|
|
secondary {
|
|
|
|
|
transfer from 10.1.2.1
|
|
|
|
|
catalog example.org internal.example
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
~~~
|
|
|
|
|
|
2018-01-10 11:45:12 +00:00
|
|
|
## Bugs
|
2018-01-04 12:53:07 +00:00
|
|
|
|
|
|
|
|
Only AXFR is supported and the retrieved zone is not committed to disk.
|
2020-09-24 11:30:39 -07:00
|
|
|
|
2020-10-28 18:56:35 +01:00
|
|
|
## See Also
|
2020-09-24 11:30:39 -07:00
|
|
|
|
|
|
|
|
See the *transfer* plugin to enable zone transfers _to_ other servers.
|
2026-07-30 09:11:36 +08:00
|
|
|
RFC 5936 details the AXFR protocol, and RFC 9432 defines DNS catalog zones.
|