RFC 5864

DNS SRV Resource Records for AFS

📅 published April 2010, from ietf

DNS SRV Resource Records for AFS 🎀

Okay bestie, this is RFC 5864 💖 It's an official IETF Standards Track document, so it's the real deal. R. Allbery from Stanford University wrote it, it was published in April 2010, and it's ISSN 2070-1721. It updates RFC 1183, and the title block doesn't list anything it obsoletes.

Abstract ✨

So the vibe is this: the doc explains how to use DNS SRV RRs (Resource Records) to find services for the AFS distributed file system 📂, and how the priority and weight values in an SRV RR should be read in AFS's server ranking system. It also updates RFC 1183 to deprecate the AFSDB RR for finding AFS cell database servers, and it gives guidance for backward compatibility. Major glow-up energy 🦋

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc5864.

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 📑

1. Overview and Rationale ..........................................2
2. Scope ...........................................................3
3. Requirements Notation ...........................................3
4. DNS SRV RRs for AFS .............................................4
   4.1. Interpretation as AFS Preference Ranks .....................5
5. Use of AFSDB RRs ................................................6
6. Example .........................................................8
7. Security Considerations .........................................9
8. References ......................................................9
   8.1. Normative References .......................................9
   8.2. Informative References ....................................10

1. Overview and Rationale 🌸

AFS (a registered trademark of IBM Corporation) is a distributed file system (see [AFS1] and [AFS2]). Its most widely used implementations are [OPENAFS] and [ARLA].

AFS is organized administratively into cells. Each AFS cell has one or more Volume Location Database (VLDB) servers, one or more Protection Service (PTS) servers, and one or more file servers and volume servers, plus possible extra services that aren't relevant to this document. Data stored in AFS is split up into collections of files called volumes. When an AFS protocol client wants to access a file in a specific AFS cell, it first contacts a VLDB server for that cell to find the file server for the AFS volume where the file lives, and then it contacts that file server directly to get the file. A client may also need to contact a PTS server for that cell to register before accessing files there, or to query protection database information. The main character energy of a client is real 💅

So an AFS client needs to figure out, for a given AFS cell, which VLDB and possibly which PTS servers belong to that cell. (Traditionally, the VLDB and PTS servers are run on the same host 🖥️) Once the client is talking to the VLDB server, it finds file and volume servers through AFS protocol queries to that VLDB server. Originally, VLDB server info was configured separately on each client in a file called the CellServDB file. [RFC1183] specified the DNS RR (Resource Record) AFSDB to find VLDB servers for AFS.

After [RFC1183], [RFC2782] defined a general DNS RR for service location for any service. This DNS SRV RR has a few advantages over the AFSDB RR:

  • AFSDB RRs don't support priority or ranking, so AFS cell administrators have no way to say which VLDB servers clients should prefer. 🙅‍♀️
  • AFSDB RRs don't include protocol or port info. They implicitly assume all VLDB servers are contacted over the standard port and UDP. Future changes to the AFS protocol may need separate VLDB server lists for UDP and TCP traffic, and some uses of AFS, like providing VLDB service for multiple cells from the same systems, need different ports.
  • Clients using AFSDB RRs have to assume that VLDB and PTS services are provided by the same host, but it may be useful to separate VLDB servers from PTS servers.
  • DNS SRV RRs are in widespread use, whereas AFSDB RRs are a little-known and little-supported corner of the DNS protocol. 😭

For those reasons, it's desirable to move AFS service location from the AFSDB RR to DNS SRV RRs. Honestly, it's giving upgrade 🦋

2. Scope 🧚

This document describes the format and use of DNS SRV RRs for AFS service location, and it deprecates the AFSDB RR. It also gives guidance for moving from the AFSDB RR to DNS SRV RRs, plus recommendations for backward compatibility.

Documentation of the AFS protocol, the exact purpose and use of the VLDB and PTS services, and other info about AFS are outside the scope of this document. Not our tea here 🍵

AFSDB RRs may also be used to locate servers for the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE) authenticated naming system, as described in [RFC1183]. Service location for DCE servers is outside the scope of this document and is not modified by this specification.

3. Requirements Notation 🔑

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

4. DNS SRV RRs for AFS 💜

The label of a DNS SRV RR, as defined in [RFC2782], is:

    _<service>._<proto>.<name>

