Changes to NS RRset caching strategy in BIND 9.6-ESV-R6, 9.7.5, 9.8.2 and 9.9.0

Introduction

In the DNS a parent zone is authoritative for the presence of a delegation (NS RRset in the parent zone) but the child zone is authoritative for the contents of the NS RRset. These NS RRsets are supposed to be loosely synchronised with both the parent and child zone operators both responsible for keeping the contents the same, as well as any glue address records for the name servers.

named can learn the contents of an NS RRset three ways:

• by a referral from the parent zone to the child zone
• by a explicit query for the NS records (externally triggered or as part of DNSSEC validation)
• as authoritative data returned along with responses to other queries

The last two, usually, result in named potentially updating a existing cached NS RRset. How this is done is important in terms of distributing subsequent queries to the zone to the current name servers for the zone and in the speed with changes to the NS RRset propagate. named needs to honor both the presence and/or absence of the NS RRset in the parent zone and the contents. As the child is authoritative for the NS records contents, it is not possible to avoid updating the NS RRset and still validate it with DNSSEC.

Previous Behavior

Prior to this change, named would trim the received TTL of NS RRsets that did not change. This prevented resolvers staying locked on to old nameservers that could happen with mismanaged DNS operator changes, where the old operator continued to serve the old zone content. With a properly managed DNS operator change, all nameservers for a zone serve the same zone content modulo zone transfer delays. named didn't, however, trim the TTL of NS RRsets that did change when storing them in the cache.

This honored the contents of the NS RRset but not the presence/absence of the delegation.

New Behavior

named now remembers the TTL of the NS RRset when looking up records in a zone and trims the TTL of any NS RRset, with the same owner name, in the response to that value. This is done to ensure that the removal of a delegation is detected.

This honors both the contents of the NS RRset and the presence/absence of the delegation.