AFSDB RecordHow does AFSDB record work?
AFSDB record is a type of DNS record used to locate database servers for distributed file system cells. Defined in RFC 1183, the AFSDB record supports two distinct distributed file system services: AFS (Andrew File System) and DCE/NCA (Distributed Computing Environment / Network Computing Architecture). The record maps a cell's domain name to the hostname of a server that holds that cell's database, allowing AFS clients and DCE naming services to discover the appropriate server for a given cell. The format of the AFSDB record is similar to that of MX records, using a subtype field in place of a priority field.
AFSDB record format
A typical AFSDB record looks like one of the following in standard BIND format:
$ORIGIN example.com.
@ 86400 IN AFSDB 1 afsdb1.example.com.
@ 86400 IN AFSDB 1 afsdb2.example.com.
@ 86400 IN AFSDB 2 dce.example.com.
An anatomy of the AFSDB record
@ 86400 IN AFSDB 1 afsdb1.example.com.
looks like the below:
| Host Label | TTL | Record Class | Record Type | Subtype | Server Name |
|---|---|---|---|---|---|
| example.com. | 86400 | IN | AFSDB | 1 | afsdb1.example.com. |
It defines the hostname of a record and whether the hostname will be appended to the label. Fully qualified hostnames terminated by a period will not append the origin. The host label in an AFSDB record represents the name of the AFS or DCE cell being described.
TTL
The time-to-live in seconds. This is the amount of time the record is allowed to be cached by an outside DNS server.
Record Class
Mainly 3 classes of DNS records exist:
- IN (Internet) – default and generally what the internet uses.
- CH (Chaosnet) – used for querying DNS server versions.
- HS (Hesiod) – uses DNS functionality to provide access to databases of information that change infrequently.
Record Type
The record format is defined using this field. Common record types are A, AAAA, CNAME, CAA, TXT etc. In the case of an AFSDB record, the record type is AFSDB (type code 18).
Subtype
The Subtype field is a 16-bit integer that identifies which distributed file system service the hostname provides. The two defined subtypes are:
- 1 (AFS Volume Location Server) – The named host runs an AFS 3.x cell database server (Volume Location Database server). AFS clients use this record to locate the VLDB server for a cell, which tracks the location of files across all AFS file servers within that cell. Multiple subtype 1 records may exist for a single cell, each pointing to a different server.
- 2 (DCE Authenticated Name Server) – The named host holds the cell-root directory node for a DCE/NCA cell, functioning as an authenticated name server. The DCE naming service uses this record to map a cell's domain name to its authenticated name server.
Server Name
The Server Name field is the fully qualified domain name of the host that provides the service indicated by the subtype. AFSDB records trigger type A additional section processing for this hostname, meaning DNS servers will attempt to include the A record for the hostname in the additional section of the response, reducing the number of separate DNS lookups required for a client to connect.
AFSDB record restrictions
Both fields are required
Both the Subtype and Server Name fields are required in every AFSDB record. Neither field may be omitted.
No priority or ranking
Unlike MX or SRV records, AFSDB records do not include a priority or weight field. When multiple AFSDB records exist for the same cell and subtype, clients have no DNS-level mechanism to prefer one server over another. For this reason, RFC 5864 updated RFC 1183 to recommend that new deployments use SRV records instead of AFSDB records to locate AFS cell database servers, as SRV records support priority and weight values. Clients SHOULD query for SRV records first and fall back to AFSDB records only if no SRV records are found.
Subtype scope
A single AFSDB record may only carry one subtype value. To advertise both an AFS cell database server (subtype 1) and a DCE authenticated name server (subtype 2) for the same cell, separate AFSDB records must be created for each.
$ORIGIN example.com.
@ 86400 IN AFSDB 1 afsdb1.example.com.
@ 86400 IN AFSDB 1 afsdb2.example.com.
@ 86400 IN AFSDB 2 dce.example.com.
How to add an AFSDB record?
For instructions on how to add an AFSDB record with us, you may refer to the tutorial here.
AFSDB record glossary
AFS (Andrew File System)
A distributed file system originally developed at Carnegie Mellon University and later maintained by Transarc Corporation. AFS organises files into administrative units called cells, each of which has one or more cell database servers (Volume Location Database servers) responsible for tracking the location of files across the cell's file servers. The AFSDB record with subtype 1 is used to locate these servers via DNS.
DCE/NCA (Distributed Computing Environment / Network Computing Architecture)
A set of technologies developed by the Open Software Foundation (OSF) for building distributed applications. DCE includes its own naming service that, like AFS, uses DNS to map cell names to authenticated name servers. The AFSDB record with subtype 2 is used to locate DCE authenticated name servers.
Cell
In AFS and DCE terminology, a cell is an administrative domain — a collection of servers and clients that share a common namespace and are managed together. Each cell has a domain name in the DNS, and AFSDB records are associated with that domain name to help clients locate the cell's servers.
VLDB (Volume Location Database)
The Volume Location Database is a component of AFS that tracks which file server hosts each volume (group of files) within a cell. AFS clients must first contact a VLDB server to find out which file server holds the data they need. The AFSDB subtype 1 record points to the host running this service.
BIND
Berkeley Internet Name Daemon – the most commonly used DNS software on the Internet. Dynu observes BIND format for DNS zone records.
Wildcard
A wildcard DNS record is a record in a DNS zone that will match requests for non-existent domain names.