From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 23:48:45 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 A881937B401 for ; Fri, 18 Apr 2003 23:48:45 -0700 (PDT) Received: from mail.parodius.com (mail.parodius.com [64.71.184.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1468343FE3 for ; Fri, 18 Apr 2003 23:48:45 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.9/8.12.9) with ESMTP id h3J6m1jU012021 for ; Fri, 18 Apr 2003 23:48:01 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.9/8.12.9/Submit) id h3J6m19X012020 for freebsd-net@freebsd.org; Fri, 18 Apr 2003 23:48:01 -0700 (PDT) Date: Fri, 18 Apr 2003 23:48:01 -0700 From: Jeremy Chadwick To: freebsd-net@freebsd.org Message-ID: <20030419064801.GA11635@parodius.com> References: <20030418201645.GA77986@parodius.com> <1050703016.604363.667.nullmailer@cicuta.babolo.ru> <20030418234119.GA85777@parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i 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 06:48:46 -0000 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. :-) Thank you for your below example -- I didn't consider that BIND would do something that ""silly"" (note quotes), but now it makes sense. 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. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Sat, Apr 19, 2003 at 02:08:19PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Fri, 18 Apr 2003 16:41:19 -0700, > >>>>> Jeremy Chadwick said: > > > Under what circumstances would the primary request data from > > the secondary on it's _public_ IP? My query-source directive > > is set to the public IP, and this IP should (according to BIND > > documentation) be used by both TCP and UDP queries (port #, > > however, cannot be guaranteed). > > You seemed to misunderstand the comment. It said "the problematic > situation can happen when ***the secondary sends a query from its > public address to the primary's private address***": > > query > secondary:----------------->primary > 64.71.184.190 10.0.0.1 > (rejected)<---- > response > > So I guess you should look at the configuration in secondary, not > primary. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp