In your letter dated Fri, 14 Nov 2025 10:25:43 +0100 you wrote: >I agree this would be useful protocol work, albeit long-term. Until we >have that I think "NS ." will do more harm than good.
I agree. At the moment SERVFAIL is not a good signal for a persistent condition. >More seriously: >Perhaps for scenarios where client trusts the remote end to do recursion >and takes answers from it at their face value (typical for global >forwarding) then perhaps it would make sense. > >Too bad we don't have threat model written down anywhere for forwarding >scenario... Or do we? Is there a document I have missed? I agree that a good security analysis is required. As far as I know there is no document that describes the threat model of forwarding. That said, I don't think there is a big problem here: - Most zones are not DNSSEC signed. It doesn't matter if the attacker inserts a SERVFAIL with a high TTL or an NXDOMAIN with a high TTL or something else. - stub (or forwarder) to resolver can use encrypted transports. The proxy on my laptop connects over TLS to a few recursors. - with a signed zone, if the stub or forwarder doesn't do DNSSEC validation, then the attack possibilities are the same as for an unsigned zone. So the interesting case is a signed zone and stub or validator that does DNSSEC vaidation (and uses Do53). With a TTL for SERVFAIL, an attacker is limited to a DoS attack. That's it. However, (at least in my implementation) if an attacker would manage to corrupt an RRSIG then that would have the same DoS effect. So I'd argue that this is not a new attack. Though I don't know how hard other implementations retry if they get an RRSIG they can't validate. So the attack opportunities are limited and an attacker with those capabilities is more likely to attack unsigned zones in a more creative way. Lastly, encrypting the connection between stub/forwarder to recursor solves a lot of problems, including this one. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