The following values for <service> advertise servers that provide AFS services:

afs3-vlserver:  servers providing AFS VLDB services.

afs3-prserver:  servers providing AFS PTS services.

Other AFS services, like file and volume management services, are located through the VLDB service, so they don't use DNS SRV RRs. 🫶

<proto> MUST be "udp" for the current AFS protocol, which uses Rx over UDP. Other values may be used for future revisions of the AFS protocol that support other protocols, like Rx over TCP.

<name> MUST be the AFS cell name for which the identified server provides AFS services. Clients MUST query DNS SRV RRs only for a <name> value that exactly matches the AFS cell of interest. They MUST NOT remove leading components to search for more general DNS SRV RRs. The AFS cell "prod.example.com" and the AFS cell "example.com" are entirely different cells in the AFS protocol, and the VLDB servers for the latter cannot provide info for the former. Not the same cell, sorry not sorry 🙅‍♀️

NOTE: As with AFSDB RRs, this means DNS SRV RRs can only be used to locate AFS services for cells whose names match the structure of the DNS. This isn't a requirement of the AFS protocol, but sites creating new AFS cells SHOULD use names that follow the structure of the DNS and that result in DNS SRV RRs under their administrative control. This both permits use of DNS SRV RRs instead of client configuration and helps avoid naming conflicts between separate AFS cells. 🎀

DNS SRV RRs include a priority and a weight. As defined in the DNS SRV RR specification [RFC2782], clients MUST attempt to contact the target host with the lowest-numbered priority they can reach. So AFS clients that use a ranked algorithm to decide which server to contact MUST assign a sufficiently distinct rank to targets with different priorities. That way, targets with a higher-numbered priority are only contacted if all targets with a lower-numbered priority are inaccessible. See Section 4.1 for more info. 👑

If there are multiple targets with an equal priority, the weight value of the DNS SRV RR SHOULD be used as input to a weighted algorithm for selecting servers. As specified by [RFC2782], larger weights SHOULD be given a proportionately higher probability of being selected. When records with weights greater than 0 are present, records with weight 0 should have a very small chance of being selected. A weight of 0 SHOULD be used if all targets with that priority are weighted equally. AFS clients MAY take network performance and other protocol metrics into account along with SRV RR weights when selecting servers, which may mean they pick different servers than a system based purely on the SRV RRs would indicate. However, that info MUST NOT override the priority information in the SRV RR. ✨

DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which the SRV record info is no longer valid (see [RFC1034]). DNS RRs SHOULD be discarded after their TTL, and after the DNS query is repeated. This applies to DNS SRV RRs for AFS just like it does for any other DNS RR. Any info derived from the DNS SRV RRs, like preference ranks, MUST be discarded when the DNS SRV RR expires. ⏰

Implementations are not required to re-run the weighted server selection algorithm for each call. Instead, they MAY reuse the results of the algorithm until the DNS SRV RRs expire. Clients could therefore use a specific server for the lifetime of the DNS SRV records, which may affect the load distribution properties that DNS SRV records provide. Server operators should account for this effect when setting the TTL of those records. 🧠

AFS clients MAY remember which targets are inaccessible to that client and ignore those targets when deciding which server to contact first. Clients that do this SHOULD have a mechanism to retry targets that were previously inaccessible, and to reconsider them according to their current priority and weight if they become accessible again. 🔄

Heads up bestie: the text you sent stops right after this Section 4 paragraph about retrying inaccessible targets. Section 4.1 and everything after it aren't in what I got, so drop those in for part 2 and I'll keep the glow going 💖

4.1. Interpretation as AFS Preference Ranks ✨

okay so a bunch of AFS implementations use a ranking trick 🎀 where each server gets a number for its preference rank when the client first shows up to that AFS cell. The client then goes for the server with the lowest rank, unless that server goes down 💀. Clients using this algorithm SHOULD assign their ranks like this:

  1. Sort the targets by priority and give each target a base rank value based on its priority. Each base rank value MUST be sufficiently different from the base rank given to any higher-numbered priority, so higher-numbered targets only get tried when the lower-numbered ones can't be reached 🙅. It MUST, in other words, be farther from the base rank of any distinct priority than any possible automatic adjustment in the rank. When you're doing the base ranks, the actual number of a priority means nothing 🤷. Only the order of the distinct priority values across the SRV RR targets needs to show up in the base ranks.
  2. For each group of targets with the same priority, follow the algorithm in [RFC2782] to put them in order. Then give those targets ranks made by incrementing the base weight for that priority, so the first selected target gets the lowest rank, the second selected target gets the next-lowest rank, and so on ✨.

