From owner-freebsd-net@FreeBSD.ORG Sat Apr 19 09:04:04 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0E4037B401 for ; Sat, 19 Apr 2003 09:04:04 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 785D743FE9 for ; Sat, 19 Apr 2003 09:04:03 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BF42315210; Sun, 20 Apr 2003 01:05:17 +0900 (JST) Date: Sun, 20 Apr 2003 01:03:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jeremy Chadwick In-Reply-To: <20030419064801.GA11635@parodius.com> References: <20030418201645.GA77986@parodius.com> <1050703016.604363.667.nullmailer@cicuta.babolo.ru> <20030418234119.GA85777@parodius.com> <20030419064801.GA11635@parodius.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 39 cc: freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 16:04:05 -0000 >>>>> On Fri, 18 Apr 2003 23:48:01 -0700, >>>>> Jeremy Chadwick said: > The secondary is configured literally identical to the > primary, except that the IPs have changed and _all_ of > the zones are type slave. > I see the exact same problem on the secondary (again, > outgoing traffic on the public interface with an IP of > the private), except that the src & dst IPs apply to > the private IP on the secondary and the WAN IP of the > primary, respectively. Sorry if that's confusing. :-) > I believe removing the query-source option could in fact > solve the problem, but there is a specific reason for it's > existance -- we rely on the MAPS RBL+ service for SBL lookups, > which are DNS based. Permission to the RBL+ service is based > on the IP doing the query. Since the nameserver IPs are > IP aliases, if I do not specify this, the queries come from > the first IP in the list shown in ifconfig -a. > If there's a workaround for this, I'd love to hear it. :-) I guess the query from the client that caused the problem was the SOA check before zone transfer. If this is correct, you can control the source address of such queries with BIND 9's transfer-source. So, please try: 1. install BIND 9 at the secondary server. 2. add the following in the zone statement for which the secondary serves: transfer-source 10.0.0.2; I don't know the reason for the error at the secondary side. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp