securing bind in todays hostile environment

[Grant Taylor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200121/a234e0f2/attachment-0001.bin>