wiki:RecursorCacheRequirements

Recursor Cache - Requirements

  1. Introduction
  2. Requirements
    1. RRset cache
      1. Looking up rrset
      2. Adding rrset
      3. Deleting rrset
      4. Updating one rrset
      5. dumping/loading to/from one document/database
      6. Updating NSAS
    2. Message Cache
      1. Looking up message
      2. Adding message
      3. Deleting message
      4. Updating message
      5. dumping/loading to/from document/database
  3. Miscellaneous
  4. Questions
    1. Key for the items in message/rrset cache

Introduction

When seeing dns query statistics of recursor, only a small part of domain names are queried frequently, so if the information of these domain names are cached properly, it will accelerate the performance of recursor.

The base unit of recursor cache should be dns message. When the recursor get the query results, the results are stored in the cache for a period of time determined in the configuration of the domain name record in message. Next time, when the recursor get one query, instead of sending query out to some authritative server, the query result(if it exists and doesn't expire) in the cache can be answered to the end-user directly.

Since dns messages in cache may share common rrsets, to decrease the memory usage of dns message cache, it's better to add one rrset cache. messages in cache just includes the rrset index information, different messages in message cache will share the same rrset cache. See the below sketch.

   |----------|----------|-------|
   | dns-msg1 | dns-msg2 |  ...  |  Message Cache
   |----------|----------|-------|
      \        /   |    \
       \      /    |     \
        \    /     |      \
      |--------|--------|-------|
      | rrset1 | rrset2 |  ...  |  RRset Cache
      |--------|--------|-------|

The cached data should can be dumped out, loaded from one file, and edited in runtime. Recursor cache is the key component of recursor. This document outlines the broad requirement of recursor cache.

Requirements

RRset cache

Since some local zones need to be coped according the draft draft-ietf-dnsop-default-local-zones, two rrset caches will be needed by recursor, L1 and L2. L1 containing local zones and any authoritative zones we want to server, and L2 containing the transient data.

The key for one rrset in cache should be "Domain_name + Type + Class". In the value part, besides of the rdata of each rr in the rrset, there should be the signature of rrset(rrsig record), if it has, the authoritative level(for the ranking, see section 5.4.1 in RFC2181), and the security status(dnssec validation result) of rrset.

The expiration time for rrsets in cache should be "now + TTL", once one rrset expires, it should never be used again.

Once the recursor get a new query result, the rrsets in the query result should be used to update the rrset cache, if the rrsets are more authoritative than ones in rrset cache.

Looking up rrset

It must be possible to look up a rrset in the rrset cache:

  • If the rrset exists, return the information of rrset.
  • If the rrset doesn't exist, return NULL.

Adding rrset

  • If the rrset doesn't exist, the rrset should be inserted into the cache.
  • If the rrset exist, update rrset according the new value.

Deleting rrset

The interface for removing one rrset from the cache should be provided, since it may be used by some third-part tools which can edit the rrset cache directly. The simple way to deleting the rrset is to mark the rrset as expired and to re-fetch them.

Updating one rrset

The interface for updating one rrset should be provided. Note: some rrsets in the cache may be updated before they expire.

dumping/loading to/from one document/database

The content of rrset cache should can be dumped to one document/database, so that the rrset cache can be reused when the recursor is restarted. Extra rrset expire time should be added when dumping, so that expired rrsets can be ignored when loading rrset cache from the document/database.

Updating NSAS

NSAS(Nameserver Address Store) should be updated when:

  • the zone's NS rrset is updated and the update involves:
    • the addition or deletion of nameservers(could occur if the NS rrset in the parent did not match that in the zone).
    • modification of nameserver address(would occur if the glue in the parent did not match that in the zone.).
  • Something is explicitly deleted from the cache.

The simple way to update NSAS is to mark the nameservers and associated address records as expired and to re-fetch them.

Message Cache

The key for one message in the cache should be "Query_name + Query_type + Query_Class", and expiration time for the message should be "now + TTL(The lowerest TTL of rrsets in the message)".

the value for one message should include message header, index information for each rrset in different message sections. For the structure, see the following sketch. The security status(dnssec validation result) of the message should also be noted. The status of the message(authoritative or non-authoritative) should also be cached.

Once one message in cache expires, it should be refetched when it is used. The cache user should send out the query to some authorative server, update the message cache when get the query result. rrset cache should be updated together with message cache. Note: when updating the rrset cache, whether to accept an rrset in a query result, or retain an rrset already in the rrset cache, the relative likely trustworthiness of the data should be considered(For how to rank data, please check the section 5.4.1 in RFC2181.).

   |------------------------|
   |  	                    |  Messsage Header
   |------------------------|
   |  dname1 + type + class |
   |  dname2 + type + class |  Message Answer 
   |  ....                  |
   |------------------------| 
   |  dname1 + type + class |
   |  dname2 + type + class |  Message Authority 
   |  ....                  |
   |------------------------| 
   |  dname1 + type + class |
   |  dname2 + type + class |  Message Additional
   |  ....                  |
   |------------------------| 

Looking up message

It must be possible to look up a message in the message cache.

  • If the message doesn't exist, return NULL.
  • If the message exists and doesn't expire, then lookup message's rrsets in rrset cache. If one rrset expires or doesn't exist in rrset cache, return NULL, or else, generate one real reply dns message and return it.
  • If the message exists and expires, return NULL.

Adding message

The interface for adding messages to the cache should be provided. When one message is added, the rrsets in it should be used to update the rrset cache, or inserted if it doesn't exist in the cache.

Deleting message

The interface for removing message from the cache should be provided. The simple way to deleting one message is to mark the message as expired and to re-fetch it.

Updating message

Authoritative message should never be updated by non-authoritative message.

dumping/loading to/from document/database

The content of message cache should can be dumped to one document/database, so that the message cache can be reused when the recursor is restarted. Extra message expire time should be added when dumping, so that expired messages can be ignored when loading message cache from the document/database. Note: rrset cache should be loaded first.

Miscellaneous

  • The rrset/message cache must be thread-safe.
  • LRU(Leatest Recently Used) entry in rrset/message cache should be removed when cache size get close to the configured value.

  • The rrset/message cache size should be configurable, and changeable in runtime-made either bigger or smaller. Note: the behavior when a cache is made smaller should use LRU.
  • It will be useful in debugging if a way to completely emtpy the cache is provided.

  • Recursor should provide the service before finishing loading the cache from one document/database, if the loading takes too long time. (Hint for the implementation: If a short time, we can construct the cache before we begin operations; if a long time, a separate component that works through the dump in the background and does an "add if not here and if the stored data has not yet expired and is more authoritative" should work.)

Questions

Key for the items in message/rrset cache

Shane's opinion is that only the class IN should be supported on the recursor cache, so the key for items in message/rrset cache will be "Query_name + Query_type". What shane said in his email is: Personally I really think we should just support class IN on the recursive side. CH is useful for getting ID.SERVER and the like, but nothing useful in the caching side, and the only other class is HS which MIT can send us a patch for. We can't get those 16 bits back from the protocol, but we can get them back in our implementation''

I will appreciate the comments on it from the reader.

Last modified 7 years ago Last modified on Dec 20, 2010, 2:06:15 AM