My terminology seems to be the issue here, so let me try and rephrase/elaborate : )
> I'm sure that you can get Ansible to add / remove / modify the list of zones > on the slave servers. But is that the best solution when BIND has something > built in for doing the same thing? I was not aware there was anything built in that would let you add/remove/change the zone itself from the master. Is this feature basically some sort of named.conf synchronization utility? The current setup needs to be touched should a new zone need to be added or removed today. > At least I would evaluate if it's reasonably possible to do. Is the added > complexity of NAT /required/ -> /needed/ -> /desired/? It’s certainly not required and not really wanted personally but having the master with a public IP (doing a no nat for that host in the FW policy) on the inside would be a snowflake as everything else has RFC1918 on it behind the firewall (IPv4 that is). Not that that’s a deal breaker, I just would have to get sign-off from others. The reason I had for having it in the DMZ is so that one would have to penetrate the FW to get to the master for any changes to be made. And this FW would next-gen with for high level of scrutiny which IPtables can’t give. > I'm failing to understand why the /reverse/ zones have more security than > /other/ zones. So all of the slaves would be answering for public/external domains. No internal will exist on them nor the master. Very simple setup without any views currently, so the slaves are copies of the master. Forward and reverse would be treated the same, sorry if I mis-spoke. > I would still expect the scope of access to be the same for forward and > reverse zones. See previous. I think what I meant to say was that the recursive servers be locked down via ACL at 2 different layers. Not the authoritative, again my apologies. Thanks for the quick and dirty on RPZ. I knew what it was and how it works somewhat but was not aware the scope of the vars and functions that act upon them to be so flexible. The functions allow me to return/manipulate the response at what seems like a pretty granular level. I need to read up on exactly what each response does in totality but I get a good guess from their name/description. Again I appreciate the detail in your response. It makes me feel a little better about managing our own instances versus handing it off to some other cloud provider. Regards, m > On Jan 19, 2020, at 11:23 AM, Grant Taylor via bind-users > <bind-users@lists.isc.org> wrote: > > On 1/19/20 3:25 AM, N. Max Pierson wrote: >> Hi Grant, > > Hi, > >> 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. > > Fair enough. > > With that in mind, I'm speculating that the list of zones (in scope) will be > somewhat dynamic. As such, I *STRONGLY* encourage you to take a look at > catalog zones. > > I'm sure that you can get Ansible to add / remove / modify the list of zones > on the slave servers. But is that the best solution when BIND has something > built in for doing the same thing? > >> 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. > > If the master is functionally identical to the slaves, save for the master vs > slave configuration, then it probably can live with the slaves. However, if > the master has any other data / configuration / internal DB access / etc, I > would recommend that it be separated. > > I like to think of slave servers in the DMZ as a line of defense for the > master. Sometimes it's appropriate, sometimes it isn't. > > I don't know your network topology. But I'd be tempted to see if I could use > standard routing in lieu of NAT between the slaves and the master. At least > I would evaluate if it's reasonably possible to do. Is the added complexity > of NAT /required/ -> /needed/ -> /desired/? The same questions should be > asked about routing, and chose the appropriate answer. > >> Paranoia I guess lol. > > Hum. > > I'm failing to understand why the /reverse/ zones have more security than > /other/ zones. > > I guess I should mention that I'm assuming that you're talking about > in-addr.arpa zones for reverse DNS of globally routed IPs. As such, I would > think that (at least the slave) servers should be accessible for the world to > query. > >> 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. > > Sure. Multiple levels of defense is a good thing. I'm an advocate for > closing and latching every picket fence gate. > > I'm still pondering if the zones are public or private and what the scope of > access /should/ be. > > I would still expect the scope of access to be the same for forward and > reverse zones. > >> 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. > > :-) > >> 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. > > Ah. Response Policy Zones are — in my (not so) humble opinion — wonderful! > > Depending on the version of BIND in question, you can do (at least) the > following: > > · Return an NXDOMAIN for a QUNAME with ".". > · Return a NODATA for a QNAME with "*.". > · Return the response unmodified with "rpz-passthru.". > · Drop the response with "rpz-drop.". > · Truncate the response with "rpz-tcp-only.". > · Replace the response with local data. > > You can trigger the above actions based on (at least) the following criteria: > > · QNAME > · IP in response > · Client IP > · Name Server Name > · Name Server IP > > The following page on Zytrax's site is one of my favorites for RPZ info. I > actually quite like Zytrax's site for all things BIND related. > > Link - BIND9 - Response Policy Zone Configuration > - https://www.zytrax.com/books/dns/ch7/rpz.html > > Note: Depending how serious you are about filtering, there is a relatively > new — and seemingly lesser known — BIND technology, Response Policy Service. > I liken RPS to Sendmail milters to actively filter DNS content. Conversely, > RPZ is more a comparison of a static list. An RPS back end could do more > active analysis on queries and / or replies. > > I've not done much with RPS, because it's still relatively new, somewhat > under documented, and all the backends that I'm aware of are commercial > products. > >> 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. > > You're welcome. > > > > -- > 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
