Date: Sat, 19 Apr 2003 12:42:40 -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: <20030419194240.GA43491@parodius.com> In-Reply-To: <y7v4r4ucw46.wl@ocean.jinmei.org> References: <20030418201645.GA77986@parodius.com> <1050703016.604363.667.nullmailer@cicuta.babolo.ru> <20030418234119.GA85777@parodius.com> <y7v65pbcbwc.wl@ocean.jinmei.org> <20030419064801.GA11635@parodius.com> <y7v4r4ucw46.wl@ocean.jinmei.org>
next in thread | previous in thread | raw e-mail | index | archive | help
It definitely looks to be an SOA check. After removing the
outbound ipfw block and running tcpdump, I'm now able to see
what's going on. Here's a tcpdump snippet taken from the
_primary_ nameserver:
01:59:20.784249 10.0.0.1.53 > 64.71.184.190.53: 29820* 1/2/3 SOA (247)
0x0000 4500 0113 19e8 0000 4011 5cec 0a00 0001 E.......@.\.....
0x0010 4047 b8be 0035 0035 00ff c48a 747c 8480 @G...5.5....t|..
0x0020 0001 0001 0002 0003 0b64 656c 7461 706c .........deltapl
0x0030 6179 6572 0363 6f6d 0000 0600 01c0 0c00 ayer.com........
0x0040 0600 0100 0007 0800 3003 6e73 3108 7061 ........0.ns1.pa
0x0050 726f 6469 7573 c018 0a68 6f73 746d 6173 rodius...hostmas
0x0060 7465 72c0 310b eef3 1400 002a 3000 000e ter.1......*0...
0x0070 1000 093a 8000 0007 08c0 0c00 0200 0100 ...:............
0x0080 0007 0800 02c0 2dc0 0c00 0200 0100 0007 ......-.........
0x0090 0800 0603 4e53 32c0 31c0 2d00 0100 0100 ....NS2.1.-.....
0x00a0 000e 1000 0440 47b8 abc0 7700 0100 0100 .....@G...w.....
0x00b0 000e 1000 0440 47b8 be14 7065 6e74 6172 .....@G...pentar
0x00c0 6f75 2d67 6162 7269 656c 2d4c 414e 0000 ou-gabriel-LAN..
0x00d0 fa00 ff00 0000 0000 3a08 484d 4143 2d4d ........:.HMAC-M
0x00e0 4435 0753 4947 2d41 4c47 0352 4547 0349 D5.SIG-ALG.REG.I
0x00f0 4e54 0000 003e a10f e801 2c00 10c0 5689 NT...>....,...V.
0x0100 472e 2631 2b54 099b 80f5 4063 0c74 7c00 G.&1+T....@c.t|.
0x0110 0000 00 ...
It's definitely an SOA lookup, and the dst IP is the secondary
NS in the zone itself (as Len's Email confirms).
The problem, in a strange way, looks to be of the chicken-and-egg
sort.
What I wanted to accomplish was the following:
1. Perform zone transfers between primary/secondary entirely across a
private network interface (fxp1), as well as notifies (for zone
updates, etc.).
2. Perform lookup queries based upon the network interface that seems
"most logical" (i.e. 10.0.0.0/8 --> 10.0.0.1 --> fxp1, etc.)
3. Keep NS records in the zones in question as assigned to public IPs,
as changing the NS IPs to point to 10.0.0.0/8 would make the zone
data inaccessible in the real world. The zones are public zones,
and aren't private zones.
4. Execute external lookups (due to MAPS RBL+) from a specific public
IP bound to the box itself.
I should note that I have tried BIND-9 on the secondary (and
not the primary), using transfer-source (I use this on BIND-8
per zone as well) and notify-source, and it did not seem to make
any difference. I still saw the same behaviour above, except on
an even larger scale. I believe Len's comments explain this.
It honestly sounds like I should move back to doing transfers,
notifies, and queries all across the public IPs which would
eliminate the use of the private network for distribution. The
two nameservers are connected on the same switch.
Thanks for the help, everyone. :-)
--
| 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 Sun, Apr 20, 2003 at 01:03:53AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> On Fri, 18 Apr 2003 23:48:01 -0700,
> >>>>> Jeremy Chadwick <freebsd@jdc.parodius.com> said:
>
> > 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. :-)
>
> > 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. :-)
>
> I guess the query from the client that caused the problem was the SOA
> check before zone transfer. If this is correct, you can control the
> source address of such queries with BIND 9's transfer-source. So,
> please try:
>
> 1. install BIND 9 at the secondary server.
> 2. add the following in the zone statement for which the secondary
> serves:
> transfer-source 10.0.0.2;
>
> I don't know the reason for the error at the secondary side.
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> jinmei@isl.rdc.toshiba.co.jp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030419194240.GA43491>