Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Apr 2003 13:16:45 -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:  <20030418201645.GA77986@parodius.com>
In-Reply-To: <20030418200936.82331.qmail@web10410.mail.yahoo.com>
References:  <20030418174956.GA71335@parodius.com> <20030418200936.82331.qmail@web10410.mail.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Oleg:

        I tried your recommendation of commenting out the transfer-source
        line, and within a few moments of running this:

ipfw zero 1005 && ndc stop && /usr/sbin/named -u bind -g bind

        ...saw the following in our security syslog:

Apr 18 13:11:09 pentarou /kernel: ipfw: Entry 1005 cleared.
Apr 18 13:11:33 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 64.71.184.190:53 out via fxp0
Apr 18 13:12:04 pentarou last message repeated 5 times

        ...and our named syslog:

Apr 18 13:11:33 pentarou named[77949]: ns_req: sendto([64.71.184.190].53): Permission denied

        So, it doesn't look like that's the offender.  :-)

        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.

        I'm still wondering why tcpdump isn't catching the I/O...

-- 
| 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 Fri, Apr 18, 2003 at 01:09:36PM -0700, Oleg Polyakov wrote:
> You may want to comment out line:
> //         transfer-source 10.0.0.1;
> 
> Transfers to 10.0.0.0 should choose address 10.0.0.1 automagically.
> Transfers elsewhere should use zone-relevant transfer-source option.
> 
> --- Jeremy Chadwick <freebsd@jdc.parodius.com> wrote:
> >         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.                            |
> > 
> > _______________________________________________
> > freebsd-net@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
> 
> 
> __________________________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo
> http://search.yahoo.com
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030418201645.GA77986>