mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-22 01:59:26 +00:00
Code Issues Releases Wiki Activity
Page: Updating resolver algorithm, or "who knows best, the parent or the child?"
Pages
"main" branch partial history rewrite in August 2022 A few thoughts on Rust in BIND BIND 9 Achievements BIND 9 F2F Meeting in Warsaw, October 2019 BIND 9 Memory Explained BIND 9 PKCS11 BIND 9 Packaging BIND 9 Style Guide BIND 9.11 ESV Soft Code Freeze BIND 9.15 Plan BIND 9.17 Plan BIND 9.19 Plan BIND 9.19 Planning: CHANGES BIND 9.19 Planning: Configuration Backend BIND 9.19 Planning: DB notes BIND 9.19 Planning: Discuss new features BIND 9.19 Planning: Incident Manager Rotation BIND 9.19 Planning: Netmgr evaluation BIND 9.19 Planning: Refactor RBTDB BIND 9.19 Planning: Refactoring XFR BIND 9.19 Planning: Refactoring zone.c BIND 9.19 Planning: Refactoring BIND 9.19 Planning: Statistics System Overhaul BIND 9.19 Planning: Testing BIND 9.19 Planning: Things to do before BIND 9.18 cutoff BIND 9.21 Plan BIND Development and Release Process 2019 BIND development workflow CGroups v2 limiting resource consumption for testing CPU profiling using perf Config system requirements DNS Shotgun integration into Gitlab CI DNSSEC Key and Signing Policy (KASP) Data structure survey Debian Packages Escalation Engineer Duties Git Of Theseus Gitlab how to Integration tests wish list Internal objects and their relations Known Issues in BIND 9.18 Known Issues in BIND 9.20 Known Issues in BIND 9.21 LLM based tools thoughts Planning Policy for removing named.conf options Preparing Useful Merge Requests QP‑trie in NSD Requirements and Designs Server side Git hooks Serving stale data Stable Release Update Statistics Requirements SystemTap on 4326 remove locking from copy_namehook_lists SystemTap on main Team Meetings Testing by configuration options Updating resolver algorithm, or "who knows best, the parent or the child?" User space Probing in BIND 9 _sidebar benchmarks best practices caches dashboard home october2018meeting pytest howto stdatomic usage in master
Clone
0
Updating resolver algorithm, or "who knows best, the parent or the child?"
Matthijs Mekking edited this page 2022-12-15 11:33:55 +00:00
Table of Contents

Issues with current resolver algorithm

Resolvers traditionally store all RRSets during the iterations in their cache. When resolvers receive new data, they will update their cache. NS records at a zone cut should be the same in the parent and child zone, but if they are different, the NS records from the child zone are authoritative so they update any NS records from the parent side that were previously cached. If they are not the same, this can cause name resolution to become unstable. Unsynchronized delegations also introduce security vulnerabilities (for example the "ghost domain" issue).

QNAME Minimization

Another issue we have seen is that there is no referral information for a child zone using QNAME minimization (with the '_' label prepended) when the parent and child zones are hosted on the same server, so we end up repeatedly querying. Changing the QNAME minimization behavior to use NS queries and no prepended label could improve our QNAME minimization algorithm, but our resp-diff test shows that there are even more differences in responses compared to Knot and Unbound. The cause for this may be that Knot uses the parent NS when performing name resolution.

Parent knows best

To overcome these issues, draft-fujiwara-dnsop-resolver-update-00 suggests to update the resolver algorithm to not use NS RRsets at the zone apex while iterating. In other words, when doing name resolution and following delegations, always use the NS RRsets at the parent.

This has the advantage that name resolution becomes more stable (you need the parent NS side anyway to get to the child zone), it mitigates the "ghost domain" vulnerability, and there is no need to rank the DNS data (RFC 2181 Section 5.4.1) because the data will no longer be overwritten.

However, the disadvantage of this is that the resolver ignores the authoritative NS RRsets at the child zone, and also makes it impossible for the child zone to control the TTL of the NS RRset.

Child knows best

draft-ietf-dnsop-ns-revalidation suggests to use the NS RRsets from the parent only for a short time, during initial resolution. After (or during) name resolution, a validation query should be sent to the delegated servers for the newly discovered zone cut.

Successive queries directed to the same zone will be directed to the servers listed in the child's apex, due to the ranking of this answer. If the validation query fails, the parent NS RRset will remain the one with the highest ranking and will be used for successive queries.

To mitigate against the "ghost domain" vulnerability, the draft proposes to perform delegation re-validation. After the TTL of the parent NS RRset, the delegation should be re-validated. If there parent no longer has any match with the NS RRset from the child's apex, then no currently cached data whose owner names are at or below that re-validation point can be used.

Delegation cache

Both proposals require a cache to remember the delegated name server names for each zone cut as received from the parent (delegating) zone's name servers. So it seems evident that either way, we need to implement a delegation cache.

This requires updates to the resolver algorithm (RFC 1034 Section 5.3.3.):

  1. See if the answer is in local information, and if so return it to the client. Use the authoritative cache

  2. Find the best servers to ask. Use either the authoritative or the delegation cache

  3. Send them queries until one returns a response.

  4. Analyze the response, either:

    a. if the response answers the question or contains a name error, cache the data in the authoritative cache as well as returning it back to the client.

    b. if the response contains a better delegation to other servers, cache the delegation information in the delegation cache, and go to step 2.

    c. if the response shows a CNAME and that is not the answer itself, cache the CNAME in the authoritative cache, change the SNAME to the canonical name in the CNAME RR and go to step 1.

    d. if the response shows a servers failure or other bizarre contents, delete the server from the SLIST and go back to step 3.

Find the best servers to ask

The two proposals differ from opinion what the best servers to ask are (step 2 in the above algorithm). draft-fujiwara-dnsop-resolver-update-00 says to never use the authoritative cache for this, also because it will never use the NS RRsets at the child's apex when iterating.

draft-ietf-dnsop-ns-revalidation says to use the authoritative cache (which stores the authoritative NS RRsets from the child zone) and only if they are not in cache, use the delegation cache. At this point a new NS validation query should be send as well.

The advantage of parent-centric is that we don't have to worry about delegation re-validation: it happens automatically if the RRsets expire from cache and a new query triggers name resolution.

Question: Would finding the best servers to ask from both the authoritative and delegation cache be a good compromise?

Sources: