From owner-freebsd-hackers Tue Dec 26 15:39:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA21747 for hackers-outgoing; Tue, 26 Dec 1995 15:39:46 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA21742 for ; Tue, 26 Dec 1995 15:39:44 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id PAA05726 for ; Tue, 26 Dec 1995 15:39:34 -0800 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id RAA04475; Tue, 26 Dec 1995 17:30:59 -0600 From: Joe Greco Message-Id: <199512262330.RAA04475@brasil.moneng.mei.com> Subject: Re: Freebsd IP alias and BIND To: volf@oasis.IAEhv.nl (Frank Volf) Date: Tue, 26 Dec 1995 17:30:58 -0600 (CST) Cc: freebsd-hackers@freebsd.org, bind-users@vix.com In-Reply-To: <199512261919.UAA05384@oasis.IAEhv.nl> from "Frank Volf" at Dec 26, 95 08:19:10 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > Hi and merry Xmas to you all, > > This message is sent to both freebsd-hackers and bind-users because I > haven't figured out yet whether to blame FreeBSD, bind ore myself. I know this > (or similar) problem have been the topic of bind-users before, but as far > as I know there has not been a fix for it. > > THE SETUP: > FreeBSD 2.05 box (pentium 90) and bind-4.9.3beta32. The FreeBSD box has > a IP address (192.87.208.2) and an IP alias (194.151.64.2). > The alias is used because we are in process of moving to a new IP netblock > and we want both the old and the new nameserver addresses to be valid in > the transition period. > > THE PROBLEM: > When a query is sent to the IP alias two responses are generated: one > response with the real IP address as the source address, the other one with > the alias address as the source address: > > 17:02:20.146789 192.87.209.4.53 > 194.151.64.2.53: 52731+ NS? tue.nl. (24) > 17:02:20.148820 192.87.208.2.53 > 192.87.209.4.53: 52731* 3/0/3 NS kweetal.tue.nl. (144) > 17:02:20.150752 194.151.64.2.53 > 192.87.209.4.53: 52731* 3/0/3 NS ns1.surfnet.nl. (144) > > On a UNIX system runing BIND, the bogus response triggers the "response from > unexpected source" message, but has no other effects. Some dialin software > however (older versions of trumpet winsocket if I recall correctly) do not > handle this correctly and cause the nameserver request to timeout if the > wrong response is received first. > > THE CAUSE: > I'm not sure. Since you can see in the tcpdump that the responses are > different (round robin is turned on), it seems that bind gets or processes > the incoming UDP package twice. I however don't know, if this is caused > by bind or by the FreeBSD kernel. I ran into this a month or three ago, when I upgraded one of my primary servers from FreeBSD 2.0R to 2.1R. I do not like tying functionality to hostnames, so all my servers have well known ("separate") IP addresses. When I traced what was happening, it appears that a second copy of the UDP message is being received by named, one on the localhost and one on the alias file descriptor, as I recall. Well I still have the article I posted... > From jgreco Sat Dec 2 22:57:15 CST 1995 > Newsgroups: comp.protocols.tcp-ip.domains > Subject: Re: 'Response from unexpected source': what does this mean, please? > References: <49ekd0$fp7@lorne.stir.ac.uk> <49ifkc$g7p@tools.bbnplanet.com> <49r80r$56e@brasil.moneng.mei.com> > > In comp.protocols.tcp-ip.domains article <49r80r$56e@brasil.moneng.mei.com>, jgreco@brasil.moneng.mei.com (Joe Greco) wrote: > ::Named has always done the right thing here. Since 4.8.1 at least. > :: > ::SunOS 4.1.3 and older (and maybe newer) don't permit Named to specify > ::the source of packets due to an obscure bug in the bind(2) syscall. > : > :Actually, something broke under FreeBSD 2.1.RELEASE. > : > :Background: I hate moving targets. Since my service machines tend to come > :and go, and their IP numbers change (but stay on the same subnet), I have > :virtual addresses for "dns{1,2}.sol.net", and several other things. This > :way I don't have to do silly gyrations each time I retire a box - I simply > :take the virtual interface down and put it up on another box. > : > :Under FreeBSD 2.0.RELEASE, this worked fine. I was using an ifconfig alias > :of "dns1.sol.net netmask 0xffffffc0". Under FreeBSD 2.1.RELEASE, this > :syntax no longer works and I must specify "dns1.sol.net netmask 0xffffffff". > : > :Coincidentally I had decided to look into this this evening, but the code > :didn't look pretty so I came here looking to see if there was a FAQ entry or > :anything that covered this. Fascinating I should run into this discussion.. > > More data: tracing enabled, request sent to "dns1.sol.net" from > "brasil.moneng.mei.com", request is seen with sniffer going brasil->dns1 and > returning from anacreon->brasil and ALSO from dns1->brasil ?? > > DNS trace data: > Version = named LOCAL-951202.215122 Sat Dec 2 21:51:22 CST 1995 > root@anacreon.sol.net:/usr/src/usr.sbin/named > bootfile = /etc/named.boot > fclose(4) succeeded > named[990]: starting. named LOCAL-951202.215122 Sat Dec 2 21:51:22 CST 1995 > root@anacreon.sol.net:/usr/src/usr.sbin/named > considering [206.55.64.68] > dqp->dq_addr 206.55.64.68 d_dfd 5 > listening [206.55.64.68] > considering [206.55.64.72] > dqp->dq_addr 206.55.64.72 d_dfd 6 > listening [206.55.64.72] > considering [206.55.64.116] > dqp->dq_addr 206.55.64.116 d_dfd 7 > listening [206.55.64.116] > considering [127.0.0.1] > dqp->dq_addr 127.0.0.1 d_dfd 8 > listening [127.0.0.1] > loopback address: x100007f > dqp->dq_addr 0.0.0.0 d_dfd 9 > > ns_init(/etc/named.boot) > ...... sent request, fast forward thru file > qfree: nsdata 040029C6 rcnt 1 > > datagram from [151.186.20.4].3557, fd 9, len 30; now Sat Dec 2 22:38:33 > 1995 > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 > ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 > ;; QUESTIONS: > ;; news.sol.net, type = A, class = IN > > ns_req(from=[151.186.20.4].3557) > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 > ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 > ;; QUESTIONS: > ;; news.sol.net, type = A, class = IN > > req: nlookup(news.sol.net) id 512 type=1 class=1 > req: found 'news.sol.net' as 'news.sol.net' (cname=0) > wanted(0x46f80, 1, 1) [IN CNAME] > make_rr(news.sol.net, 46f80, efbfd6f6, 470, 1) 15 zone 6 ttl 0 > ....... blah blah > free_nsp: H.ROOT-SERVERS.NET rcnt 2 > free_nsp: B.ROOT-SERVERS.NET rcnt 2 > ns_req: answer -> [151.186.20.4].3557 fd=9 id=2 size=170 Remote > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 > ;; flags: qr aa rd ra; Ques: 1, Ans: 2, Auth: 3, Addit: 2 > ;; QUESTIONS: > ;; news.sol.net, type = A, class = IN > > ;; ANSWERS: > news.sol.net. 86400 IN CNAME hummin.sol.net. > hummin.sol.net. 86400 IN A 204.95.172.243 > > ;; AUTHORITY RECORDS: > sol.net. 86400 IN NS dns1.sol.net. > sol.net. 86400 IN NS dns2.sol.net. > sol.net. 86400 IN NS spool.mu.edu. > > ;; ADDITIONAL RECORDS: > dns1.sol.net. 86400 IN A 206.55.64.68 > dns2.sol.net. 86400 IN A 206.55.64.69 > > > datagram from [151.186.20.4].3557, fd 5, len 30; now Sat Dec 2 22:38:33 > 1995 > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 > ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 > ;; QUESTIONS: > ;; news.sol.net, type = A, class = IN > > ns_req(from=[151.186.20.4].3557) > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 > ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 > ;; QUESTIONS: > ;; news.sol.net, type = A, class = IN > > req: nlookup(news.sol.net) id 512 type=1 class=1 > req: found 'news.sol.net' as 'news.sol.net' (cname=0) > wanted(0x46f80, 1, 1) [IN CNAME] > ....... blah blah > free_nsp: B.ROOT-SERVERS.NET rcnt 2 > Qfree(x58400) > ns_req: answer -> [151.186.20.4].3557 fd=5 id=2 size=170 Remote > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 > ;; flags: qr aa rd ra; Ques: 1, Ans: 2, Auth: 3, Addit: 2 > ;; QUESTIONS: > ;; news.sol.net, type = A, class = IN > > ;; ANSWERS: > news.sol.net. 86400 IN CNAME hummin.sol.net. > hummin.sol.net. 86400 IN A 204.95.172.243 > > ;; AUTHORITY RECORDS: > sol.net. 86400 IN NS dns1.sol.net. > sol.net. 86400 IN NS dns2.sol.net. > sol.net. 86400 IN NS spool.mu.edu. > > Ok. Wait a minute here :-) I don't remember sending TWO requests..?? > Note that the first one was directed at the fd associated with the "*" > device... "how odd!" And a reply was sent back. > > Well at this point I am at a loss and am about ready to call it a day > anyways. Any bright ideas, anyone? Your analysis seems to be the same as mine..... I came to the conclusion that it was a FreeBSD funnyism of some sort, that it didn't seem to hurt anything, and that I had bigger fish to fry on my list at the moment (and also right now). Anyone want to look at this? ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847