Using forwarders

Howard Wilkinson howard at
Wed Jun 25 08:59:09 UTC 2008

Brian Feeny wrote:
> I am familiar with using forwarders for conditional forwarding of certain
> zones, and understand the reasons for doing so.  I am also familiar with
> using forwarders with an internal and external dns model, where you do not
> wish to allow your internal dns direct access to external
> entities/internet/etc.
> What about the situation where a company has a single DNS server, that has
> direct internet access, and they add a forwarder to their ISP.  What is the
> case for this?  I do not believe that DNS processing is so cpu intensive
> that pawning off the recursive lookups to another server buys you a whole
> lot.  Same goes for bandwidth.  Assume the server has internet access via
> NAT or PAT, I don't see any real driving reasons.  I bring this up because I
> have a client doing just this, and I cannot think of any reason they do it
> like this, they cannot defend why its like this, but their change order
> process is so involved that for them to switch it requires more
> justification.  I don't like it as well because it introduces a point of
> failure that need not be.  Sure the DNS server should locally attempt
> recursive lookups on its own if the forwarder times out, but the current
> timeout was set so high (5 seconds) that requests were timing out, at least
> most of the time, before the queries could be locally resolved.
> So can anyone think of practical reasons why one would want to set
> forwarders to their ISP?  I mean, even pooling to a much larger DNS cache
> (The ISP) doesn't seem like a big win.  
> Brian

is it possible that the ISP provides a "name translation service" :-[  
on their name servers and hence the forwarding is needed to "see" the 
translated name space! I have seen this happen in the past, although not 
recently I admit, where the ISP intercepted requests to ad providers and 
replaced with their benign ad's O:-)

Otherwise as you indicate this can only provide a higher chance of a hit 
rate for a (potential) reduction in reliability of the overall service.


More information about the bind-users mailing list