Date: Tue, 03 Feb 2004 10:25:10 +1100 From: Mark.Andrews@isc.org To: Kenneth W Cochran <kwc@TheWorld.com> Cc: freebsd-stable@freebsd.org Subject: Re: DNS problem Message-ID: <200402022325.i12NPAcc035872@drugs.dv.isc.org> In-Reply-To: Your message of "Mon, 02 Feb 2004 18:02:19 CDT." <200402022302.SAA19225393@shell.TheWorld.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >To: Kenneth W Cochran <kwc@TheWorld.com> > >Cc: Don Lewis <truckman@freebsd.org>, freebsd-stable@freebsd.org > >From: Mark.Andrews@isc.org > >Subject: Re: DNS problem > >Date: Tue, 03 Feb 2004 07:28:29 +1100 > > > >> >Date: Sun, 1 Feb 2004 12:36:27 -0800 (PST) > >> >From: Don Lewis <truckman@freebsd.org> > >> >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 addres > s. > >> >> 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 <kern.info> localhost /kernel: Connection attempt to UDP 1 > 92. > >> 168.0.1:3826 from 192.168.0.1:53 > >> Feb 2 09:17:39 <kern.info> localhost /kernel: Connection attempt to UDP 1 > 92. > >> 168.0.1:3827 from 192.168.0.1:53 > >> Feb 2 09:20:28 <kern.info> localhost /kernel: Connection attempt to UDP 1 > 92. > >> 168.0.1:3853 from 192.168.0.1:53 > >> Feb 2 09:20:33 <kern.info> localhost /kernel: Connection attempt to UDP 1 > 92. > >> 168.0.1:3854 from 192.168.0.1:53 > >> Feb 2 09:20:43 <kern.info> localhost /kernel: Connection attempt to UDP 1 > 92. > >> 168.0.1:3855 from 192.168.0.1:53 > >> Feb 2 09:21:01 <kern.info> localhost /kernel: Connection attempt to UDP 1 > 92. > >> 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. > > So let me try to restate/rephrase what is going on... > > > Your resolver asks the same question multiple times to multiple > > servers. It closes the socket after it gets the first answers. > > It is *normal* to receive answers from the other server after > > the first answer. > > "My" resolver makes some queries from some high port > to port 53 of whatever nameserver(s) it is configured > (explicitly or by default) to query. The answers come back > from port 53 of that/those servers to that originating > (high) port. As soon as it gets an answer, it closes > that high port from which it was asking. This all happens > via UDP? Yes. This is all built into the C library. Note if the answer is too small for UDP the client will be told by setting TC in the UDP answer then the resolver will re-query using TCP. > > It is also *normal* to receive answers late if the nameserver > > cannot resolve the answer. In this case it sends SERVFAIL to > > say that it is giving up. Usually the client has timed-out > > and closed the socket before that has happened. > > So the logged messages I'm seeing are resulting from ports > that were closed (well, actually no longer listening) > following an answer to the original query. (?) > > In other words - originating query-port (high) got closed > b/c the resolver got some answer, therefore there's no > longer a listener on it, therefore the logged message(s). > > Correct? > > Is this configurable somehow? Sounds like it might not be, > as it appears to be a *resolver* behavior rather than that > of the nameserver. No. It is not configurable. It is a consequence of using UDP. UDP does not have connections. It just has datagrams. UDP is choosen for the initial query because 1. the messages are small 2. the number of clients using a server at one time is large (each of the root servers handle ~13000 clients/sec). The only thing wrong here is that log-in-vain UDP doesn't have the equivalent of the TCP TIME_WAIT state which handles late anwers. > Where might I find this documented? > > Many thanks, > > -kc -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402022325.i12NPAcc035872>