On Fri, 26 Oct 2018 09:50:31 -0600 Grant Taylor via bind-users <bind-users@lists.isc.org> wrote:
> On 10/26/2018 08:52 AM, Kevin Darcy wrote: > > My basic rule of thumb is: use forwarding when connectivity > > constraints require it. Those constraints may be architectural, > > e.g. a multi-tiered, multi-layer network for security purposes, or > > may be the result of screwups or unintended consequences, e.g. a > > routing blackhole. Use forwarding to get around those blockages. > > Agreed all around. > > Is there any reason to not prefer to slave the zone instead of > forwarding? I would think that would provide better performance > results and lessen the requirement for always on nature of the > forwarded target. its a netscaler load balancer, the zone name is the zone that the netscaler "owns", so it can create LB records off of it that it owns and can control. so we cant slave it, it had to be a forward. i called this out years ago when this was being built and said it was a bad idea and that we should do proper delegation and plan it out. by the time everything was said and done it was, said it was to late to change it... to work with or around it doh... > > > Now, if one thinks one can use forwarding for > > efficiency/performance ("forward first") as opposed to using it for > > connectivity ("forward only"), then do so based on *documented* , > > *observed* evidence, not just on assumptions or conjecture. A lot > > of folks just take for granted that forwarding to a rich cache will > > speed up their lookups. Maybe it will, maybe it won't -- MEASURE IT. > > > > Also, bear in mind that while forwarding to a rich cache may help > > your *best* case, and maybe your *average* case, it may hurt your > > *worst* case, since in the case of a cache miss, you have your > > wasted forwarding attempt *plus* however long it takes to fetch the > > data yourself. Your worst case is going to be the one that causes > > apps to time out, support calls, tickets, everyone blaming the DNS > > infrastructure, etc. You've been warned. > > Duly noted. Thank you for articulating. > > > _______________________________________________ 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