Newbie's BIND Questions on DNSSEC, HA and SD

Wed Jan 20 00:32:54 UTC 2016

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 that'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 Update. 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 used. Again, like DNSSEC, the devil is in the details, though: do you expect your Apple stuff to be able to update Bonjour resources directly? If so, then you need a way to secure those Dynamic Updates. I can't really speak to this, having not had much exposure to Bonjour, and I don't think BIND has any special accommodations in this regard. Maybe some other DNS packages do (?)

A requirement you *didn't* mention, however, and probably *should*, is: what are the mechanisms and tools for maintaining the DNS data and configurations in the environment? BIND is an open-source package, but it doesn't really provide its own GUI, or console, for instance, for managing DNS data and configurations. Were you thinking you'd just manually edit zone files and named.conf? That can get old real fast. A lot of commercial products are built on BIND (e.g. Infoblox and Blue Cat, to name a couple), and BIND can be front-ended with open source tools too (Webmin has been mentioned, although I've never used it personally) and these tools provide such functionality. I think you'll find that, while the initial implementation of a DNS environment can be rather manpower-intensive, in the long term, the care and feeding of a DNS environment will take a lot more of your time, unless you have powerful tools to help manage it. So, you should be looking not only at the core DNS package to use on your network, but also at the management layer you're going to use with that core, since different combinations of core-software and management layer work better or worse with each other.

Lastly, another thing you didn't mention is integration between DNS and DHCP. Don't your clients use DHCP, and don't you want records populated automatically in DNS when they get a lease, and removed when the lease is gone? I suppose it's _possible_ that you don't use DHCP, or you don't care about having your client names automatically populate DNS, but this would be rather atypical. It's worth noting, I think, that the prevailing DHCP server software comes from the same organization (ISC) as maintains BIND, so these pieces work well together (which is not to suggest that ISC's DHCP server *can't* work with, say, PowerDNS and so forth, but just that there are more examples and "mindshare" out there for getting the ISC stuff to work together). Some of the aforementioned commercial products, e.g. Infoblox, provide both DNS and DHCP services, among others, and DNS and DHCP can be very tightly integrated with each other, within those products.

																			- Kevin

P.S. Re-reading my message, I realize it may sound like a bit of an advertisement for a commercial DDI (DNS, DHCP and IPAM) solution, e.g. Infoblox. But, having made the transition from a fairly "classic" BIND installation, with a significant amount of custom programming wrapped around it, to a commercial-DDI solution, with the remaining custom programming just a front-end to it, I can attest to the manageability and integration benefits. It's especially useful if one wants to run more advanced features like DNSSEC, Anycast, reputation-based blacklisting of C&C sites, DoS mitigation strategies, meaningful mining of query stats, integration with Active Directory's "sites and subnets" mechanism, etc. I shudder to think how much time and effort would be involved in creating those things from scratch, and/or cobbling together open source tools to make all of that work.

-----Original Message-----
From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of David Li
Sent: Sunday, January 17, 2016 12:34 AM
To: bind-users at lists.isc.org
Subject: Newbie's BIND Questions on DNSSEC, HA and SD

Hi,

I am new to BIND. I am researching for a DNS server that can meet a list of requirements to be used in  a distributed system. They are:

1. Security (DNSSEC)
2. High Availability (HA)
3. Service Discovery (DNS-SD)

So I think BIND might be my best choice so far. Others I have looked at include dnsmasq, unbound, PowerDNS etc.

Because I don't have real experience with BIND yet and our architecture hasn't been finalized, I am asking the community experts for validations on my conclusion.

Another question I haven't quite figured out is the HA architecture.
Is it possible to set up a cluster of BIND servers (> 2) for each VLAN subnet with one of them as master the rest as slaves?

Thanks!

David
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users