securing bind in todays hostile environment

[N. Max Pierson]

Hi List,

First off, I should note that I am a novice with administering Bind, so please bear with me. 

We are looking to be more pro-active and security minded in our network in general and while we are getting ready to completely replace/upgrade our current instances of Bind, I would like to hear of opinions of the following ansible role that would install, setup, configure, etc our instances taking security into account. I have read some of the common best practices on this very list over time but wanted to ensure what was in this role wasn't missing anything in terms of securing the deployment. 

So I am aware it’s preferred to split recursive and authoritative services across different instances. I also understand it’s preferred to use one of the “out of zone” (apologies for not knowing the proper terminology) master methods (such as hidden or shadow master). It’s also a very good idea to deploy TSIG for transaction signing. And of course, ACL recursive lookups as well as AXFRs. Beyond that, what other best practices should be considered when making a deployment such as the following scenario ….

ns1 - ns4: authoritative name servers - slaves
ns0 - hidden/shadow master

old ns1- ns4: will be used as recursive as these were deployed doing both authoritative and recursive many years ago and policy routing for these old IPs is very ugly, so we would like to keep them there after an upgrade as opposed to try and figure out who’s still using them to notify we’re changing the IPs


The ansible role can be seen here at https://github.com/juju4/ansible-bind <https://github.com/juju4/ansible-bind> . So you don’t have to click on the link, what this role does to secure bind in summary is as follows:

- Secure template from Team Cymru template (http://www.cymru.com/Documents/secure-bind-template.html). Please note than separated internal/external views are not implemented currently.
- DNSSEC for authentication,
- RPZ to whitelist/blacklist entries
- Malware domains list blackholed
- Eventual integration with MISP RPZ export
- Authoritative DNS (mostly for internal zones) Mostly as cache/forwarder but could be other roles.

Taking into consideration what I have already learned plus the few things above mentioned on GitHub (mainly the security template and malware domain blackhole as we do not use RPZ or Views), is there anything else that should be considered/added/changed/removed to/from the defaults of this role when we go to deploy the above scenario? 

TIA,
m
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200118/74956822/attachment.htm>