On 1/20/20 9:06 AM, N. Max Pierson wrote:
My terminology seems to be the issue here, so let me try and rephrase/elaborate : )
;-)
I was not aware there was anything built in that would let you add/remove/change the zone itself from the master.
Yes, Catalog Zones. I think it's only a few years old.
Is this feature basically some sort of named.conf synchronization utility?
No. It's actually quit a bit nicer than that.Catalog Zones are a way for a BIND slave server to read a zone and learn what zones it should be a slave for and where the master servers are along with other related metadata.
You add a new zone as a (series of) record(s) to the catalog zone, which is a standard zone used for the catalog purpose. The slave uses standard zone transfers from the master(s), reads the catalog zone, and then dynamically re-configures itself to add / remove zone(s) as necessary.
The current setup needs to be touched should a new zone need to be added or removed today.
No config files get updated. Obviously, the typical slave zone files will get created / written to as you would expect.
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.
That makes sense.
And this FW would next-gen with for high level of scrutiny which IPtables can’t give.
I question that statement, because that's the type of person that I am and the type of thing I question. (More what you have been told, than questioning you as the messenger.)
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.
ACK
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.
That makes more sense. Thank you for clarifying.
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.
:-D -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 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
