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

[Jeremy Chadwick]

        The secondary is configured literally identical to the
        primary, except that the IPs have changed and _all_ of
        the zones are type slave.

        I see the exact same problem on the secondary (again,
        outgoing traffic on the public interface with an IP of
        the private), except that the src & dst IPs apply to
        the private IP on the secondary and the WAN IP of the
        primary, respectively.  Sorry if that's confusing.  :-)

        Thank you for your below example -- I didn't consider that
        BIND would do something that ""silly"" (note quotes), but
        now it makes sense.

        I believe removing the query-source option could in fact
        solve the problem, but there is a specific reason for it's
        existance -- we rely on the MAPS RBL+ service for SBL lookups,
        which are DNS based.  Permission to the RBL+ service is based
        on the IP doing the query.  Since the nameserver IPs are
        IP aliases, if I do not specify this, the queries come from
        the first IP in the list shown in ifconfig -a.

        If there's a workaround for this, I'd love to hear it.  :-)

-- 
| 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 02:08:19PM +0900, JINMEI Tatuya / ?$B?@L at C#:H wrote:
> >>>>> On Fri, 18 Apr 2003 16:41:19 -0700, 
> >>>>> Jeremy Chadwick <freebsd at jdc.parodius.com> said:
> 
> >         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).
> 
> You seemed to misunderstand the comment.  It said "the problematic
> situation can happen when ***the secondary sends a query from its
> public address to the primary's private address***":
> 
>               query
> secondary:----------------->primary
> 64.71.184.190               10.0.0.1
>                (rejected)<----
>                        response
> 
> So I guess you should look at the configuration in secondary, not
> primary.
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, Toshiba Corp.
> 					jinmei at isl.rdc.toshiba.co.jp