After the ranks are assigned, the AFS client MAY adjust the ranks dynamically based on network performance and other protocol metrics 💅. Those adjustments just have to be sufficiently small compared to the gap between base ranks, so they can't cause a higher-numbered priority server to get contacted instead of a lower-numbered one.

The TTL of the DNS SRV RRs MUST be honored by invalidating and regenerating the server preference ranks with new DNS information once that TTL has expired. But accumulated network and protocol metrics may be kept and reapplied to the new rankings 🧠.

AFS server preference ranks are conventionally numbers between 1 and 65535. DNS SRV RR priorities are also numbers between 0 and 65535. So implementations following this algorithm could run into trouble assigning sufficiently distinct base rank values in exceptional cases, like a huge number of DNS SRV RR targets with different priorities 😵. Honestly though, an AFS cell config with thousands of DNS SRV RR targets for an AFS VLDB or PTS service with meaningfully distinct priorities is highly improbable 🙃. AFS client implementations that encounter a DNS SRV RR with more distinct priority values than can be correctly represented as base ranks SHOULD fall back to generating ranks based solely on priorities, ignoring other rank inputs, and disabling dynamic adjustment of ranks. Implementations MUST be able to assign distinct base ranks as described above for at least ten distinct priority values.

5. Use of AFSDB RRs ✨

Lots of AFS client implementations support AFSDB RRs but don't support DNS SRV RRs yet 🥺. So AFS cells providing DNS SRV RRs SHOULD also provide AFSDB RRs. Be aware though, AFSDB RRs don't carry priority or weighting info, so every server listed in AFSDB RRs is treated as equal 🙈. AFSDB RRs also don't give any port info.

An AFS cell using DNS SRV RRs SHOULD therefore also provide an AFSDB RR listing all AFS servers for which all of the following statements are true:

  • The server provides both VLDB and PTS service on the standard ports (7003 and 7002, respectively).
  • The server provides these services via Rx over UDP.
  • The server either has the lowest-numbered priority of those listed in the DNS SRV RRs, or the AFS cell administrator believes it's reasonable for clients using AFSDB RRs to use this server by preference.

The above is a default recommendation 🌈. AFS cell administrators MAY use different lists of servers in the AFSDB RRs and DNS SRV RRs if they want specific effects, based on local knowledge of which clients use AFSDB RRs and which use DNS SRV RRs. Still, AFS servers SHOULD NOT be advertised with AFSDB RRs unless they provide VLDB and PTS services via UDP on the standard ports. (This falls shy of MUST NOT, because it may be useful in some unusual circumstances to advertise, via an AFSDB RR, a server that provides only one of the two services. But be aware that such a configuration may confuse legacy clients 👀.)

An AFS cell SHOULD have at least one VLDB and at least one PTS server providing service on the standard ports of 7003 and 7002, respectively. Clients without DNS SRV RR support can't locate servers on non-standard ports, so this matters a lot 🫶.

Clients SHOULD query DNS SRV RRs by default, but SHOULD then fall back on 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 the following pair of DNS SRV RRs:

_afs3-vlserver._udp.<cell> <ttl> IN SRV 0 0 7003 <hostname>
_afs3-prserver._udp.<cell> <ttl> IN SRV 0 0 7002 <hostname>

<cell> is the label of the AFSDB RR, <ttl> is its TTL and <hostname> is the <hostname> value of the AFSDB RR as specified in [RFC1183]. This is the fully-qualified domain name of the server 🍓.

6. Example ✨

This example is a whole bingo card 🎰. It includes TCP AFS services, separation of a PTS server from a VLDB server, and use of non-standard ports. All of these features either assume future AFS protocol development or aren't widely supported by current clients. This example is meant to show the range of possibilities for AFS DNS SRV RRs, not to be a practical example for an existing cell 🧚. It's a part of the zone file for a fictional example.com domain with AFS services.

