From owner-freebsd-stable@FreeBSD.ORG Mon Feb 2 12:41:54 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D56CB16A4CE for ; Mon, 2 Feb 2004 12:41:54 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 100A043D2D for ; Mon, 2 Feb 2004 12:41:34 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i12KfQ7E000860; Mon, 2 Feb 2004 12:41:30 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200402022041.i12KfQ7E000860@gw.catspoiler.org> Date: Mon, 2 Feb 2004 12:41:26 -0800 (PST) From: Don Lewis To: kwc@TheWorld.com In-Reply-To: <200402021603.LAA18667215@shell.TheWorld.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT cc: freebsd-stable@FreeBSD.org Subject: Re: DNS problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2004 20:41:55 -0000 On 2 Feb, Kenneth W Cochran wrote: >>Date: Sun, 1 Feb 2004 12:36:27 -0800 (PST) >>From: Don Lewis >>To: kovacspeter2@freemail.hu >>Cc: freebsd-stable@freebsd.org >>Subject: Re: DNS problem >> >>On 1 Feb, Kovács Péter wrote: >>> Hello, >>> >>>> Which server in your organization is acting as a DNS >>>> server? >>> The Windows... >>> >>>> If you only have one network card in your FreeBSD box... >>> Yes, I only have one. >>> >>>> This could be why you only see this kind of traffic with one IP address. >>> Is there a way to fix this? >> >>Something on your FreeBSD box is sending DNS queries to your Windows box >>and is timing out its query and closing the socket it used to send the >>query before the Windows box returns its response. Because you have >>net.inet.udp.log_in_vain enabled, your FreeBSD box logs the arrival of >>the DNS response packet because there is not a UDP socket listening on >>the port that the response is being returned to. >> >>About all you can do to turn off these messages is to turn off >>udp.log_in_vain. As a substitute you could log unexpected packets using >>one of the firewall packages on FreeBSD, which would allow you to ignore >>packets coming from port 53 on your DNS server. > > I get similar messages, viz: > > Feb 2 09:16:59 localhost /kernel: Connection attempt to UDP 192.168.0.1:3826 from 192.168.0.1:53 > Feb 2 09:17:39 localhost /kernel: Connection attempt to UDP 192.168.0.1:3827 from 192.168.0.1:53 > Feb 2 09:20:28 localhost /kernel: Connection attempt to UDP 192.168.0.1:3853 from 192.168.0.1:53 > Feb 2 09:20:33 localhost /kernel: Connection attempt to UDP 192.168.0.1:3854 from 192.168.0.1:53 > Feb 2 09:20:43 localhost /kernel: Connection attempt to UDP 192.168.0.1:3855 from 192.168.0.1:53 > Feb 2 09:21:01 localhost /kernel: Connection attempt to UDP 192.168.0.1:3856 from 192.168.0.1:53 > > Sysctl log_in_vain is is set for both tcp & udp. > > It has been like this for ages and so far I can find > neither an explanation as to why, no a way to fix it > (assuming it is some kind of breakage/misconfiguration). > OS is 4.9-stable as of 15 January, 2004. > > There is indeed a Windows box at 192.168.0.2, but DNS is on > the FreeBSD machine, configured as cache-only (supposedly; > could be something not quite correct in that config...) > > There are 2 network interfaces and the syslog indicates > (I think correctly) named listening on both of them when it > starts. 192.168.0/24 is on an internal interface/network; > the external interface gets its ip-address from the ISP > via DHCP. > > What I'd like to do is 1. fix any errors/misconfigurations > that might be causing those messages and 2. keep the > cache-only nameserver, and have it run/query efficiently. You've got the same problem as in the previous message. In this case the DNS client on your machine is closing the socket that was listening for the DNS response before your caching-only DNS server on the same machine is sending its response. Note the IP addresses in the log messages: Connection attempt to UDP 192.168.0.1:3826 from 192.168.0.1:53 Log_in_vain thinks your machine is "attacking" itself. I'd recommend turning off net.inet.udp.log_in_vain, and if you want to log unexpected UDP packets, do it using ipf or ipfw where you can tune what is logged and what is ignored.