Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Feb 2004 18:02:19 -0500 (EST)
From:      Kenneth W Cochran <kwc@TheWorld.com>
To:        Mark.Andrews@isc.org
Cc:        freebsd-stable@freebsd.org
Subject:   Re: DNS problem
Message-ID:  <200402022302.SAA19225393@shell.TheWorld.com>

next 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 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 <kern.info> localhost /kernel: Connection attempt to UDP 192.
>> 168.0.1:3826 from 192.168.0.1:53
>> Feb  2 09:17:39 <kern.info> localhost /kernel: Connection attempt to UDP 192.
>> 168.0.1:3827 from 192.168.0.1:53
>> Feb  2 09:20:28 <kern.info> localhost /kernel: Connection attempt to UDP 192.
>> 168.0.1:3853 from 192.168.0.1:53
>> Feb  2 09:20:33 <kern.info> localhost /kernel: Connection attempt to UDP 192.
>> 168.0.1:3854 from 192.168.0.1:53
>> Feb  2 09:20:43 <kern.info> localhost /kernel: Connection attempt to UDP 192.
>> 168.0.1:3855 from 192.168.0.1:53
>> Feb  2 09:21:01 <kern.info> 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.

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?

>	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.

Where might I find this documented?

Many thanks,

-kc

>> 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.
>>
>> Any ideas/suggestions/suggested reading?
>--
>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?200402022302.SAA19225393>