/*
* Copyright (C) Internet Systems Consortium, Inc. ("ISC")
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, you can obtain one at https://mozilla.org/MPL/2.0/.
*
* See the COPYRIGHT file distributed with this work for additional
* information regarding copyright ownership.
*/
#ifndef DNS_ACACHE_H
#define DNS_ACACHE_H 1
/*****
***** Module Info
*****/
/*
* Acache
*
* The Additional Cache Object
*
* This module manages internal caching entries that correspond to
* the additional section data of a DNS DB node (an RRset header, more
* accurately). An additional cache entry is expected to be (somehow)
* attached to a particular RR in a particular DB node, and contains a set
* of information of an additional data for the DB node.
*
* An additional cache object is intended to be created as a per-view
* object, and manages all cache entries within the view.
*
* The intended usage of the additional caching is to provide a short cut
* to additional glue RRs of an NS RR. For each NS RR, it is often
* necessary to look for glue RRs to make a proper response. Once the
* glue RRs are known, the additional caching allows the client to
* associate the information to the original NS RR so that further
* expensive lookups can be avoided for the NS RR.
*
* Each additional cache entry contains information to identify a
* particular DB node and (optionally) an associated RRset. The
* information consists of its zone, database, the version of the
* database, database node, and RRset.
*
* A "negative" information can also be cached. For example, if a glue
* RR does not exist as an authoritative data in the same zone as that
* of the NS RR, this fact can be cached by specifying a NULL pointer
* for the database, version, and node. (See the description for
* dns_acache_getentry() below for more details.)
*
* Since each member stored in an additional cache entry holds a reference
* to a corresponding object, a stale cache entry may cause unnecessary
* memory consumption. For instance, when a zone is reloaded, additional
* cache entries that have a reference to the zone (and its DB and/or
* DB nodes) can delay the cleanup of the referred objects. In order to
* minimize such a bad effect, this module provides several cleanup
* mechanisms.
*
* The first one is a shutdown procedure called when the associated view
* is shut down. In this case, dns_acache_shutdown() will be called and
* all cache entries will be purged. This mechanism will help the
* situation when the configuration is reloaded or the main server is
* stopped.
*
* Per-DB cleanup mechanism is also provided. Each additional cache entry
* is associated with related DB, which is expected to have been
* registered when the DB was created by dns_acache_setdb(). If a
* particular DB is going to be destroyed, the primary holder of the DB,
* a typical example of which is a zone, will call dns_acache_putdb().
* Then this module will clean-up all cache entries associated with the
* DB. This mechanism is effective when a secondary zone DB is going to
* be stale after a zone transfer.
*
* Finally, this module supports for periodic clean-up of stale entries.
* Each cache entry has a timestamp field, which is updated every time
* the entry is referred. A periodically invoked cleaner checks the
* timestamp of each entry, and purge entries that have not been referred
* for a certain period. The cleaner interval can be specified by
* dns_acache_setcleaninginterval(). If the periodic clean-up is not
* enough, it is also possible to specify the upper limit of entries
* in terms of the memory consumption. If the maximum value is
* specified, the cleaner is invoked when the memory consumption reaches
* the high watermark inferred from the maximum value. In this case,
* the cleaner will use more aggressive algorithm to decide the "victim"
* entries. The maximum value can be specified by
* dns_acache_setcachesize().
*
* When a cache entry is going to be purged within this module, the
* callback function specified at the creation time will be called.
* The callback function is expected to release all internal resources
* related to the entry, which will typically be specific to DB
* implementation, and to call dns_acache_detachentry(). The callback
* mechanism is very important, since the holder of an additional cache
* entry may not be able to initiate the clean-up of the entry, due to
* the reference ordering. For example, as long as an additional cache
* entry has a reference to a DB object, the DB cannot be freed, in which
* a DB node may have a reference to the cache entry.
*
* Credits:
* The basic idea of this kind of short-cut for frequently used
* information is similar to the "pre-compiled answer" approach adopted
* in nsd by NLnet LABS with RIPE NCC. Our work here is an independent
* effort, but the success of nsd encouraged us to pursue this path.
*
* The design and implementation of the periodic memory management and
* the upper limitation of memory consumption was derived from the cache
* DB implementation of BIND9.
*
* MP:
* There are two main locks in this module. One is for each entry, and
* the other is for the additional cache object.
*
* Reliability:
* The callback function for a cache entry is called with holding the
* entry lock. Thus, it implicitly assumes the callback function does not
* call a function that can require the lock. Typically, the only
* function that can be called from the callback function safely is
* dns_acache_detachentry(). The breakage of this implicit assumption
* may cause a deadlock.
*
* Resources:
* In a 32-bit architecture (such as i386), the following additional
* memory is required comparing to the case that disables this module.
* - 76 bytes for each additional cache entry
* - if the entry has a DNS name and associated RRset,
* * 44 bytes + size of the name (1-255 bytes)
* * 52 bytes x number_of_RRs
* - 28 bytes for each DB related to this module
*
* Using the additional cache also requires extra memory consumption in
* the DB implementation. In the current implementation for rbtdb, we
* need:
* - two additional pointers for each DB node (8 bytes for a 32-bit
* architecture
* - for each RR associated to an RR in a DB node, we also need
* a pointer and management objects to support the additional cache
* function. These are allocated on-demand. The total size is
* 32 bytes for a 32-bit architecture.
*
* Security:
* Since this module does not handle any low-level data directly,
* no security issue specific to this module is anticipated.
*
* Standards:
* None.
*/
/***
*** Imports
***/
#include