Daniel Margolis пишет: > > > On Sat, May 14, 2016 at 1:19 AM, Vladimir Dubrovin > <[email protected]> wrote: > > 2. Standard should specify recommended time for negative policy > response > caching for existing domains, overwise it can lead to overload for > DNS/Web infrastructure. > > > The HTTPS lookup only happens if the DNS record resolves, so in the > negative case this should only result in a single DNS lookup. (If the > "policy ID" from the STS TXT record is unchanged, there is again no > HTTPS lookup.) So we're effectively talking about a second DNS lookup > per mail send--on top of the existing MX and host resolutions. > > I don't expect this to be a significant amount of load on the DNS > infrastructure, since DNS already supports native negative result > caching. > >
There are at least 2 reasons to specify minimum cache time for negative results in the standard: 1. One can use this time to ratelimit requests to policy server and prevent DDoS against policy server without risks to affect clients. It's really important, because policy server is a point of failure for mail system. 2. I'm not sure it can be applied in the case of policy server with MTA as a client, but it's general approach to avoid situation like this: Given - Your have single server and can handle 1000 reqests per second. - Your current LA (load averages) are 30% with 300 rps. - If LA reaches 100%, all requests begin to timeout (sadly to say, it's quite usual for many HTTP applications) Now imagine, you had some problems (blackout, network connectivity problems, etc) for e.g. 3 hours. If negative responses are not cached by client, client makes request for every delivery attempt for every message in queue. Lets say, client retries failed attempt every 15 minutes.It means, after 3 hours you will have >3000 requests per second instead of average 300 rps, 3 times more than your server can handle. And rps still growing, because all requests timeouts, so recovering is extremaly hard. If you set minimum caching time, client do one attempt in a caching time despite the number of the messages in the queue, so there is no linear growth. -- Vladimir Dubrovin @Mail.Ru
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
