Split horizon and authoritative servers

[Mathew Ian Eis]

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 [john.blue at rrcic.com]
Sent: Monday, April 04, 2016 7:12 PM
To: Mathew Ian Eis; bind-users at lists.isc.org
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 <Mathew.Eis at nau.edu>
Sent: Apr 4, 2016 7:38 PM
To: bind-users at lists.isc.org
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160405/a29b4a34/attachment.html>