On Mon, Apr 4, 2016 at 11:12 PM, Mathew Ian Eis <mathew....@nau.edu> wrote:
> 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 > > A slave server has a copy of the zone, so it is by definition "authoritative". I think what you mean by "non-authoritative slave" is "hidden slave" - not listed in NS records. I see no advantage of 3 over 2, you need some server listed in the NS and SOA records. 2 should work fine. -- Bob Harold
_______________________________________________ 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
