On 11/04/18 02:14, Peter Viskup wrote: > Squid use TTL of 60 seconds for DNS resource records with TTL smaller > than that value. > > Some sites can have DNS TTL set to lower value due to high availability > design (DNS load balancer). > > In RFCs [1][2][3] it is explained the received TTL can be lowered to the > upper bound TTL value of DNS cache, but not to increase it. > > Is it possible to change that 60 seconds default somewhere in > configuration? Was the 60 seconds default chosen according some reference? > <http://www.squid-cache.org/Doc/config/negative_dns_ttl/> Please note that Best Practice for DNS records is to use *24 hour* TTLs as the minimum. Shorter times are provided to allow for clean server migrations, not for load balancing. RRset rotation is for DNS load balancing, is enabled in most resolvers by default and does not require short TTLs to operate. It is also compatible with the behaviour of load balancing mechanisms in every protocol from TCP itself up the stack (ie they are designed to account for rotation, not for widespread abusive TTLs). Since you ask; One reason Squid sets a minimum is that extremely short TTLs in DNS conflicts directly with both HTTP persistence mechanisms and the load balancing performed by Squid itself. The default ensures that for any given server IP Squid can re-use persistent connections to it for ~60 seconds. NP: These services are actually *worsening* their service times. Squid and numerous other middleware now has to ignore already setup and perfectly usable connections in order to perform several entire TCP (and TLS) handshake processes all over again for the changed IPs. Another (which no longer applies) was that Squid used to base each new retry attempt on new DNS record lookup. If the RRset changed on every retry it could end up trying the same IP from a large set N times in a row and failing when a different IP from the same RRset would be fine. Current Squid do a single lookup and only retry the IPs found there (think about what that means for TTL). This was explicitly to workaround and counter the breakages caused by those servers you mention doing short TTLs. Consider, what would you expect to happen when DNS RRset changes _multiple_ times within the same TTL that TCP uses for a SYN-ACK timeout and retry? > [1] https://tools.ietf.org/html/rfc2181#section-8 > <https://tools.ietf.org/html/rfc2181#section-8> > [2] https://tools.ietf.org/html/rfc1035#section-3.2.1 > <https://tools.ietf.org/html/rfc1035#section-3.2.1> > [3] https://tools.ietf.org/html/rfc7719#section-4 > <https://tools.ietf.org/html/rfc1035#section-3.2.1> Which states: "Some servers are known to ignore the TTL on some RRsets (such as when the authoritative data has a very short TTL)". Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
