On Tue, May 10, 2016 at 10:09:09AM -0500, Jorge Alberto Martínez Melo wrote: > It seems that my maintain proposed tasks are unnecessary. > Furthermore occasional backups and updates, in your opinion what > are frequent necessary maintain tasks for a cache dns server.
The answer depends on the importance of these servers to your company's mission. As you seem to be from an ISP, I'll assume they're critical, that you'd be getting phone calls from paying customers within minutes of an outage. First I'd say you need monitoring. Don't wait for the phone calls, which are going to have to be filtered through first-level support before the DNS team is alerted. Your NOC needs to know immediately when there is a crash or other outage. (For that matter, so does first-level support; they need to be prepared for the question and to sound like they know what they're talking about.) Second, I'd strongly recommend diversity. As much as we all love BIND9 here, don't put all your resolver eggs in that basket (please forgive the idiomatic expression, but I think you can figure out the meaning.) Consider pdns-recursor and unbound, for example, to augment your BIND resolver farm. Third, I'd use an anycast arrangement to keep things simple for the user and to provide a kind of failover. One or two IP addresses can be answered by any number of nameservers. Fourth, consider a BIND ASN subscription agreement. This way you will be alerted prior to public disclosure of any BIND security issue, and you'll get the patched code in advance of public release. (Disclaimer: I am not affiliated with ISC.) Four-and-a-half: even if you choose not to go with the ASN contract, stay alert and ready to patch when an issue is announced. Know how to build from source for your platform and how to quickly deploy upgrades across your farm. Automation tools such as ansible or salt can help here. Fifth: while it generally doesn't hurt to serve a few authoritative zones to your users through the resolvers, the resolvers should NOT be published as NS for any zone, and they should NOT be reachable from outside your networks. In fact a little internal isolation might be useful too: a division of your networks into chunks, each with its own set of resolvers, and blocked from other chunks. See also the ISC KB article on best practices for resolvers. I probably missed something, but that's a good start. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
