I'll start by saying that I have not tried out catalog zones properly yet.
This review is from the point of view of how I currently manage my
configurations.
(Aside: there should probably be a copy of the draft in the BIND
distribution in doc/draft/.)
There is a lot of TBD in this draft which makes it hard to give a
meaningful review.
There's a big section mapping abstract configuration to DNS master file
syntax, which seems OK.
However, there doesn't seem to be anything about what member zone
properties are available and what they mean - I would expect them to be in
section 2.9 but that is almost empty.
There's a bit more in the latest BIND 9.11 ARM. This amounts to being able
to set the default-masters server addresses in named.conf, which can be
overridden by a global masters setting inside the catalog zone, which can
be overridden by per-member-zone masters settings.
(Aside: the BIND 9.11 release notes refer to chapter 9 of the ARM which I
think should be section 4.14.)
In my current configuration I have a two-level setup: the automatically
managed zone configuration (which would ideally be one or more catalog
zones in the future), and some more hands-on config for things like ACLs
and lists of masters. The zone configs just use names, e.g.
zone cam.ac.uk {
type slave; file "/zone/cam.ac.uk";
masters { master-ipreg; };
allow-transfer { secondaries; };
allow-query { any; };
also-notify { notify-isc; };
};
The relevance for catalog zones is that indirect ACLs with names make it
easy to support secure zone transfer of the catalog zone without exposing
the TSIG keys used by the member zones. And using names for the other
settings gives us a sort of templated zone config.
For instance, for my public zones on my authoritative servers, the
allow-transfer ACL includes our local IP addresses, and TSIG keys for
ic.ac.uk and isc.org; if we could all use the same catalog zone then
ic.ac.uk could define their version of my ACL as "none" and isc.org could
define it to cover their anycast cloud.
... Having written that I have second thoughts because the coupling
between ACL names and third-party catalog zone contents is probably a
really bad idea :-)
Maybe for my own cluster I want really rich catalog zones, but if I'm
slaving a catz from a third party I want the member zone configurations to
be firmly pinned down.
Tony.
--
f.anthony.n.finch <[email protected]> http://dotat.at/ - I xn--zr8h punycode
Fisher: East 4 or 5, occasionally 6 later. Slight or moderate. Showers. Good,
occasionally poor.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
