plugin/file: reject SOA owners that do not match the zone (#8555)

Signed-off-by: houyuwushang <liuluoqianqiu@outlook.com>
This commit is contained in:
houyuwushang
2026-09-17 08:49:58 +08:00
committed by GitHub
parent 73198897ef
commit 84a93a0b89
10 changed files with 302 additions and 29 deletions

View File

@@ -22,6 +22,12 @@ file DBFILE [ZONES...]
* **ZONES** zones it should be authoritative for. If empty, the zones from the configuration block
are used.
The SOA record's owner name must match the zone being loaded. Names without a final dot are
relative to the current origin; for example, `test` in a zone loaded as `test.` becomes
`test.test.`, not `test.`. Use `@` (when the current origin matches the zone) or the zone's
absolute name for the SOA owner. A mismatched SOA causes loading to fail; an invalid reload
leaves the last successfully loaded zone in service.
If you want to round-robin A and AAAA responses look at the *loadbalance* plugin.
~~~
@@ -72,17 +78,28 @@ www IN A 127.0.0.1
~~~
Or use a single zone file for multiple zones:
Or use a single zone file for multiple zones, with relative owner names and no fixed `$ORIGIN`:
~~~ corefile
. {
file example.org.signed example.org example.net
file db.shared example.org example.net
transfer example.org example.net {
to * 10.240.1.1
}
}
~~~
For example, `db.shared` can contain:
~~~
@ 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2017042745 7200 3600 1209600 3600
@ 3600 IN NS a.iana-servers.net.
www 3600 IN A 127.0.0.1
~~~
Each configured zone is used as the initial origin when parsing this file, so `@` is its apex.
Signed zones require signatures for the actual owner names and must be signed separately.
Note that if you have a configuration like the following you may run into a problem of the origin
not being correctly recognized:
@@ -93,9 +110,9 @@ not being correctly recognized:
~~~
We omit the origin for the file `db.example.org`, so this references the zone in the server block,
which, in this case, is the root zone. Any contents of `db.example.org` 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:
which, in this case, is the root zone. A file with an SOA for `example.org.` will be rejected
because it does not match the configured root zone, even if the file sets `$ORIGIN example.org.`.
Specify the correct zone in one of two ways:
~~~ corefile
. {