Date: Fri, 18 Apr 2003 16:41:19 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? Message-ID: <20030418234119.GA85777@parodius.com> In-Reply-To: <1050703016.604363.667.nullmailer@cicuta.babolo.ru> References: <20030418201645.GA77986@parodius.com> <1050703016.604363.667.nullmailer@cicuta.babolo.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030418234119.GA85777>