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

[Jeremy Chadwick]

        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 at 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, . at 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.