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

[Crist J. Clark]

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