wiki:NameserverAddressStoreRequirements

Nameserver Address Store - 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 zones. 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:

  1. The additional overhead of multiple lookups to locate first the NS records then the A/AAAA records.
  2. The need to keep additional information about the address such as the round-trip time (RTT) of packets sent to the server.

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:

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

The component that performs these tasks is the Nameserver Address Store (NSAS). This document outlines the broad requirements for it.

Requirements

Adding/Looking? Up Names

1) It must be possible to look up a zone in the database:

  • If the zone exists, the address of one of the nameservers for the zone is returned.
  • If the zone does not exist, an entry for it is created using the list of nameservers supplied. (A lookup will be made as the result of receiving a referral; the information in the Authority and Additional sections will be used to seed address store.)
  • Adding a new name will cause the database software to issue lookups for the A/AAAA information of the nameservers and store that information.

2) In returning the address of one of the nameservers:

  • If only IPv4 addresses have been requested, only an IPv4 address associated with a nameserver for the zone will be returned.
  • If only IPv6 addresses have been requested, only an IPv6 address associated with a nameserver for the zone will be returned.
  • If both IPv4 and IPv6 addresses have been requested, any address (IPv4 or IPv6) will be returned.
  • Addresses know to be unreachable will not be returned unless explicitly requested.

3) The names in different classes should be distinct, e.g. example.com class IN is distinct from example.com class CH.

Deleting Names

4) It must be possible to delete a zone name from the database

  • This should remove all nameserver address entries associated with it.

5) A zone name should be deleted when it reaches its TTL

  • This should remove all nameserver address entries associated with it.

6) If the address information associated with a nameserver reaches its TTL, the information should be fetched again the next time address information is required. (It is possible that the A RRset for a nameserver will have a lower TTL than that of the NS RRset.)

7) 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).

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

Address Selection

9) The address returned for a zone should generally be that associated with the lowest RTT.

  • Initial values of the RTT should be low and random; this ensures that all nameservers will be selected and that the order they are selected is unpredictable.
  • Other nameservers should be periodically tried to check their RTT
  • Unreachable nameservers should be re-tried infrequently (see below).

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 a low number of microseconds.
  • 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
  • rtt: Value of RTT measured on last query.
  • factor: a number between 0 and 10. (This is a tuneable parameter.)

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, a new RTT should be calculate for it.

Miscellaneous

13) The address store must be thread-safe

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

15) To limit memory usage, it should be possible to limit the number of zones in the database.

  • If a new zone is added and takes the count over the limit, another zone should be removed.

16) It should be possible to write the contents of the NSAS to disk on shutdown and to load it from disk on startup.
Note: in the case of a big caching resolver such as that used by a large ISP, it will take tens of minutes to get a rich enough cache to start winning on cache hits. So a disk file that loads in single digit minutes would be a big win.

Last modified 7 years ago Last modified on Oct 8, 2010, 9:05:27 AM