mutual forwarders in ISC BIND
m.seaman at infracaninophile.co.uk
Wed Dec 28 10:04:05 UTC 2011
On 28/12/2011 07:54, Victor Sudakov wrote:
> This question is not directly related to FreeBSD, but perhaps some
> network administrators reading this list know the answer.
> Can I setup several ISC BIND servers to be each other's mutual forwarders?
> Will it work or create an endless loop of DNS queries?
> I have customers using several DNS servers as recursive resolvers. The
> usage pattern is pretty much equal between all the servers. What I
> want is create a cache common to all the recursive servers to reduce
> traffic and response time (much like squid siblings work).
Hmmm.... I've a feeling that the end result will be a forwarding loop
as you suspect, although eventually your resolvers will go and do the
lookup correctly and return the answers. That will probably add quite a
lot to the latency of cache misses and on the whole not help at all.
This is not a configuration I've ever heard of in use successfully,
which might be a clue as to it's efficacy and desirability.
DNS delays are almost always due to one or more of the nameservers
listed in resolv.conf being uncommunicative. Or because there's a dumb
firewall between the client and the resolver or between the resolver and
the rest of the net that does stupid things like assume that DNS packets
are limited to 512 bytes -- so blocking eDNS0 and forcing the resolver
to eventually fall back to using TCP. [Cisco, I'm looking at you...]
You can use tcpdump or wireshark to capture DNS traffic and diagnose
this sort of problem, plus bind will log information about problems with
eDNS0 packet sizes. Also this:
If you want to consolidate caches then probably your best bet is to have
fewer, but larger resolvers. A pretty standard server class machine
dedicated to recursive DNS should be easily capable of supporting many
thousands of clients.
DNS is not really a fruitful target for reducing traffic volume -- there
really isn't that much of it compared to all other types in any case.
It's also pretty critical to the perceived performance of your networks.
Complicating and slowing down the DNS lookup path just makes everything
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matthew at infracaninophile.co.uk Kent, CT11 9PW
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20111228/21be572f/signature.pgp
More information about the freebsd-questions