From owner-freebsd-questions@FreeBSD.ORG Wed Dec 28 10:04:04 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6992106564A for ; Wed, 28 Dec 2011 10:04:04 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 391C98FC08 for ; Wed, 28 Dec 2011 10:04:04 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id pBSA3vJK034333 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 28 Dec 2011 10:03:57 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: OpenDKIM Filter v2.4.1 smtp.infracaninophile.co.uk pBSA3vJK034333 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1325066637; bh=BBpmyH0KE8CTfn13vtEeCFNq7L6wo0tXtaB0bfPPKXc=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Cc; b=GY37bTpaV+u0ERonYCRnIhuVubYH2YXYg3nqehV/pv+GXTh5DFxBsbmydejmRWRzr ecdO7BxCisQWOLNbTxLiWfKqcnV058aCYHmMly2kT8s9w4J90XmZb2zWQmiUO56fFc m/KluqBXfjUJTgRC8G6gqTiInogQo4kJiEIl8u/8= Message-ID: <4EFAE986.7030207@infracaninophile.co.uk> Date: Wed, 28 Dec 2011 10:03:50 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <20111228075422.GA18064@admin.sibptus.tomsk.ru> In-Reply-To: <20111228075422.GA18064@admin.sibptus.tomsk.ru> X-Enigmail-Version: 1.3.4 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig814EEE72AB375714A9BCC2CB" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED, AWL, DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Subject: Re: mutual forwarders in ISC BIND X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 10:04:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig814EEE72AB375714A9BCC2CB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. >=20 > Can I setup several ISC BIND servers to be each other's mutual forwarde= rs? > Will it work or create an endless loop of DNS queries? >=20 > 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).=20 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: https://www.dns-oarc.net/oarc/services/replysizetest 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 look slow. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig814EEE72AB375714A9BCC2CB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk766Y0ACgkQ8Mjk52CukIwyrQCdGjooFbtCgdnMkVPMMRnNnTdM 6GsAn1U+VIV62B6xx4xJBzcLPV12+20p =yF+d -----END PGP SIGNATURE----- --------------enig814EEE72AB375714A9BCC2CB--