securing bind in todays hostile environment
gtaylor at tnetconsulting.net
Tue Jan 21 20:22:32 UTC 2020
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
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.
> 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.
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
More information about the bind-users