> The only difference I can see is this draft allows the attacker to > (if the client is willing) override the hardcoded DNSSEC validation > failure TTL with an attacker-supplied value. In all other cases > attacker can already do more damage. > > I.e. we are back at the question of TTL upper bound discussed in > https://datatracker.ietf.org/doc/html/rfc9520#section-5 It seems > to apply here as well. > > > Is there a value in caching failures for more than 5 minutes? Even > if something is known to be down for a day, I can't imagine an > operator willingly saying 'do not retry for the whole day' anyway.
I worry we go down a path of overspecifying how this should work. For example, if an attacker can spoof TTLs for errors then with the same effort an attacker can also spoof A records for unsigned zones. We do not (at the protocol level) limit how long A records can be cached. Then why could we limit the error TTL to 5 minutes? The point of caching to reduce the load. If 5 minutes is fine, then can we limit all TTLs to 5 minutes? If not why not. And why would caching erros be different? > 5 minutes vs. 1 day TTL means an extra query every 300 seconds, > which is damn close to most 'positive' TTLs these days anyway. It seems that you propose that all unsigned data should be cached for at most 5 minutes. Maybe you want to write an RFC about that? I can imagine that RFC 9520 had to pick a number and that 5 minutes seems resonable. But I'm not aware of any RFC that limits TTLs to this value. And 5 minutes also doesn't seem a common default value for DNS client software. > The biggest impact has going from 0 to 1 second. Everything above > 1 second is a nice bonus. We already have RFC 9520. So you are saying that this draft is not needed? > Perhaps we can stick to 300 s limit and be done with security > considerations by copying what RFC 9520 has done? The principle of TTL so far is that the server decides what is a reasonable TTL and it is upto clients to limit that to a sensible value. What makes error TTL so different from TTLs of unsigned data that we need more strict limits? DNSSEC is a lot more complex. Some validator code is subject to the same DoS attacks as decribed for error TTLs. In that case, there is no need to treat error TTLs differently. Other validator code is more aggressive in retrying for DNSSEC failures. In that case the error TTL should be limited to a lower value. However, this very much depends on the client. So it is better to leave it to client's discretion. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
