Le 19/07/2023 à 19:53, Michael Peddemors a écrit :
Real world is a bit different.. DNS Caching.. While DNS Round Robin is good enough to distribute loads, it isnt' a very good method for failover, even with a very short TTL. Many home routers, still insist on caching results for a long time, no matter what the TTL says, and of course Windows internal caching etc..
Should not confuse the issue.. call it a 'poor man's load balancer' if you will, but it more of a last line failover, and during the time it takes for DNS to retry, and find another active node, an AWFUL lot of disgruntled customers will be calling ;)
Also so interesting to see some resolvers that don't think of using the second record, if the first one is down..
You're mixing things : DNS and Mail client behavior. It is a non sense. A resolver will serve records, It does not use them and do not care of what is behind the record. A good client use the lists (of A or AAAA) records to connect to the server and will iterate on the list if the server behind the record is down. And DNS caching do it job nothing less, nothing more and is out of the picture.
Emmanuel is right. Here's an example to clarify:
$ dig imap.web.de
;; ANSWER SECTION: imap.web.de. 226 IN A 212.227.17.178 imap.web.de. 226 IN A 212.227.17.162
A dns query for imap.web.de address records (IN A) returns two ip addresses. A local resolver receives those two ip addresses and usually passes them on to clients while it may rotate the order, so that some clients will see 212.227.17.178, 212.227.17.162 and others will see 212.227.17.162, 212.227.17.178. It is possible to get the same order for subsequent requests but on a *global* scale that roughly equals 50/50 loadbalancing.
Mail clients then connect to e.g. 212.227.17.178 and try 212.227.17.162 on connection failure without any further dns involvement. Dns caching (ttl) is irrelevant in that case.
Best regards, Gerald