On 14. 07. 26 11:58, Philip Homburg wrote:
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?
The real deployment already decided that 5 minutes is plenty, judging by
TTLs observed in the field. But that's completely besides the point, see
below.
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?
No. We already have protocol to protection for those who care - sign
your zones. This proposal adds a signal which cannot be signed so the
traditional answer (DNSSEC) is not applicable. That's why I ask about
the upper limit.
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.
If this logic was acceptable for the WG then RFC 9520 authors _would not
have_ to pick a value.
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.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
