Daisy chaining slaves

[Mark Andrews]

The expiry inflation can be removed if you use a servers that support the EDNS EXPIRE option.

-- 
Mark Andrews

> On 18 Dec 2017, at 23:03, Tony Finch <dot at dotat.at> wrote:
> 
> vijay bommareddy <vijayb888 at gmail.com> wrote:
>> 
>> I generally do multiple slaves to a set of masters. But I'm just wondering
>> if daisy chaining slaves i.e slave to a slave to a slave to a master, a
>> good practice in general? What are the pros and cons of it?
> 
> In my setup there are a couple of reasons for daisy-chaining secondaries.
> 
> I have a hidden primary master (well, firewalled rather than strictly
> hidden, since it appears in my SOA MNAME field) that only allows xfers to
> other servers I deirectly control.
> 
> I have a number of secondaries which xfer from my public authoritative
> servers, so they have a two-stage daisy chain. Here, daisy chaining allows
> me to implement a security boundary.
> 
> I also have a third-party anycast secondary service, which has a hidden
> xfer distribution server, the the actual anycast nodes are at the end of a
> three-stage daisy chain. Here, daisy chaining allows the details of an
> anycast cloud to be hidden from the primary servers.
> 
> On a high traffic system you'll probably want to separate xfers from
> normal authoritative service, to reduce the risk of performance gotchas.
> This may lead you to a daisy-chained xfer topology similar to the anycast
> case.
> 
> The consequence of daisy-chaining is that it inflates the SOA expire
> interval. Zone expiry is a timer local to each secondary since its most
> recent successful refresh, so (in my setup) if xfers start failing my
> anycast secondary might not expire the zones for three weeks (3x my SOA
> expire time).
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
> Northwest Fitzroy, West Sole: Westerly backing southerly 4 or 5, occasionally
> 6 in west. Moderate or rough. Occasional drizzle, fog patches. Moderate or
> good, occasionally very poor.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users