Address database dump (ADB) - understanding the fields and what they represent
  • 20 Jan 2019
  • 7 Minutes to read
  • Contributors
  • Dark
  • PDF

Address database dump (ADB) - understanding the fields and what they represent

  • Dark
  • PDF

Article Summary

BIND provides the administrator with a feature that allows the current cache contents to be dumped to a text file for inspection. Using the -all suboption will cause named to dump everything in cache, including authoritative zone data that has loaded, and the Address database:

$ rndc dumpdb -all

(Please see the Administrator Reference Manual (ARM) for more suboptions to the rndc dumpdb control command)

The Address database is where named tracks details that it has learned about the behavior and responsiveness of other servers that it contacts so that it can optimize its future resolver actions in order to provide clients as quickly as possible with the answers they need, and reduce expending resources on repeated resolver queries that have failed previously.

Entries are retained in the Address database for 10 minutes and are indexed by server name (if this is information that is still valid in main cache) and by server address. Servers who can no longer be identified by name are listed in the dump output in the section Unassociated entries. This is so that named doesn't forget what it has learned about servers for 10 minutes, even if TTLs in main cache are shorter than this. Future queries may result in unassociated entries being re-associated with one or more names.

Here's an example of an entry indexed by server name:

; [v6 TTL 11] [v4 unexpected] [v6 nxrrset]
; [v4 TTL 0] [v4 success] [v6 unexpected]
; [srtt 181080] [flags 00004000] [edns 9/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1330]
A server may be associated with more than one name
The server information being retained in the ADB is the same, irrespective of whether the server name is known or not. Since the server is identified by its address(es), if multiple names refer to the same server address, then all the valid names by which this server is known will be listed in the ADB dump alongside its entry.

And here is an example of an unassociated entry:

; Unassociated entries
; [srtt 19154] [flags 00004000] [edns 1/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1350]

Looking at the fields one by one:

  1. Server name and TTL from main cache:
    ; [v6 TTL 11] [v4 unexpected] [v6 nxrrset]
    ; [v4 TTL 0] [v4 success] [v6 unexpected]
    ; [srtt 181080] [flags 00004000] [edns 9/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1330]
    This is the name as taken from the main cache. The TTL is the TTL of the name/PTR from main cache - so in 11 seconds (unless refreshed before then), this server is going to move to the Unassociated entries list.

  2. What we know about the server and its addresses (if anything):
    ; [v6 TTL 11] [v4 unexpected] [v6 nxrrset]
    ; [v4 TTL 0] [v4 success] [v6 unexpected]
    ; [srtt 181080] [flags 00004000] [edns 9/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1330]
    The v6 entry records that we have a cached NXRRSET - there is no IPv6 address for this server (and also that we wouldn't expect to have an IPv4 address result from looking up the IPv6 address - which makes sense). In main cache we can see the corresponding NXRRSET:

l.gtld-servers.NET.     11      \-AAAA  ;-$NXRRSET

The IPv4 name entry has been caught and dumped just before it is expired (the main cache section did not display the A record for but it did exist previously ('v4 success').
The list of potential values we might see here is

  • success - there is a valid cache entry
  • unexpected - explained above
  • nxrrset - the name exists, but not the A/AAAA RR (for v4/v6 respectively)
  1. The server's SRTT (stored with its address):
    ; [srtt 181080] [flags 00004000] [edns 9/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1330]
    This is the smoothed round trip time. It is adjusted each time a response to a query is received from this server (or if a query to this server times out). It is also adjusted each time a response to a query is received from another server from an NS RRset that includes this server. (Details of the SRTT algorithm and how it operates are out-of-scope for this KB article but it is generally well-known that named will 'try' servers in order, starting with those with the smallest recorded SRTT.)

  2. The flags field:
    ; [srtt 181080] [flags 00004000] [edns 9/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1330]
    This field is a bitmask. More of the bit values are in use internally than are stored in the Address database for a server and the definitions of the bit values have evolved over various releases of BIND. In addition, not all releases of BIND report/use the same flags in ADB.

  3. The edns and plain counters:
    ; [srtt 181080] [flags 00004000] [edns 9/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1330]
    These are new in BIND 9.10.0, due to the change in EDNS probing - for more information see Testing authoritative server support for EDNS and large UDP buffer sizes in BIND 9.10. The counters are incremented as you would expect them to be as the responses are successfully received or timeouts are logged. But they are also capped/adjusted in order to periodically retry with EDNS (if the server has not yet responded to queries with EDNS) and with larger EDNS packet sizes. The counters should be interpreted as adjusted counts of:
    -- Successful queries with EDNS (i.e. replies received - the count in this example is 9)
    -- Timeouts advertising EDNS with 4096 or smaller
    -- Timeouts advertising EDNS with 1432 or smaller
    -- Timeouts advertising EDNS with 1232 or smaller
    -- Timeouts advertising EDNS with 512
    -- Successful queries without EDNS
    -- Timeouts on queries without EDNS

  4. udpsize (BIND 9.10 and newer only):
    ; [srtt 181080] [flags 00004000] [edns 9/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1330]
    This is where named records the size of the largest reply it has received from this server (minimum 512).
    Note that if named has not yet received any responses from this server, then this field is not set and is not included in the cache dump.

  5. ADB entry ttl:
    ; [srtt 181080] [flags 00004000] [edns 9/0/0/0/0] [plain 0/0] [udpsize 512] [ttl 1330]
    All current versions of BIND record (and dump) the ttl of the ADB entry for the server.

In addition to the information above, lame server information is sometimes also seen.  It is recorded per-server and displayed below the server entry in the ADB dump.  For example:

;      PTR [lame TTL 595]
;      PTR [lame TTL 60]

Server 'lameness' is recorded on a per-zone basis
A server is lame, not of itself alone, but lame for some zone(s) that have been delegated to it. The length of time for which lameness is cached is controlled by the named.conf option lame-ttl.

More modern versions of BIND in which the fetches-per-server is Recursive Client Rate Limiting option is available will have two further fields formatted out for each server:

; [v4 TTL 2658] [v4 not_found] [v6 unexpected]
; [srtt 948570] [flags 00004000] [ttl -342230] [atr 0.97] [quota 1]

The two additional fields [atr 0.97] and [quota 1]show the adaptive fetches-per-server quota that is being applied to this server as well as the Adjusted Timeout Rate. In the example above, this server is being very heavily rate-limited; the initial quota of outstanding fetches is at the minimum value and only one outstanding query to is permitted at any one time. The ratio of timeouts to completed fetches (atr) is also high at .97 (97%), so this unsurprising.

Why does my cache dump contain ADB records with a negative ttl?
When they are not capped by max-cache-size or constrained by access to memory resources, both main cache and Address database clean up expired entries 'opportunistically' - this means that they are removed as named is 'passing this way anyway' in cache. So at any point in time there will likely be a number of RRsets in cache awaiting clean-up. They are not used after their TTL has expired (except in certain corner-cases where they expire before they can be used, or are received with TTL=0 from an authoritative server during the lifetime of an ongoing client query - in which case yes, they will be used so as not to return SERVFAIL to the requesting clients). The main cache dump specifically excludes any RRsets that it finds that have already expired, even though they may still be present in the cache (and are included in the counters of cache entries - this is because named doesn't know that the entries have expired until it happens to compare the expire datestamp on the record with 'date/time now'). The ADB dump, however, takes a different approach. If stale/expired records are still present, it will dump them, but displaying their negative ttl. Such records will not be used and will be refreshed if the server is used again.