catalog zone grammar does not enforce default-primaries key / should we support primary zones in catalog?
Summary
Catalog zones grammar in named.conf does not enforce/require default-primaries
key. This can be either bug, or an opportunity to extend the feature in an meaningful way.
BIND version used
Steps to reproduce
- Define catalog zone without
default-primaries
key. E.g.
catalog-zones {
zone "catalog.invalid"
//default-masters { 127.0.0.2; }
in-memory no
zone-directory "catzones"
min-update-interval 1;
};
2a. Start with matching files on disk 2b. Start without matching files on disk
What is the current bug behavior?
The config is accepted by parser but causes surprising behavior later on.
Variant 2A:
The zone is on disk under correct name, and it loads just fine when the file is available in catzones
directory. rndc zonestatus
then reports:
name: .
type: secondary
files: catzones/__catz___default_catalog.invalid_..db
serial: 2023010600
nodes: 8438
last loaded: Fri, 06 Jan 2023 16:03:08 GMT
next refresh: Fri, 06 Jan 2023 16:12:19 GMT
expires: Fri, 13 Jan 2023 16:03:08 GMT
secure: yes
inline signing: no
key maintenance: none
dynamic: no
reconfigurable via modzone: yes
Next time refresh timer hits it errors out with
zone ./IN: cannot refresh: no primaries
but continues serving the zone until it expires. Kind of works, but not so much because it can never refresh and is bound to expire eventually.
Variant 2B: File is not on disk. It fails to load as expected, and logs
zone ./IN: cannot refresh: no primaries
immediately.
Possible fixes
I can see two options:
a) Require the default-primaries
and error out if it is not present. That would be the same as for regular secondary zones, I believe.
b) Make this behavior "supported", probably by switching zone type to "primary" in case there is no default-primaries
defined for the respective catalog. (In that case in-memory
must be configured as no
.)
Personally I think it makes sense to do b) because it eliminates need to have two different per-zone config management procedures for primaries.
I mean - with "strict" variant adding a new primary zone always requires rndc addzone
+ catalog zone modification on the primary side.
With less strict variant rndc addzone
is not necessary and the whole state is in the catalog zone, which is has to be maintained for secondaries anyway.