From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 15:02:33 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 9C0EC37B401 for ; Fri, 18 Apr 2003 15:02:33 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id B956143F75 for ; Fri, 18 Apr 2003 15:02:32 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-159-107.client.attbi.com[12.234.159.107]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <2003041822023100100a3tute>; Fri, 18 Apr 2003 22:02:31 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h3IM2Uki040305; Fri, 18 Apr 2003 15:02:30 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h3IM2TLg040304; Fri, 18 Apr 2003 15:02:29 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Fri, 18 Apr 2003 15:02:29 -0700 From: "Crist J. Clark" To: Jeremy Chadwick Message-ID: <20030418220229.GB39466@blossom.cjclark.org> References: <20030418174956.GA71335@parodius.com> <20030418200936.82331.qmail@web10410.mail.yahoo.com> <20030418201645.GA77986@parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030418201645.GA77986@parodius.com> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ 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 Reply-To: "Crist J. Clark" 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 22:02:33 -0000 On Fri, Apr 18, 2003 at 01:16:45PM -0700, Jeremy Chadwick wrote: > Oleg: > > I tried your recommendation of commenting out the transfer-source > line, and within a few moments of running this: > > ipfw zero 1005 && ndc stop && /usr/sbin/named -u bind -g bind > > ...saw the following in our security syslog: > > Apr 18 13:11:09 pentarou /kernel: ipfw: Entry 1005 cleared. > Apr 18 13:11:33 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 64.71.184.190:53 out via fxp0 > Apr 18 13:12:04 pentarou last message repeated 5 times > > ...and our named syslog: > > Apr 18 13:11:33 pentarou named[77949]: ns_req: sendto([64.71.184.190].53): Permission denied > > So, it doesn't look like that's the offender. :-) > > 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. > > I'm still wondering why tcpdump isn't catching the I/O... That I can answer. The bpf(4) hooks lie very close to the "edges" of the stack, right in the device drivers. Outgoing packets that get blocked by the firewall never get low enough in the stack to get caught by BPF. I have a guess what those might be, but it'd be a weird feature. Perhaps the queries (potentially) involved with zone transfers use the transfer address? It'd be nice if you could get those outgoing packets. Can you turn on query logging within BIND? It _is_ possible to grab those packets before the firewall blocks them, but it might take some tricks with divert(4) sockets or other ugliness to do it. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org