[squid-users] Squid ipcache and DNS TTL smaller than 60 seconds

[Amos Jeffries]

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