Browse Prior Art Database

Notifying Caching Resolver of Zone Changes Disclosure Number: IPCOM000031805D
Original Publication Date: 2004-Oct-11
Included in the Prior Art Database: 2004-Oct-11
Document File: 1 page(s) / 30K

Publishing Venue



There are a few implementations of a caching resolver daemon which caches, among other things, DNS responses. The caching daemon can sit on an individual system, to be used locally, or it can be used by multiple systems. Host records (A - address records, PTR-pointer records) on local DNS servers often changes readily. The DNS protocols specifies that a record can be cached for as long as the TTL(time to live). Unfortunately, when the DNS updates its host records, the caching daemon is unaware that its cached records might become invalid.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 100% of the total text.

Page 1 of 1

Notifying Caching Resolver of Zone Changes

When a caching daemon starts, it joins a well known multicast group. This group will contain other caching daemon as well as local domain name system (DNS) servers that are authoritative for the zone that the caching daemon resides. The caching daemon will cache all responses as usual until it gets a notify from this multicast group. This notification tells the caching daemon that its record might become invalid. Here there are three possible path the caching daemon can implement:
(1) since the notify also specifies which zone the DNS is authoritative for, the caching daemon will invalidate all records associated with this zone.
(2) the caching daemon should check the DNS server to see what might have changed.
(3) the daemon should be prepared to receive a multicast update packet contain the recent changes.

If the third path is taken, the daemon processing the packet can determine if the record exist in its cache and whether it needs to apply the changes. The advantage of a multicast group for the DNS is that it does not need to maintain a list of caching daemon. It also minimizes the amount of communication, only one notify is sent out and a minimum of one update packet. This is a plus since multiple updates or request for updates can be expensive in terms of network usage and increasing the load on an already overloaded DNS server. This concept can also be applied for a network information services (NIS) environment.