Hi Grant, A couple of things ….
I should have been a little more descriptive in the scenario by giving the purpose of these name servers. They are basically being deployed as a managed DNS service that we offer. We are a MSP for the most part and the DNS infrastructure was not being very well maintained when I got here. Knowing that and the fact we sell this as a service, it needs more attention that it has gotten in the past plus someone with more knowledge than the ones that originally set them up. Having that said, I have my work cut out for me. > One thing that I couldn't tell from your description is if you need to > support dynamic updates from clients. We do not use dynamic entries and as far as the hidden/shadow master, I do not have an issue with the master being on the public segment and part of the NS records. I was thinking of simply poking a hole in the firewall to a static NAT for the master (restricted by the slave IPs) so that it could be contacted from the outside. I would have the master in the DMZ. Since this isn’t being used for any internal name services, I guess it may not make much sense to have it in the DMZ. > Why do you want to ACL /recursive/ lookups? Paranoia I guess lol. I should have mentioned said servers will have proper IPtables configured but will not have a formal next-gen firewall appliance in front of it. Even though we do implement some sort of packet filter for access to the services, I also tell bind to only respond to certain sources as well. Possibly overkill and more administrative work but I always go back to the “security in layers” train off thought. And since we use ansible for management, the second argument is sort of moot. > Another option to avoid PBR and mass client changes is to use traditional > routing to get to the ns1–ns4 IPs. Your strategy for putting the old resolver IPs as loopbacks on the new servers is a spiffy idea that I had not thought of before. That would make life easier as it could be queried by the interface IP for new users should we want to use the new IP and the old users would still just work because of the loopback. And we actually have each server on it’s own /29 or /64 (due to VRRP) so the actual IPs are very easily movable. > How are you doing the black hole if not with RPZ? As or the RPZ, I understood how it works at a high level but have never had the experience in using it. I was not aware the blackhole mechanism was also provided by it ( i had assumed they could send responses to something like /dev/null which Im guessing is now wrong ), so I do need to correct my self and state that we will need them because I intend on implementing filtering at that level since it is available. As for the rest, some of them would not apply since these are public servicing name servers and not internal. The rest of the suggestions will certainly be researched more so that I can fully understand how to implement them should they apply to our deployment. Thanks for the lengthy and descriptive response. It gives me several things to think about and research. Regards, m > On Jan 18, 2020, at 11:59 AM, Grant Taylor via bind-users > <bind-users@lists.isc.org> wrote: > > On 1/18/20 7:06 AM, N. Max Pierson wrote: >> Hi List, > > Hi M, > >> First off, I should note that I am a novice with administering Bind, so >> please bear with me. > > We all started somewhere. Hopefully we all continue to learn new things. ;-) > >> 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. > > «hat tip» > >> So I am aware it’s preferred to split recursive and authoritative services >> across different instances. > > Yes, that's the ideal design. Unfortunately that doesn't always scale down > to where some people need it. It quickly starts to be more complexity for > smaller networks, particularly SOHO networks. :-/ > > My current understanding is that if the server is accessible from the > Internet, then it probably really should have the recursive and authoritative > roles separated. If it's not accessible from the Internet, then it's more up > to your discretion of what makes sense for your network. > > My preference for smaller networks that may have multiple servers but don't > warrant separate servers is to have multiple recursive servers slave internal > zones off of the internal authoritative master. > >> 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). > > I do think it's a good idea to separate recursive servers for clients from > the master server for the internal zones. If this is possible in your > network. I don't have any reason to hide the master or prevent clients from > being able to communicate with it. In fact, clients may /need/ to > communicate with the master. I see no reason not to list the master as an > additional NS record in the zone. > > One thing that I couldn't tell from your description is if you need to > support dynamic updates from clients. I.e. Windows workstations updating DNS > based on new DHCP lessees, et al. This has some complications in that the > last time I dealt with this, the workstations sent their DDNS updates to the > master, thus needed to be able to communicate with the master. > >> It’s also a very good idea to deploy TSIG for transaction signing. And of >> course, ACL recursive lookups as well as AXFRs. > > Why do you want to ACL /recursive/ lookups? Why single out /recursive/ for > additional protection? I'd think that you would want to apply the same > protection to all DNS server access. Possibly with a belt and suspenders > method with the BIND and host firewalls / routing. > >> 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 > > Another option to avoid PBR and mass client changes is to use traditional > routing to get to the ns1–ns4 IPs. Bind said IPs to a loopback / dummy > interface on the DNS servers and rely on the networking to route to these /32 > / /128 IPs. You effectively turn these IPs into Service / Virtual IPs that > you can move around your network as you see fit. Of course, this does rely > on a routed L3 boundary between your clients and ns1–ns4 IPs. But I'm > guessing you already have that. > >> The ansible role can be seen here at 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 > > How are you doing the black hole if not with RPZ? > > Remember, you can have multiple RPZ zones, as well as RPZ white lists to > override subsequent RPZ black lists. > >> - Eventual integration with MISP RPZ export > > I would probably plan for this at deployment time. Possibly with a stub > empty (save for requisite zone metadata records) from the start. Then you > can simply replace that stub zone with actual MISP content when you're ready > to do so. > >> - 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? > > I would encourage you to start with stub RPZ configuration, especially if you > know that you want it. > > I would encourage you to think about starting with views, even if everything > is in a single view. Doing that will allow you to more easily add additional > views without needing to clear the hurdle of going from no views to multiple > views. > > I would strongly suggest that everybody read about BIND's deny-answer-* > filtering capability. In short, it allows you to tell BIND to filter answers > containing IPs in the first list except for zones in the second list. This > will help prevent attacks, like DNS Rebinding, that cause an external name > (not in the 2nd list) from resolving to internal IPs (in the 1st list). > > // block name to protected IP > deny-answer-address { … } except-from { … }; > // block alias to protected name > deny-answer-alias { … } except-from { … }; > > I'm a fan of BIND's empty zones and tweaking them to look mostly like what > IANA uses. > > empty-zones-enable yes; > empty-server "prisoner.iana.org"; > empty-contact "hostmaster.root-servers.org"; > > You can adjust server and contact as you like. I was trying to make my > server respond as close to the same way as would be responded by external > servers. (Don't make it obvious that something local is doing this filtering > of non-local zones.) > > While you're filtering spurious zones that you aren't authoritative for, take > a look at AS112. > > Link - AS112 Nameserver Operations > - https://tools.ietf.org/html/rfc7534 > > Similarly, consider being a root zone slave. If your version of BIND > supports it, use mirror zones instead of a slave zone. > > Aside: A mirror has a better failure mode than slave a slave zone. Mirror > fails as if it doesn't exist instead of a broken slave breaking things. > > I'm a big fan of DNSSEC. But sometimes you need to "break-dnssec", > particularly if you're doing things like RPZ or overriding external domains > with internal zones or filtering AAAA for some reason.* > > *I've had to filter AAAA records for IPv6 enabled clients to be able to > access Netflix b/c Netflix doesn't like my IPv6 provider. :-( > > Enable "minimal-responses". > > Depending on how many internal zones you have, and how dynamic they are, you > may want to consider catalog zones. > > TL;DR: Catalog zones are a way for slave servers to learn what zones they > should serve, where the masters are, and other pertinent information. Read: > Less reconfiguration. > > Given that you're talking about five servers, in what sounds like an SMB > configuration, you might appreciate rndc's ability to remotely control > servers. Be it from the from the master to the slaves or management > workstation(s) to all DNS servers. > > Depending on your environment, you might appreciate a VPN (or something else > to protect traffic) between servers. IPSec Transport Mode with minimal > (manual / automated / orchestrated) configuration comes to mind. > > You may be interested in BIND's monitoring and / or API interface too. > > Finally, I believe there are methods to allow clients to authenticate to BIND > via Kerberos for things like authorizing DDNS. Also, > > Link - RFC 2136 Dynamic DNS Updates using GSS-TSIG and Kerberos > - > https://jpmens.net/2012/06/29/dynamic-dns-updates-using-gss-tsig-and-kerberos/ > > I'm sure that there are other things to think about. But that's what came to > mind as I read and replied while drinking coffee. I'll be keeping an eye on > this thread to learn what others think and suggest. > > > > -- > Grant. . . . > unix || die > > _______________________________________________ > 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 _______________________________________________ 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
