Squid ipcache and DNS TTL smaller than 60 seconds

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Squid ipcache and DNS TTL smaller than 60 seconds

Peter Viskup
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?

[1] https://tools.ietf.org/html/rfc2181#section-8
[2] https://tools.ietf.org/html/rfc1035#section-3.2.1
Peter

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid ipcache and DNS TTL smaller than 60 seconds

Amos Jeffries
Administrator

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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid ipcache and DNS TTL smaller than 60 seconds

Alex Rousskov
On 04/10/2018 09:19 AM, Amos Jeffries wrote:

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

I would expect that nothing special happens to a good implementation:
The TCP client would not notice the TTL expiration and RRset changes
while dealing with packets on a single TCP connection.

RRset TTL does _not_ mean that the client of a DNS cache cannot use the
answer after the TTL expires. It means that the DNS cache itself should
not return a stale answer to its client after the TTL expires. There is
an architectural boundary between a DNS cache and a client of that DNS
cache. Squid implementation may violate that boundary, but that Squid
problem is not a good (long-term) justification for violating server TTLs.

Connection reuse problems that you have described could be a good
justification for a default minimum TTL of 60 seconds. IMHO, it is not a
valid long-term justification for violating server TTLs when the admin
wants to honor them.


Cheers,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users