$ORIGIN example.com.
@                    SOA   dns.example.com. root.example.com. (
                             2009100201 3600 3600 604800 86400 )
                     NS    dns.example.com.
_afs3-vlserver._udp  SRV   0 2 7003 afsdb1.example.com.
_afs3-vlserver._udp  SRV   0 4 7003 afsdb2.example.com.
_afs3-vlserver._udp  SRV   1 0 65500 afsdb3.example.com.

_afs3-vlserver._tcp  SRV   0 0 7003 afsdb3.example.com.

_afs3-prserver._udp  SRV   0 0 7002 afsdb1.example.com.

_afs3-prserver._tcp  SRV   0 0 7002 afsdb3.example.com.

@                    AFSDB 1 afsdb1.example.com.

dns                  A     192.0.2.9
afsdb1               A     192.0.2.10
afsdb2               A     192.0.2.11
afsdb3               A     192.0.2.12

In this example, the AFS cell name is example.com. 🏠

afsdb1, afsdb2, and afsdb3 all provide VLDB service via UDP. The first two have the same priority, but their weights say afsdb1 should get about twice as many clients as afsdb2. afsdb3 should only be used for UDP VLDB service if afsdb1 and afsdb2 aren't accessible, and it provides that service on a non-standard port (65500) 🦋.

Only one host, afsdb1, provides UDP PTS service 👑.

afsdb3 provides a hypothetical TCP version of AFS VLDB and PTS service on the standard ports. It's the only server providing these services over TCP for this cell 🌸. Such a TCP-based AFS protocol did not exist when this document was written. This example just shows what the record would look like in a hypothetical future where such a protocol gets developed.

An AFSDB RR is provided for backward compatibility with older clients. It lists only afsdb1, since that's the only host providing both VLDB and PTS service over UDP on the standard ports 💜.

7. Security Considerations 🔥

Using DNS SRV RRs for AFS service locations poses the same security issues as the existing AFSDB RRs, and this part is seriously important 😭. Unless the integrity and authenticity of the DNS response are checked, an attacker may forge DNS replies and thereby direct clients at a VLDB or PTS server under the attacker's control. From there, the attacker may deceive an AFS client about the volumes and file servers in a cell, and about the contents of files and directories in that cell. If the client uses cell data in a trusted way, such as by executing programs out of that AFS cell or using data from the cell as input to other programs, the attacker may be able to further compromise the client's security and trick it into taking action under the attacker's control 🚨.

This attack can be prevented if the server is authenticated, since the client can then detect a failure to authenticate the attacker's servers and thereby detect possible impersonation. However, this only applies to authenticated AFS access, and a lot of AFS access is unauthenticated 💀. Furthermore, clients that fail to authenticate may fall back to unauthenticated access, which the attacker's servers may permit.

Using an integrity-protected DNS system such as DNS Security (DNSSEC) [RFC4033] can prevent this attack via DNS. However, the underlying vulnerability is inherent in the current AFS protocol and may be exploited in ways other than DNS forgery, such as by forging the results of VLDB queries for an AFS cell. Properly addressing it requires changes to the AFS protocol that let clients always authenticate AFS services and discard unauthenticated data 🛡️. Even without a DNS system with integrity protection, adding DNS SRV RRs does not make this vulnerability more severe. It only opens another equivalent point of attack.

8. References 📚

8.1. Normative References

  • [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
  • [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.

8.2. Informative References

  • [AFS1] Howard, J., Kazar, M., Menees, S., Nichols, D., Satyanarayanan, M., Sidebotham, R., and M. West, "Scale and Performance in a Distributed File System", ACM Trans. on Computer Systems 6(1), February 1988.
  • [AFS2] Howard, J., "An Overview of the Andrew File System", CMU-ITC 88-062, February 1988.
  • [ARLA] Assar Westerlund, et al., "Arla", May 2001, http://www.stacken.kth.se/project/arla/html/arla.html.
  • [OPENAFS] IBM Corporation, et al., "OpenAFS Documentation", April 2000, http://docs.openafs.org/.
  • [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

Author's Address 🎀

Russ Allbery
Stanford University
P.O. Box 20066
Stanford, CA  94309
US

EMail: rra@stanford.edu
URI:   http://www.eyrie.org/~eagle/
📦 where this page comes from