Your post is a little difficult to respond to, due to lack of detail on each of
your enumerated points.
For instance, "DNSSEC" is a fairly broad topic, and all major DNS
implementations support the record types (RRSIG, DNSKEY, DS and so forth)
necessary to support validation and the "chain of trust". But, the devil is in
the details, e.g. how flexible and well-performing are the mechanisms and/or
tools provided for validation, for on-line signing, for key rollover, etc.?
This requires a fairly detailed understanding and experience of DNSSEC
operational details, and I'm not sure you'll find many people who have this, as
applied to multiple product suites like BIND, unbound, PowerDNS and so forth.
It's possible, I suppose.
For "HA", Anycast has already been mentioned as a way to provide robust DNS
service, with automatic failover. Most private enterprises, if they use Anycast
at all, only do so for *recursive* service, since that's where the bulk of the
DNS query traffic occurs, and stub-resolver failover incurs a significant
performance penalty, which implementors seek to negate. But, there's no reason
why Anycast can't be used for *authoritative* service as well, just as is done
for root and/or gTLD servers on the public Internet. The big downside to
Anycast, of course, is that it requires close co-ordination with your routing
infrastructure and the people who run it. Depending on the organization, this
may be a significant challenge. In the absence of Anycast, at least some level
of transparent failover can be achieved, for DNS as it is for other services
(typically HTTP/HTTPS) using LSLB (Local Server Load Balancing). Note that GSLB
(Global Server Load Balancing) relies on DNS itself, so th
at's a chicken-and-egg situation, which means you *cannot* use it for
providing high-availability to DNS services. But, with LSLB, you can at least
eliminate the "failover penalty" associated with a single-node failure. I think
this is what you were hinting at by "clustering", but the term "clustering"
usually implies a server-based methodology, whereas LSLB is a more generic
term, and the function can be provided by dedicated network devices (if
available).
As others have mentioned, however, unless you have a really small number of
really busy subnets, it wouldn't likely be economically feasible to have
multiple DNS instances on every subnet. You could easily end up with dozens of
DNS instances that way, and how do you manage all of that (I expand further on
that, below)?
You mentioned having one master and multiple slaves in each of these per-subnet
"clusters", and I'm wondering why you would think you would need that. Are you
envisioning that each subnet has its own dedicated zone? That too seems like
overkill. You may not have thought through your DNS namespace hierarchy yet,
but generally speaking, location-based naming schemes go down to the "campus"
level, if that. One zone per subnet seems rather excessive, for "forward"
names, although it may make sense for your "reverse" namespace, especially with
IPv4 and where your subnets are divvied up on 8-bit boundaries (e.g. /24 or
/16). Just because a zone may be subnet-specific, though, doesn't imply that
the master server for the zone needs to be *on* the subnet, however. Usually,
it doesn't hurt performance much for a DNS caching resolver to be a few network
hops away from its stub-resolver clients, or for a DNS master server to be a
few hops away from a client that updates it via Dynamic U
pdate. In the DNS realm, one usually gets better performance results by
focusing on *availability* (because of the aforementioned stub-resolver
"failover penalty"), rather than nickle-and-dime'ing a few network hops here
and there (caveat: this assumes relatively fast links; I suppose, if your
network hops are _really_ slow, you might need to focus on minimizing them. If
network hops *really* matter, then, again, you should look long and hard at
Anycast as the most efficient way to provide service, despite the steep initial
learning curve and the possible co-ordination challenges). Does replication of
DNS data towards the clients which query it -- via the classic master/slave
replication or something else -- also help performance? You bet it does. So, I
think you're on the right track to be thinking about it. Just be aware that
maintaining a bunch of master/slave configuration elements, or the equivalent
in non-standards-defined replication mechanisms, can be a chore in and
of itself, especially if you want to set things up so that changes made at the
master replicate quickly (using the NOTIFY extension or something else).
Lastly, you mention "DNS-SD". I'm assuming you're referring to the
Apple-oriented "Bonjour" stuff specified in RFC 6763 (?) Apparently you have a
lot of Apple gear. I gather that there's not a lot of "special" DNS-server
requirements for that -- standard record types like PTR, SRV and TXT are
