Op 17-03-2025 om 15:14 schreef Peter Thomassen:
On 3/17/25 20:18, Willem Toorop wrote:But many zones are still not DNSSEC signed. Making sure that responses are answered by the correct authoritative name servers (NS revalidation), protects the unsigned zonesThe thing is, there is no "making sure".
There is making sure if the authoritative NS RRset is signed (and also the addresses with the names it refers to).
And this could for example be the NS RRset of .com protecting therefore many unsigned second level domains (you know who those are).
If the referral for an insecure delegation is spoofed, then NS revalidation won't help you, as any serious attacker will set up their fake zones to contain an apex RRset different from the original one.
There is also a benefit with insecure delegations. Because the authoritative data is preferred, there is less opportunity to hijack once the authoritative data is in cache. As long as the authoritative data is not in cache, there is opportunity for an adversary to spoof this authoritative data. Many of the attacks summarized in [1] work on this principle.
Of course, as the draft also mentions and is also mentioned in the referenced Cache Injections paper[1], resolvers that only use the non-authoritative parent side NS RRsets and glue returned in referral responses for contacting authoritative name servers (such as the akamai resolver) are not susceptible to these kind of attacks. However, such resolvers will also never benefit from DNSSEC protection of infrastructure RRsets and are thus susceptible to query redirection attacks. Also, DNSSEC protection of infrastructure RRsets (through NS revalidation) is the only mitigation that also counters on-path (or partially on-path) attacks [2].
Section "Redirected query traffic" of this report [2], has an extensive impact and risk analysis of "redirected query traffic", including the positive impact that revalidation has. It is this report that made me want to help out with the NS revalidation draft.
-- Willem[1] Klein, A., Shulman, H., and M. Waidner, "Internet-Wide Study of DNS Cache Injections", n.d., <https://ieeexplore.ieee.org/abstract/document/8057202>.
[2] https://www.icann.org/en/system/files/files/reduced-risk-redirected-query-traffic-signed-root-name-server-data-22may24-en.pdf
This is actually the main point I've never understood about revalidation. (What definition if "validation" is actually being used here? It's more like a consistency check.)Best, Peter
OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
