Date: Fri, 18 Apr 2003 10:49:56 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: freebsd-net@freebsd.org Subject: BIND-8/9 interface bug? Or is it FreeBSD? Message-ID: <20030418174956.GA71335@parodius.com>
next in thread | raw e-mail | index | archive | help
Greetings. I've spoken with numerous other administrators
about the phenomenon I'm about to post, and the only answer
I've gotten so far is "Your box is broken" (how quaint). I
have two web/nameservers, both which exhibit this behaviour.
There's much mystery involved in this problem, so this post
will be long and verbose.
The problem: BIND-8 looks to be sending packets destined for
my RFC 1918 subnet (10.0.0.0/8) over my _WAN interface_.
Since I have overly anal firewall rules to block this sort-of
thing, what I see numerous times a day (at irregular intervals)
are _outgoing_ packets being blocked.
First, let's start with the machine NIC/network topology. There
are two physical NICs in my nameservers: one public interface
and one private, using entirely separate switches to segregate
the traffic. The public interface NIC has multiple IPs assigned
to it (IP aliases). Here's ifconfig:
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 64.71.184.170 netmask 0xffffffe0 broadcast 64.71.184.191
inet 64.71.184.171 netmask 0xffffffff broadcast 64.71.184.171
inet 64.71.184.172 netmask 0xffffffff broadcast 64.71.184.172
inet 64.71.184.173 netmask 0xffffffff broadcast 64.71.184.173
inet 64.71.184.175 netmask 0xffffffff broadcast 64.71.184.175
inet 64.71.184.176 netmask 0xffffffff broadcast 64.71.184.176
inet 64.71.184.177 netmask 0xffffffff broadcast 64.71.184.177
inet 64.71.184.178 netmask 0xffffffff broadcast 64.71.184.178
inet 64.71.184.179 netmask 0xffffffff broadcast 64.71.184.179
ether 00:e0:81:02:3c:88
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255
ether 00:e0:81:02:3c:89
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
My routing table:
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 64.71.184.161 UGSc 63 109070 fxp0
10 link#2 UC 3 0 fxp1
10.0.0.2 00:e0:81:04:69:e2 UHLW 8 1263590 fxp1 1053
10.0.0.128 00:04:ea:9c:2d:c1 UHLW 0 14822 fxp1 966
10.0.0.129 00:c0:05:01:60:fe UHLW 0 263 fxp1 1023
64.71.184.160/27 link#1 UC 5 0 fxp0
64.71.184.161 00:03:6b:50:1a:21 UHLW 62 0 fxp0 978
64.71.184.162 00:90:27:e0:0f:70 UHLW 0 2 fxp0 1053
64.71.184.170 00:e0:81:02:3c:88 UHLW 0 25583 lo0
64.71.184.171/32 link#1 UC 0 0 fxp0
64.71.184.172/32 link#1 UC 0 0 fxp0
64.71.184.173/32 link#1 UC 0 0 fxp0
64.71.184.175/32 link#1 UC 0 0 fxp0
64.71.184.176/32 link#1 UC 0 0 fxp0
64.71.184.177/32 link#1 UC 0 0 fxp0
64.71.184.178 00:e0:81:02:3c:88 UHLW 0 19203 lo0 =>
64.71.184.178/32 link#1 UC 1 0 fxp0
64.71.184.179/32 link#1 UC 0 0 fxp0
64.71.184.189 00:e0:81:04:69:e1 UHLW 0 99 fxp0
64.71.184.190 link#1 UHLW 1 12 fxp0
127.0.0.1 127.0.0.1 UH 2 246142 lo0
My firewalling rules are set up as follows (please note rule 400,
and the packet counters on rule 1005):
00100 580884 73786974 allow ip from any to any via lo0
00200 0 0 deny ip from any to 127.0.0.0/8
00300 0 0 deny ip from 127.0.0.0/8 to any
00400 2507920 940337032 allow ip from any to any via fxp1
01000 0 0 deny log ip from any to 10.0.0.0/8 in recv fxp0
01005 195 52392 deny log ip from 10.0.0.0/8 to any out xmit fxp0
01100 0 0 deny log ip from any to 172.16.0.0/12 in recv fxp0
01105 0 0 deny log ip from 172.16.0.0/12 to any out xmit fxp0
01200 0 0 deny log ip from any to 192.168.0.0/16 in recv fxp0
01205 0 0 deny log ip from 192.168.0.0/16 to any out xmit fxp0
syslog security shows the following for the denied on rule 1005
(this is just a snippet):
Apr 18 08:53:45 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 64.71.184.190:53 out via fxp0
Apr 18 09:35:13 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 64.71.184.190:53 out via fxp0
Apr 18 10:01:21 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 64.71.184.190:53 out via fxp0
syslog for named shows corresponding entries, verifying that BIND
does look to be sending things out on the wrong interface (the
entries below report Permission denied due to my firewalling
rules above):
Apr 18 08:53:45 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): Permission denied
Apr 18 09:35:13 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): Permission denied
Apr 18 10:01:21 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): Permission denied
What is happening should not even be technically possible, if I
understand things correctly.
Applicable pieces of my BIND-8 configuration are as follows:
options {
query-source address 64.71.184.171;
transfer-source 10.0.0.1;
listen-on {
127.0.0.1;
10.0.0.1;
64.71.184.171;
};
};
Then, in zones I wish to slave via the WAN interface, I insert
the following into the zone block (example included):
zone "malkavian.com" in {
type slave;
notify no;
file "../zones/zone.malkavian.com";
allow-transfer { 216.66.32.72; };
masters { 216.66.32.72; };
transfer-source 64.71.184.171;
};
Non-WAN zones (which should be transferred over the private
interface) look to be as follows (I use TSIG just because):
zone "deltaplayer.com" in {
type master;
file "../zones/zone.deltaplayer.com";
allow-transfer { key pentarou-gabriel-LAN; };
};
I'd also like to throw in the fact that I have tried BIND-9
on this exact setup, adding "notify-source" entries where
appropriate, and I _still witnessed the same behaviour_ (and
on a much larger scale none the less!).
Finally, here's the twist which makes absolutely no sense
to me what-so-ever:
To try and find out what sort-of packets were being sent
across the WAN with a src address of 10.0.0.1, I ran tcpdump
as follows, and went to bed for about 8 hours:
$ tcpdump -p -ifxp0 -l -n -s8192 -X "src net 10.0.0.0/8"
During those 8 hours, ipfw reported numerous outgoing packets
being blocked (rule 1005) -- but tcpdump showed _absolutely
nothing_.
I'd _REALLY_ love to get to the bottom of this, as there is
obviously a bug somewhere, and I have a feeling this kind-of
issue could easily become one of folks saying "BIND is buggy"
and the ISC folks saying "FreeBSD is broken."
Advice/comments/questions would be greatly appreciated, as
I'm extremely frustrated with this entire situation, and not
sure where to turn.
Thanks.
--
| 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. |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030418174956.GA71335>