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. In sort, there is an attack vector. But compared to other attacks, the increase in attack potential is small. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
