2 Questions - forward zone and DNS firewalling

N6Ghost n6ghost at gmail.com
Fri Oct 26 16:35:33 UTC 2018


On Fri, 26 Oct 2018 09:50:31 -0600
Grant Taylor via bind-users <bind-users at 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.
> 
> 
> 



More information about the bind-users mailing list