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.
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. -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 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
