Mailing List Archive

Hi there,

On Fri, 29 Jan 2021, Gary R. Schmidt wrote:

> I've just noticed that freshclam has logged "DNS record is older than 3
> hours." twice in the last few days.
>
> It's not a problem, I just wonder that the underlying cause could be - is it
> just that DNS updates somewhere in there are slow on occasion??

It's probably not a problem for ClamAV, but if it keeps happening it
might indicate there's something which does need your attention.

Freshclam likes to know that things are up to date, and it's a little
unhappy about what it's found. I've seen this message just once, last
September. It seemed to coincide with a network outage. As it never
happened again and it depends on quite a few imponderables, apart from
checking that things were otherwise OK AFAICT, I ignored it.

If you look at the code in .../libfreshclam/libfreshclam_internal.c at
around lines 1590-1640 in the latest version you'll see that (1) this
part of the code is only compiled under some circumstances, (2) it is
a fallback for when the primary means of getting the database version
fails and (3) the warning is only emitted if the time provided by the
system and the timestamp on the DNS record differ by more than 10800
seconds (a rather nasty hard-coded value in the source).

My first check would be that the timestamps on all the log entries at
about the time that the messages were emitted make some sort of sense.
They will if your system clock is properly set at boot, before things
which rely on it can use it, and that it *stays* that way, reliably
providing the correct time, at all times. It's vital. The system
clock *must* be reliable. All my systems run chronyd (except for the
odd one or two which run the more capable but much more troublesome
ntpd), and Nagios/Icinga check that all the clocks stay within a few
milliseconds of UTC. For the sake of confidence I look at the graphs
now and then, and I'll investigate if any system seems to be going out
by more than 5ms for any length of time - which can happen to some VMs
if you aren't careful - and I'll get an email alert if the time on any
system goes way off the reservation. (In my view that means +/- 25ms.
Nuke it from orbit, it's the only way to be sure. :)

Assuming that I was satisfied that the system time was beyond reproach
my second check would be that DNS resolution is reliable. Do you run
a name server, or do you rely on some e.g. consumer firewall/router,
or something from an ISP, or....? Running nameservers is out of scope
for this list and a short email, but again things like Nagios can help
check the reliability of the service.

--

73,
Ged.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

On 29/01/2021 21:57, G.W. Haywood via clamav-users wrote:
> Hi there,
>
> On Fri, 29 Jan 2021, Gary R. Schmidt wrote:
>
>> I've just noticed that freshclam has logged "DNS record is older than
>> 3 hours." twice in the last few days.
>>
>> It's not a problem, I just wonder that the underlying cause could be -
>> is it just that DNS updates somewhere in there are slow on occasion??
>
> It's probably not a problem for ClamAV, but if it keeps happening it
> might indicate there's something which does need your attention.
>
[SNIP]
> If you look at the code in .../libfreshclam/libfreshclam_internal.c at
> around lines 1590-1640 in the latest version you'll see that (1) this
> part of the code is only compiled under some circumstances, (2) it is
> a fallback for when the primary means of getting the database version
> fails and (3) the warning is only emitted if the time provided by the
> system and the timestamp on the DNS record differ by more than 10800
> seconds (a rather nasty hard-coded value in the source).
>
Yep, been there and had a look, just in case it was a symptom of
something nasty.

> My first check would be that the timestamps on all the log entries at
> about the time that the messages were emitted make some sort of sense.
>
[SNIP]

Hi Ged,

Some background:
Solaris 11.4 Intel server, patched up to date.
It's the local DNS, NTP, SMTP, and so forth server.

The caching DNS talks to OpenDNS first, because I like to get
correct-ish answers.
NTP talks to the various .au.pool.ntp.org servers.

(I am ancient BOFH, HR will be talking to me about long-term recovery in
the next few years. :-) )

It logs pretty much everything, and I'd already had a shufty at them,
the only thing mentioned around then is freshclam doing its thing.

But!!

