From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 16:42:01 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 8C49D37B401 for ; Fri, 18 Apr 2003 16:42:01 -0700 (PDT) Received: from mail.parodius.com (mail.parodius.com [64.71.184.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id F008743F75 for ; Fri, 18 Apr 2003 16:42:00 -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 h3INfJjU086374 for ; Fri, 18 Apr 2003 16:41:19 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.9/8.12.9/Submit) id h3INfJTP086373 for freebsd-net@freebsd.org; Fri, 18 Apr 2003 16:41:19 -0700 (PDT) Date: Fri, 18 Apr 2003 16:41:19 -0700 From: Jeremy Chadwick To: freebsd-net@freebsd.org Message-ID: <20030418234119.GA85777@parodius.com> References: <20030418201645.GA77986@parodius.com> <1050703016.604363.667.nullmailer@cicuta.babolo.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1050703016.604363.667.nullmailer@cicuta.babolo.ru> 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: Fri, 18 Apr 2003 23:42:01 -0000 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). I have no forwarders configured, and using topology makes no difference. The problem at hand does not seem to be zone transfer related, but I cannot verify this; I'm going off the fact that the transfer-source directives are working fine (both functionally and in the logs). Another user here on the list recommended I enable query logging (I hope it doesn't require a rebuild; this is stock 8.3.4 taken from src) -- I'll give that a shot and see if there's anything odd appearing there. I don't even understand on a technical level how BIND is able to send outgoing UDP packets from a src address that isn't even bound to the interface in question. I'm frustrated that there doesn't seem to be a workaround that I know of. Another administrator recommended using a "stub" zone, but I have no experience with such, and the DNS/BIND book does not cover them in very verbose detail... -- | 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 01:56:56AM +0400, .@babolo.ru wrote: > > > > By the way, something I didn't cover: 64.71.184.190 is our > > secondary nameserver's WAN IP. It's private is 10.0.0.2. > That can be the key - if secondary server > request your private master using public IP > > > I'm still wondering why tcpdump isn't catching the I/O... > Your ipfw rules forbid packets > before interface you are looking for. > Just ipfw forward them to another interface to catch them.