BIND-8/9 interface bug? Or is it FreeBSD?

[Jeremy Chadwick]

        Since when?  :-)  That wouldn't make very much sense, and
        would be extremely misleading for network administrators.
        bpf should have the highest priority, well above ipfw.

        I just verified that fact with a test: blocking any telnet I/O
        across my public interface and telnetting in from my home
        workstation:

$ ipfw add 350 deny tcp from any to any 23 via fxp0
00350 deny tcp from any to any 23 via fxp0
$ ipfw -a list 350
00350        0           0 deny tcp from any to any 23 via fxp0
$ tcpdump -p -ifxp0 -l -n "port 23"
tcpdump: listening on fxp0
16:46:17.585420 12.234.135.66.43116 > 64.71.184.170.23: S 3333778257:3333778257(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
16:46:19.541515 12.234.135.66.43117 > 64.71.184.170.23: S 3333778257:3333778257(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
16:46:21.731619 12.234.135.66.43118 > 64.71.184.170.23: S 3333778257:3333778257(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
$ ipfw -a list 350
00350        3         144 deny tcp from any to any 23 via fxp0

        The fact that tcpdump does not see the erroneous behaviour
        BIND is exhibiting is very bothersome.  What I have yet to do
        is run tcpdump on fxp1 and see if the traffic shows up there
        (and if it does, then I would classify this as a FreeBSD bug
        somewhere, while the origin itself would be a BIND bug).

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.                            |

On Fri, Apr 18, 2003 at 03:02:29PM -0700, Crist J. Clark wrote:
> 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 at alum.mit.edu
>                                    |     cjclark at jhu.edu
> http://people.freebsd.org/~cjc/    |     cjc at freebsd.org