Your suggestions made a buried memory surface, for some reason we log
all the DNS traffic, but under /var/named/log, because who wants all
that guff flooding your normal logging area.

I went and had a look, at the time of the message there was trouble in
River City:
26-Jan-2021 18:03:16.094 lame-servers: info: REFUSED unexpected RCODE
resolving 'play.googleapis.com/TYPE65/IN': 208.67.222.222#53

With variations, for about a second, in the "auth_servers" channel.

So possibly there was a problem with getting to the OpenDNS servers,
they're only in Sydney, about 10 hops away, but if the network betwixt
us got clogged or foosled for a moment that may explain it.

It doesn't seem to cause any problems, and it is, after all, only a
warning, and the databases seem to be updating around midnight here, so
I'll not worry about it unless it becomes a fixture.

Thanx for the prod that reminded me we have other logs. :-)

Cheers,
Gary B-)

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

> On Jan 29, 2021, at 7:50 AM, Gary R. Schmidt <grschmidt@acm.org> wrote:
>
> On 29/01/2021 21:57, G.W. Haywood via clamav-users wrote:
>> Hi there,
>> On Fri, 29 Jan 2021, Gary R. Schmidt wrote:
>>> I've just noticed that freshclam has logged "DNS record is older than 3 hours." twice in the last few days.
>>>
>>> It's not a problem, I just wonder that the underlying cause could be - is it just that DNS updates somewhere in there are slow on occasion??
>> It's probably not a problem for ClamAV, but if it keeps happening it
>> might indicate there's something which does need your attention.
> [SNIP]
>> If you look at the code in .../libfreshclam/libfreshclam_internal.c at
>> around lines 1590-1640 in the latest version you'll see that (1) this
>> part of the code is only compiled under some circumstances, (2) it is
>> a fallback for when the primary means of getting the database version
>> fails and (3) the warning is only emitted if the time provided by the
>> system and the timestamp on the DNS record differ by more than 10800
>> seconds (a rather nasty hard-coded value in the source).
> Yep, been there and had a look, just in case it was a symptom of something nasty.
>
>> My first check would be that the timestamps on all the log entries at
>> about the time that the messages were emitted make some sort of sense.
> [SNIP]
>
> Hi Ged,
>
> Some background:
> Solaris 11.4 Intel server, patched up to date.
> It's the local DNS, NTP, SMTP, and so forth server.
>
> The caching DNS talks to OpenDNS first, because I like to get correct-ish answers.
> NTP talks to the various .au.pool.ntp.org servers.
>
> (I am ancient BOFH, HR will be talking to me about long-term recovery in the next few years. :-) )
>
> It logs pretty much everything, and I'd already had a shufty at them, the only thing mentioned around then is freshclam doing its thing.
>
> But!!
>
> Your suggestions made a buried memory surface, for some reason we log all the DNS traffic, but under /var/named/log, because who wants all that guff flooding your normal logging area.
>
> I went and had a look, at the time of the message there was trouble in River City:
> 26-Jan-2021 18:03:16.094 lame-servers: info: REFUSED unexpected RCODE resolving 'play.googleapis.com/TYPE65/IN': 208.67.222.222#53
>
> With variations, for about a second, in the "auth_servers" channel.
>
> So possibly there was a problem with getting to the OpenDNS servers, they're only in Sydney, about 10 hops away, but if the network betwixt us got clogged or foosled for a moment that may explain it.
>
> It doesn't seem to cause any problems, and it is, after all, only a warning, and the databases seem to be updating around midnight here, so I'll not worry about it unless it becomes a fixture.
>
> Thanx for the prod that reminded me we have other logs. :-)


For context for the thread, because I may have missed it… what version of ClamAV?

On 30/01/2021 01:04, Joel Esler (jesler) via clamav-users wrote:
>
[SNIP]
>
> For context for the thread, because I may have missed it… what version of ClamAV?
>
Oops!

Clam AntiVirus: Daemon Client 0.103.0


Cheers,
Gary B-)

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml