Skip site navigation (1)Skip section navigation (2)
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>