shuque / ns-revalidation Goto Github PK

Redhat Enterprise Linux has been running this for years without problems
As reported by @paulwouters at the dnsop session at the IETF 119

Knot resolver does it for the root
Unbound does it when enabled for harden referral path

As mentioned in the DNS directorate early review https://datatracker.ietf.org/doc/review-ietf-dnsop-ns-revalidation-04-dnsdir-early-gieben-2023-07-30/

Putting a marker here as a reminder to address these

...because he did a lot of work earlier.

local root with ZONEMD gives triple-AAA status to the addresses of the root servers in the root zone, and also to all glue records and all referral NS records.

As mentioned in the DNS directorate (early) review: https://datatracker.ietf.org/doc/review-ietf-dnsop-ns-revalidation-04-dnsdir-early-gieben-2023-07-30/

This is more of a nitpick at this point, so let me just file it as an issue.

[QNAME minimization] would provide a way to definitively learn the child zone's authoritative NS RRset.

I disagree with that. The RFC 7816 proposes to ask NS one label below apex, not on the apex itself:

the QNAME that is the original QNAME, stripped to just one label more than the zone for which the server is authoritative

root-servers.net will receive at least 26 times the number of priming queries, plus the extra queries needed to get to root-servers.net. Would be nice to create a formula to get to the number.

Revalidation higher up the tree is more effective that lower in the tree. Knot resolver is doing it only for the root, but there it counts the most.

Ralf Weber pointed out that parent centric resolvers (such as the akamai resolver), are not susceptible to many of the cache hijacking attacks because cache entries are not following the rules of RFC, and are not sensitive to GHOST domain attacks.
However they will also never DNSSEC validate infrastructure RRsets which make them susceptible to query redirection attacks.

See this thread https://mailarchive.ietf.org/arch/msg/dnsop/KIH3WEH3ZakatCAfQxdsFZn0AA0/ , quoted my response here for ease of reference:

Op 18-03-2024 om 17:01 schreef Florian Obser:

On 2024-03-17 20:12 -07,[email protected] wrote:

Internet-Draft draft-ietf-dnsop-ns-revalidation-06.txt is now available. It is
| 7. Security Considerations
| [...]
| In case of non DNSSEC validating
| resolvers, an attacker controlling a rogue name server for the root
| has potentially complete control over the entire domain name space
| and can alter all unsigned parts undetected.

can alter all parts undetected.

It's a non-DNSSEC validating resolver, it doesn't care about signed or
unsigned. Maybe just drop that sentence, it doesn't add much.

Ah sorry, no the "In case of non DNSSEC validating resolvers" is wrong,
this should be "In case of a DNSSEC validating resolver that does not do
revalidation, ..."

From DNS directorate (early) review, see: https://datatracker.ietf.org/doc/review-ietf-dnsop-ns-revalidation-04-dnsdir-early-gieben-2023-07-30/