On 3/17/25 17:16, Willem Toorop wrote:
Op 17-03-2025 om 16:39 schreef Peter Thomassen:
On 3/17/25 21:37, 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 zones
The thing is, there is no "making sure".
There is making sure if the authoritative NS RRset is signed
:-)
I was responding to your claim about unsigned zones. There is no
making sure via NS re-validation for them, precisely because the
authoritative NS RRset is not signed.
The claim stands! My claim is that protecting DNSSEC signed delegations
(like almost all of the TLDs) by NS revalidation also protects all the
DNSSEC unsigned zones that are delegated from those zones. I elaborate a
bit further on that topic below.
For secure zones, you surely can look-up the authoritative (child-
side) NS RRset and DNSSEC-validate it, exposing a fake referral.
However, you'd also detect that without NS revalidation (at the cost
of compromising privacy of the next query's question).
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.
Eventually, the parent-side delegation will be refetched and override
the authoritative data, because the domain might have been redelegated.
As an attacker who's in a position to serve fake stuff to a resolver,
wouldn't you thus spoof the referral, and the next time it gets
fetched, you win?
That is correct.
I'm ready to be told that I'm just getting this wrong, but the above
points are the core to me. So let me rephrase this as a question:
- For unsigned delegations, NS revalidation makes attack timing more
challenging (between caching the auth NS RRset and the delegation re-
fetch).
Indeed. It also does not counter /on-path/ or partly /on-path/ attacks.
- For signed delegations, NS revalidation protects the privacy of the
actual query.
And in addition to that prevents all unsigned parts of the hijacked zone
to be rewritten. For example if com is hijacked, unsigned zones like
google.com can be redirected. Similarly if the root is hijacked all
unsigned responses for the entire DNS can be rewritten.
TL;DR:
This draft presents a complex workaround for protocol quirks and comes
with constant operational cost (see last paragraph of section 8.3 of the
draft).
At the same time there are better protocol alternatives which have
better systemic effects on the DNS ecosystem. For this reason this draft
does not cut the cost/benefit for BIND. See below for a very long
explanation.
Long version:
In my view, domain owners (or operators who run the domain for them)
don't consider cache poisioning to be a significant risk. If it was
considered significant we would see much higher DNSSEC deployment rate
then we see today.
This implies this draft is an attempt to add workaround for people who
don't care about security in the first place. That does not sound like a
compelling reason to complicate the protocol and implementation!
Unbound already has it - good - make it into a selling point and
convince people it is worth migrating!
From BIND's point of view, the resources needed to implement, test, and
maintain protocol in this draft are not worth it.
Alternatives with better payoff are:
A. I-D.fujiwara-dnsop-resolver-update
Why is this approach better is partially explained in the revalidation
draft itself, section 8.3. Quote:
Some resolvers do not adhere to Sections 5.4.1 and 6.1 of [RFC2181], and only
use the non-authoritative parent side NS RRsets and glue returned in referral
responses for contacting authoritative name servers
[I-D.fujiwara-dnsop-resolver-update]. As a consequence, they are not
susceptible to many of the cache poisoning attacks enumerated in
[DNS-CACHE-INJECTIONS] that are based upon the relative trustworthiness of DNS
data. Such resolvers are also not susceptible to the GHOST domain attacks
[GHOST1], [GHOST2]. Such resolvers will however never benefit from DNSSEC
protection of infrastructure RRsets and are susceptible to query redirection
attacks.
Additionally, this approach does not come with running operational cost
described in the last paragraph of the same section:
Revalidating referral and authoritative NS RRset responses will induce more
traffic from the resolver to the authoritative name servers. The traffic
increase may be substantial if the address RRsets for the names in the NS
RRset's RDATA were provided non-authoritatively (as glue or as additional
addresses) and need revalidation too [REDIRECTED-QUERY-TRAFFIC]. Resolvers
SHOULD take care to limit the amount of work they are willing to do to resolve
a query to a sensible amount.
Even more importantly, there are zones which partially or fully break
because child-NS is inconsistent with parent, typically because these is
a dumb or misconfigured load-balancer in front which overwrites NS RRs.
We at ISC learnt the hard way these zones are hard to support because of
the parent/child mess and it's typically better to keep child NS out of
picture as long as practical. Revalidation makes this worse.
The long term alternative is:
B. Making DELEG happen.
That removes two major protocol quirks from the equation completely:
- duplicate-but-not-quite-NS in the child (covered by the point A above)
- the unsigned-parent NS (unique for deleg)
Plus it provides more benefits for the whole ecosystem down the road -
like ability to do proper authenticated transport security, easier to
deploy third-party-managed DNSSEC etc.
NS revalidation of signed delegations is the only mitigation that
protects against /on-path/ or partly /on-path/ attacks.
>
> I love DNS cookies, and they are also a really good remedy for unsigned
> delegations, but they do nothing against on-path attacks.
If integrity and on-path attackers are a concern, DNSSEC is the answer.
I don't see motivation for making the current protocol more complex
beyond that. See above.
If DNSSEC deployment is too much hassle, DELEG intends to make it easier.
If DNSSEC is not possible for some other reason then DELEG in intended
to offer proper authenticated transport security.
IMHO these new options are systemic fixes worth implementation effort.
The draft in question is a complex workaround with constant operational
cost, and that does not cut the cost/benefit for BIND.
Does NS revalidation achieve anything beyond this?
Besides you underestimation of the impact of a hijack of a signed zone
(especially higher up in the DNS tree), you have it covered :).
Also, responding to the reluctance of some to do revalidation in
general, even doing it just at the root, which is the easiest and least
risky, already has the biggest risk reduction.
Well, this is again where we have to agree to disagree. If attacks
against root is a concern then either DNSSEC validation or mirror
zone+ZONEMD is IMHO the way to go. Revalidation is a workaround, not a
proper solution.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
