[bind10-dev] Resolver - address database requirements

[Stephen Morris]

Your comments are requested on the first draft of the requirements for the address database component of the resolver. They are not complete, but at this stage the intention is to make sure that there is enough documentation for work on the component to start.  However, if there is anything obviously missing (or just plain wrong), please let me know.

Stephen



BIND-10 Address Database Requirements

Introduction
============
A zone is served by one or more nameservers, each of which has one or more addresses.  When the resolver needs to communicate with a zone, it must choose one of the nameservers for the zone, then choose an address should the nameserver have more than one.

For this reason, the resolver needs to maintain a list of nameserver addresses associated with domain names.  Although the information may be in the main cache (in the form of A/AAAA records for the nameservers), using the cache directly is inappropriate because:

a) The additional overhead of multiple lookups to locate first the NS records then the A/AAAA records.
b) The need to keep additional information about the address such as round-trip time.

RTT is important because it is one of the factors that influences the selection of nameserver to which a query should be directed.  These factors include:

a) Whether the nameserver is reachable (i.e. did it respond to the last query).
b) Does the nameserver support the address family (IPv4/v6) required?
c) The average round-trip time of the last few queries to the nameserver address.
d) The last time the nameserver was queried. (Nameservers with higher RTTs are periodically used to see if the RTT has dropped.)



Requirements
============
The broad requirements for this component are:

Adding Names
-------------
1) It must be possible to add a domain name to the database:
* Adding a new name will cause the database software to issue lookups for the A/AAAA information of the associated nameservers and store that information.
* As adding a new name will be associated with the need to use the address information, and since the address information may take time to acquire, it should be possible for the caller to specify a callback function that will be called when the address information arrives.

2) The names in a given class should be distinct, e.g. example.com class IN is distinct from example.com class CH.

Looking up Names
----------------
3) It must be possible to look up a name in the database.  The lookup will return the addresses associated with the name subject to:
* If only IPv4 addresses have been requested, only the IPv4 addresses associated with a name will be returned.
* If only IPv6 addresses have been requested, only the IPv4 addresses associated with a name will be returned.
* If both IPv4 and IPv6 addresses have been requested, both IPv4 and IPv6 addresses will be returned.
* If an address is marked as unreachable, it will not be returned unless explicitly requested.

4) The returned address information should contain round-trip time (RTT) information.
* The RTT should be an integral number of microseconds.

Deleting Names
--------------
5) It must be possible to delete a domain name from the database
* This should remove all nameserver address entries associated with it.

6) A domain name should be deleted when it reaches its TTL
* This should remove all nameserver address entries associated with it.

7) If the address information associated with a nameserver reaches its TTL, the information should be fetched again the next time address information is required.

8) It should be possible to invalidate the address information associated with a nameserver (and so force a re-fetch the next time it is required).

9) It should be possible to delete all information in the database.

Modifying Information
---------------------
10) It must be possible to update the round-trip time associated with an address.
* When an address is added, the initial value of the RTT is a random value of 0
* The current BIND-9 formula should be used as a first implementation of the RTT update algorithm.  This is

	new_srtt = (old_srtt / 10 * factor) + (rtt / 10 * (10 - factor));

Where:

new_srtt = New value of the average RTT
old_srtt = Current value of the average RTT
factor = a number between 0 and 10. (This is a tuneable parameter.)

Note that "a / b * c" in the above equation means "(a / b) * c" and not "a / (b * c)"

11) It must be possible to mark an address as unreachable.

12) All unreachable addresses should be marked as reachable after a (settable) fixed period.
* If an address becomes unreachable, the existing RTT information is not changed (so when it next comes back on line the RTT calculation uses the RTT before it went off-line).

Miscellaneous
-------------
13) The database must be thread-safe

14) It should be possible to dump all or part of the database for diagnostic purposes.

15) To limit memory usage, it should be possible to limit the number of names in the database.
* If a new name is added and takes the count over the limit, another name should be dropped.