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]
