[DNSOP] Re: Add TTLs to DNS errors (draft-homburg-dnsop-de ttl-00.txt)

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]