Maintain task frequency

[/dev/rob0]

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: