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

I like the idea.

The biggest question is if clients are willing to implement this.
Do we have e.g. web folk around to comment on this?

Security Considerations comment follows below.

On 26. 06. 26 17:38, Philip Homburg wrote:
> In your letter dated Fri, 26 Jun 2026 07:26:13 +0200 you wrote:
>> However, I don't see how this solution can work. As the draft even
>> acknowledges, the attacker can spoof the error+TTL response, since the
>> crafted SOA (or whatever RR type) can't be DNSSEC-secured.
>>
>> Even when the TTL would be (upper bounded to) several seconds, can't the
>> attacker simply DoS anything easily by repeatedly poisoning the cache
>> with error+TTL?
> 
> I think the 'simply' is key.
> 
> In theory the connection could be authenticated DoX (currently between
> stub resolver and recursive, in the future maybe also between recursive
> and authoritative). In that the attack only come from the server itself.
> 
> In theory the connection can be TCP. In that case spoofing is possible for
> an on-path attacker but is pretty hard for an off-path attacker.
> 
> The request could go over UDP in which case an on-path attacker can obviously
> spoof. An off-path attack would have to guess ID, source port, QNAME, and
> possibly the client cookie. Not impossible, but not easy either.
> 
> We can turn it around. If an attacker can 'simply' spoof such an error
> reply, then what else can the attacker do?
> 
> In the case of an unsigned zone, the attacker can insert arbitrary data in
> the client's cache. I think in this case a DoS is the least of our worries.
> 
> In case of a signed zone, the attacker can insert bad DNSSEC replies. This
> also creates a DoS. If the DNSSEC validator treats an error reply similar
> to DNSSEC failures then there is no additional attack vector.

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.

5 minutes vs. 1 day TTL means an extra query every 300 seconds, which is 
damn close to most 'positive' TTLs these days anyway.

The biggest impact has going from 0 to 1 second. Everything above 1 
second is a nice bonus.

Perhaps we can stick to 300 s limit and be done with security 
considerations by copying what RFC 9520 has done?

> In sort, there is an attack vector. But compared to other attacks, the increase
> in attack potential is small.

I agree with this assessment.

-- 
Petr Špaček

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]