Howdy John,

Eh, I was afraid of that <sad> let me try again.

Can something like this:

[ internal recursive resolver + non-authoritative slave for foo.edu ] <-> [ 
internal authoritative slave for foo.edu ] <-> [ internal hidden master for 
foo.edu | external hidden master for foo.edu ] <-> [ external authoritative 
slave for foo.edu / listed in whois ]

... be safely collapsed to this:

[ internal recursive resolver + authoritative slave for foo.edu ] <-> [ 
internal hidden master for foo.edu | external hidden master for foo.edu ] <-> [ 
external authoritative slave for foo.edu / listed in whois ]

... or this *shudder*:

[ internal recursive resolver + non-authoritative slave for foo.edu ] <-> [ 
internal hidden master for foo.edu | external hidden master for foo.edu ] <-> [ 
external authoritative slave for foo.edu / listed in whois ]

The first case seems like it is wasting N copies of [ internal authoritative 
slave for foo.edu ] that aren't ever used for anything except dynamic updates 
(and not even that if you don't allow it, so possibly literally sitting idle).

The second case seems unsafe on the concern of cache poisoning risks, but... is 
it really necessary to invoke the fairly size-able case 1 to avoid cache 
poisoning? This feels like too much of an edge case to easily answer with Mark 
Andrew's comments on "strict separation lore".

The third case seems efficient, but ridiculous and not really possible; e.g. 
what would you put in the NS/SOA records to keep the master hidden and the 
slaves non-authoritative?

Thanks again,

-Mathew Eis

________________________________
From: John W. Blue [[email protected]]
Sent: Monday, April 04, 2016 7:12 PM
To: Mathew Ian Eis; [email protected]
Subject: Re: Split horizon and authoritative servers

Hello Matthew,

I am mobile right now and a bit distracted sitting here in a parking lot so 
what exactly your question is eludes me.

<grin>

Speaking from experience, running a split horizon environment has several 
advantages and is quit liberating.  For example, internally your BIND servers 
can be authortative for the root of your zone and then you delegate a subzone 
to Active Directory.  It keeps external/internal root neat and tidy and 
internally allows Active Directory the freedom to run dynamic updates without 
risk of leakage.

Every host get DNS from the Domain Controllers and the DC's get recursion 
exclusively from BIND.

That said, you will want authorative name severs for both external and 
internal.  If you choose to go with hidden external/internal masters that is 
fine.  No need to separate the roles of the slaves out unless there is an 
unknown operational requirement.

Finally,  if you have a lot of RR churn, look to an IPAM solution the help 
shoulder the load.  Editing db files by hand is asking for mistakes to be made.

Hope that helps!

John

Sent from Nine<http://www.9folders.com/>

From: Mathew Ian Eis <[email protected]>
Sent: Apr 4, 2016 7:38 PM
To: [email protected]
Subject: Split horizon and authoritative servers

Hi BIND,

I have a question about authoritative servers in a split horizon environment 
(suppose two views “internal” and “external”).

Is is necessary to have separate internal authoritative (listed in internal 
zone NS records, but not in whois or external NS records) servers, if the 
internal recursive servers are also authoritative (in the same way) slaves to 
an internal hidden master for the relevant zones?

It seems like cache poisoning should not be a concern, since the only servers 
listed in the (internal) NS records would as slaves always have full copies of 
relevant zones, and would not actually be recursing for those records. I can’t 
think of any other reason to separate the internal authoritative slaves and the 
internal recursive resolvers… am I missing anything obvious?

Thanks in advance,

Mathew Eis
Northern Arizona University
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to