Date: Fri, 18 Apr 2003 13:09:36 -0700 (PDT) From: Oleg Polyakov <opolyakov@yahoo.com> To: Jeremy Chadwick <freebsd@jdc.parodius.com>, freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? Message-ID: <20030418200936.82331.qmail@web10410.mail.yahoo.com> In-Reply-To: <20030418174956.GA71335@parodius.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030418200936.82331.qmail>