Al Varnell <alvarn...@mac.com> wrote: > So I think I have the answer for this one. From my research it would seem > that TTL values are set by the DNS server you are accessing, not by the > ClamAV and is the same for all records on that server. You would have to > check with the DNS ISP to find out if it has changed or not.
OK, there seems to be some confusion about how DNS works and what the TTL value does, and what lookups report. Dennis has sort of covered some of this, but it might help to see the whole process. When you do a lookup for a name, your client asks the locally configured resolver the question - eg what is the TXT record for current.cvd.clamav.net. Assuming the resolver has nothing in the cache, then it will go to the root servers and ask the same question. The root servers won't know, so they will reply to the effect of "I don't know, but the name servers <list of servers> have a better answer" - ie the name servers for .net So your resolver goes and asks the same question of one or more of those servers. They'll get the same "I don't know, but ..." answer, this time with a list of name servers handling clamav.net. The resolver will continue in this manner until it reaches far enough down the tree to get find a server that knows the answer. In this case, the nameservers for clamav.net (ns[2-7].clamav.net here*) know the answer and will return it. Using DIG, this is the chain of results, note that when using +trace, DIG deliberately ignores cached records and so the TTL values are those of the records as served by the relevant name server (except for the root servers which I assume it still uses the local resolver cache for - it has to start somewhere !) : $ dig +trace current.cvd.clamav.net txt ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +trace current.cvd.clamav.net txt ;; global options: +cmd . 45003 IN NS h.root-servers.net. . 45003 IN NS b.root-servers.net. . 45003 IN NS l.root-servers.net. . 45003 IN NS e.root-servers.net. . 45003 IN NS g.root-servers.net. . 45003 IN NS m.root-servers.net. . 45003 IN NS j.root-servers.net. . 45003 IN NS c.root-servers.net. . 45003 IN NS i.root-servers.net. . 45003 IN NS a.root-servers.net. . 45003 IN NS d.root-servers.net. . 45003 IN NS f.root-servers.net. . 45003 IN NS k.root-servers.net. ;; Received 508 bytes from 192.168.0.33#53(192.168.0.33) in 21 ms net. 172800 IN NS e.gtld-servers.net. net. 172800 IN NS m.gtld-servers.net. net. 172800 IN NS f.gtld-servers.net. net. 172800 IN NS a.gtld-servers.net. net. 172800 IN NS l.gtld-servers.net. net. 172800 IN NS b.gtld-servers.net. net. 172800 IN NS j.gtld-servers.net. net. 172800 IN NS c.gtld-servers.net. net. 172800 IN NS d.gtld-servers.net. net. 172800 IN NS h.gtld-servers.net. net. 172800 IN NS k.gtld-servers.net. net. 172800 IN NS g.gtld-servers.net. net. 172800 IN NS i.gtld-servers.net. ;; Received 509 bytes from 2001:7fe::53#53(2001:7fe::53) in 43 ms clamav.net. 172800 IN NS ns3.clamav.net. clamav.net. 172800 IN NS ns4.clamav.net. clamav.net. 172800 IN NS ns7.clamav.net. clamav.net. 172800 IN NS ns6.clamav.net. clamav.net. 172800 IN NS ns4a.clamav.net. clamav.net. 172800 IN NS ns1a.clamav.net. ;; Received 302 bytes from 192.42.93.30#53(192.42.93.30) in 44 ms current.cvd.clamav.net. 1800 IN TXT "0.99.2:57:22593:1479972755:1:63:45272:285" cvd.clamav.net. 7200 IN NS ns3.clamav.net. cvd.clamav.net. 7200 IN NS ns4.clamav.net. cvd.clamav.net. 7200 IN NS ns5.clamav.net. cvd.clamav.net. 7200 IN NS ns6.clamav.net. cvd.clamav.net. 7200 IN NS ns7.clamav.net. ;; Received 184 bytes from 2a01:4f8:160:8421::2#53(2a01:4f8:160:8421::2) in 38 ms Naturally it would be wasteful if the resolver did all these lookups every time, so it stores all the results it gets back in a local cache. So next time you lookup the same answer, it already has it. If you lookup a different .net address, it already knows which servers handle .net. And so on. So what is the TTL value ? Put simply, it's the maximum time your resolver should cache the record for. It doesn't mean the record should disappear, only that the resolver should discard it's cached copy after that time. As Dennis says, if you ask your local resolver repeatedly, you'll see the TTL value dropping - this is the time remaining before the resolver must discard the record. Once that time drops to zero, the record is removed from the cache. Next time you look it up, the resolver must go and ask the question again to get the current answer. It will use whatever results it still has in the cache to shorten the sequence needed - so we can see here that the .net NS records have a TTL value of 2 days because they aren't going to change very often, and it means our local resolver should never need to go and ask the root servers for them more than once every two days. At the other extreme, the TXT for current.cvd.clamav.net is just half an hour - because it changes frequently and we want users to get the new value reasonably quickly. Depending on timing, users will see a lag between 0 and 1800s between the record changing and when they see the new value. Oh yes, and TTL values can be set globally for each zone, and also on a per record basis. So you can lookup a record as often as you like, but it won't actually change more often that the TTL length. Eg, you could lookup the current.cvd.clamav.net value every minute - but it'll only change when that 1/2 hour TTL expires. Here's the result of doing the same lookup a short time apart (without the +trace option). Here' it's using my local nameserver cache and you can see the times dropping between the lookups. $ dig current.cvd.clamav.net txt ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> current.cvd.clamav.net txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26666 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5 ;; QUESTION SECTION: ;current.cvd.clamav.net. IN TXT ;; ANSWER SECTION: current.cvd.clamav.net. 1800 IN TXT "0.99.2:57:22593:1479972755:1:63:45272:285" ;; AUTHORITY SECTION: cvd.clamav.net. 749 IN NS ns3.clamav.net. cvd.clamav.net. 749 IN NS ns5.clamav.net. cvd.clamav.net. 749 IN NS ns7.clamav.net. cvd.clamav.net. 749 IN NS ns6.clamav.net. cvd.clamav.net. 749 IN NS ns4.clamav.net. ;; ADDITIONAL SECTION: ns3.clamav.net. 36431 IN A 193.28.86.61 ns4.clamav.net. 760 IN A 5.9.14.57 ns4.clamav.net. 760 IN AAAA 2a01:4f8:160:8421::2 ns6.clamav.net. 36431 IN A 208.201.249.238 ns7.clamav.net. 36431 IN A 209.204.159.15 ;; Query time: 45 msec ;; SERVER: 192.168.0.33#53(192.168.0.33) ;; WHEN: Thu Nov 24 07:53:03 2016 ;; MSG SIZE rcvd: 276 $ dig current.cvd.clamav.net txt ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> current.cvd.clamav.net txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20064 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5 ;; QUESTION SECTION: ;current.cvd.clamav.net. IN TXT ;; ANSWER SECTION: current.cvd.clamav.net. 1328 IN TXT "0.99.2:57:22593:1479972755:1:63:45272:285" ;; AUTHORITY SECTION: cvd.clamav.net. 277 IN NS ns4.clamav.net. cvd.clamav.net. 277 IN NS ns5.clamav.net. cvd.clamav.net. 277 IN NS ns6.clamav.net. cvd.clamav.net. 277 IN NS ns7.clamav.net. cvd.clamav.net. 277 IN NS ns3.clamav.net. ;; ADDITIONAL SECTION: ns3.clamav.net. 35959 IN A 193.28.86.61 ns4.clamav.net. 288 IN A 5.9.14.57 ns4.clamav.net. 288 IN AAAA 2a01:4f8:160:8421::2 ns6.clamav.net. 35959 IN A 208.201.249.238 ns7.clamav.net. 35959 IN A 209.204.159.15 ;; Query time: 27 msec ;; SERVER: 192.168.0.33#53(192.168.0.33) ;; WHEN: Thu Nov 24 08:00:55 2016 ;; MSG SIZE rcvd: 276 * Lastly, while I've got ns[3-7].clamav.net, I suspect the system may be configured to give out different sets of servers to different users - either on a timed basis so they rotate a bit, or on a (network) geography basis. This is a common trick for spreading load around multiple servers. Edit: Yes indeed, I've just done another lookup before sending this, and the list has changed for me. I hope this clears up any confusion. _______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
