On 14. 11. 25 12:13, Philip Homburg wrote:
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.
Care to start a draft on that topic? :-)
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
