DNS SRV Resource Records for AFS
updated by
- rfc-8553 — DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names
updates
- rfc-1183 — New DNS RR Definitions
Extracted elements (21)
DNS SRV RRs are preferred over AFSDB RRs because SRV RRs support priority and weight for server ranking, include protocol and port information (enabling future TCP support and non-standard ports), allow separation of VLDB and PTS servers, and are in widespread use whereas AFSDB RRs are little-known and little-supported.
Implementations are not required to re-run the weighted server selection algorithm for each call; they MAY reuse results until DNS SRV RRs expire. This may affect load distribution, and server operators should account for this effect when setting TTL values.
New AFS cells SHOULD use names that follow the structure of the DNS, as DNS SRV RRs can only locate AFS services for cells whose naming matches the DNS hierarchy. This also helps avoid naming conflicts between separate AFS cells.
AFSDB RRs do not support priority, weighting, or port information, meaning all servers listed in AFSDB RRs are treated as equal and assumed to operate on standard ports. Cells using DNS SRV RRs should provide AFSDB RRs listing only servers that provide both VLDB and PTS on standard UDP ports for backward compatibility.
AFS cells providing DNS SRV RRs SHOULD also provide AFSDB RRs for backward compatibility with clients that do not support DNS SRV RRs. The AFSDB RR SHOULD list servers that provide both VLDB and PTS service on the standard ports (7003 and 7002) via Rx over UDP.
AFS clients MAY remember which targets are inaccessible and ignore those targets when determining which server to contact first. Clients that do this SHOULD have a mechanism to retry previously inaccessible targets and reconsider them according to their current priority and weight if they become accessible again.
AFS servers SHOULD NOT be advertised with AFSDB RRs unless they provide VLDB and PTS services via UDP on the standard ports. An AFS cell SHOULD have at least one VLDB and one PTS server on the standard ports (7003 and 7002 respectively) since clients without DNS SRV RR support cannot locate servers on non-standard ports.
Clients MUST attempt to contact the target host with the lowest-numbered priority they can reach. AFS clients using a ranked algorithm MUST assign sufficiently distinct ranks to targets with different priorities such that higher-numbered priority targets are only contacted if all lower-numbered priority targets are inaccessible.
Clients SHOULD query DNS SRV RRs by default but SHOULD fall back to AFSDB RRs if no DNS SRV RRs are found. In the absence of DNS SRV RRs, an AFSDB RR of subtype 1 SHOULD be treated as equivalent to a pair of DNS SRV RRs: one for _afs3-vlserver._udp on port 7003 and one for _afs3-prserver._udp on port 7002, both with priority 0 and weight 0.
DNS SRV RRs SHOULD be discarded after their TTL and the DNS query repeated. Any information derived from DNS SRV RRs, such as preference ranks, MUST be discarded when the DNS SRV RR expires.
If there are multiple targets with equal priority, the weight value of the DNS SRV RR SHOULD be used as input to a weighted algorithm for selecting servers. Larger weights SHOULD be given a proportionately higher probability of being selected, and a weight of 0 SHOULD be used if all targets with that priority are weighted equally.
Implementations MUST be able to assign distinct base ranks for at least ten distinct priority values. If more distinct priority values are encountered than can be represented as base ranks, implementations SHOULD fall back to generating ranks based solely on priorities, ignoring other rank inputs and disabling dynamic rank adjustment.
Network performance and other protocol metrics MAY be used alongside SRV RR weights when selecting servers, but such information MUST NOT override the priority information in the SRV RR.
The <name> field MUST be the AFS cell name for which the server provides services. Clients MUST query DNS SRV RRs only for a <name> value exactly matching the AFS cell of interest and MUST NOT remove leading components to search for more general DNS SRV RRs.
The <proto> field in the SRV label MUST be 'udp' for the current AFS protocol, which uses Rx over UDP. Other values may be used for future revisions supporting other protocols such as Rx over TCP.
The TTL of DNS SRV RRs MUST be honored by invalidating and regenerating server preference ranks with new DNS information once the TTL has expired. However, accumulated network and protocol metrics MAY be retained and reapplied to new rankings.
AFS clients using a ranking algorithm SHOULD assign ranks by sorting targets by priority, assigning base rank values sufficiently distinct to enforce priority ordering, then ordering equal-priority targets using the RFC 2782 weighted algorithm and assigning incrementing rank values. Dynamic rank adjustment based on network metrics is permitted but must not alter the priority ordering.
AFS services are located using DNS SRV RRs with service labels 'afs3-vlserver' (VLDB services) and 'afs3-prserver' (PTS services). The SRV label format is _<service>._<proto>.<cell-name>. Other AFS services (file and volume management) are located through the VLDB service and do not use DNS SRV RRs.
Adding DNS SRV RRs does not make the existing AFS vulnerability more severe compared to AFSDB RRs — it only opens another equivalent point of attack. The underlying vulnerability is inherent in the AFS protocol and can be exploited through VLDB query forgery independent of DNS.
Server authentication can prevent impersonation attacks, but only for authenticated AFS access. Much AFS access is unauthenticated, and clients may fall back to unauthenticated access after authentication failure, which an attacker's server may permit. Using DNSSEC can prevent DNS forgery but the underlying vulnerability requires AFS protocol changes to always authenticate services.
Without integrity and authenticity checks on DNS responses, an attacker may forge DNS replies to direct clients to a VLDB or PTS server under attacker control, potentially deceiving clients about volumes, file servers, and file contents, and enabling further compromise if the client executes programs or uses data from the AFS cell in a trusted manner.