[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 5864

Network Working Group                                         R. Allbery
Internet-Draft                                       Stanford University
Intended status: Informational                           October 3, 2009
Expires: April 6, 2010

                    DNS SRV Resource Records for AFS

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 6, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   This document specifies how to use DNS (Domain Name Service) SRV RRs
   (Resource Records) to locate services for the AFS distributed file
   system and how the priority and weight values of the SRV RR should be

Allbery                   Expires April 6, 2010                 [Page 1]

Internet-Draft      DNS SRV Resource Records for AFS        October 2009

   interpreted in the server weighting system used by AFS.  It
   deprecates use of the AFSDB RR to locate AFS cell database servers
   and provides guidance for backward compatibility.

Internet Draft Comments

   Comments are solicited.  Please include the AFS Standardization
   mailing list at afs3-standardization@openafs.org as a recipient of
   any comments.

Table of Contents

   1.  Overview and Rationale  . . . . . . . . . . . . . . . . . . . . 3
   2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Requirements Notation . . . . . . . . . . . . . . . . . . . . . 4
   4.  DNS SRV RRs for AFS . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Use of AFSDB RRs  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

Allbery                   Expires April 6, 2010                 [Page 2]

Internet-Draft      DNS SRV Resource Records for AFS        October 2009

1.  Overview and Rationale

   AFS (a registered trademark of IBM Corporation) is a distributed file
   system organized administratively into cells.  Each AFS cell consists
   of one or more Volume Location Database (VLDB) servers, one or more
   Protection Service (PTS) servers, and one or more pairs of file
   servers and volume servers, plus possibly additional services not
   relevant to this document.  Data stored in AFS is divided into
   collections of files called volumes.  An AFS protocol client, when
   accessing a file within a specific AFS cell, first contacts a VLDB
   server for that cell to determine the file server for the AFS volume
   in which that file is located, and then contacts that file server
   directly to access the file.  A client may also need to contact a PTS
   server for that cell to register before accessing files in that cell.

   An AFS client therefore needs to determine, for a given AFS cell, the
   VLDB and possibly the PTS servers for that cell.  (Traditionally, the
   VLDB and PTS servers are provided by the same host.)  Once the client
   is in contact with the VLDB server, it locates file and volume
   servers through AFS protocol queries to the VLDB server.  Originally,
   VLDB server information was configured separately on each client in a
   file called the CellServDB file.  [RFC1183] specified the DNS RR
   (Resource Record) AFSDB to locate VLDB servers for AFS.

   Subsequent to [RFC1183], a general DNS RR was defined by [RFC2782]
   for service location for any service.  This DNS SRV RR has several
   advantages over the AFSDB RR:

   o  AFSDB RRs do not support priority or ranking, leaving AFS cell
      administrators without a way to control which VLDB servers clients

   o  AFSDB RRs do not include protocol or port information, implicitly
      assuming that all VLDB servers will be contacted over the standard
      port and the UDP protocol.  Future changes to the AFS protocol may
      require separate VLDB server lists for UDP and TCP traffic, and
      some uses of AFS, such as providing VLDB service for multiple
      cells from the same systems, require use of different ports.

   o  Clients using AFSDB RRs must assume that VLDB and PTS services are
      provided by the same host, but it may be useful to separate VLDB
      servers from PTS servers.

   o  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 is desirable to move AFS service location from
   the AFSDB RR to DNS SRV RRs.

Allbery                   Expires April 6, 2010                 [Page 3]

Internet-Draft      DNS SRV Resource Records for AFS        October 2009

2.  Scope

   This document describes the format and use of DNS SRV RRs for AFS
   service location and deprecates the AFSDB RR.  It also provides
   guidance for transition from the AFSDB RR to DNS SRV RRs and
   recommendations for backward compatibility.

   Documentation of the AFS protocol, the exact purpose and use of the
   VLDB and PTS services, and other information about AFS is outside the
   scope of this document.

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

3.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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:


   The following values for <service> advertise servers providing AFS

   afs3-vlserver:  servers providing AFS VLDB services.

   afs3-prserver:  servers providing AFS PTS services.

   Other AFS services, such as file and volume management services, are
   located through the VLDB service and therefore do not use DNS SRV

   <proto> MUST be "udp" for the current AFS protocol, which uses Rx
   over UDP.  The value "tcp" may be used for future revisions of the
   AFS protocol using 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

Allbery                   Expires April 6, 2010                 [Page 4]

Internet-Draft      DNS SRV Resource Records for AFS        October 2009

   <name> value exactly matching 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 VLDB servers for the
   latter cannot provide information for the former.

      NOTE: As with AFSDB RRs, this means that DNS SRV RRs can only be
      used to locate AFS services for cells whose naming matches the
      structure of DNS.  This is not a requirement of the AFS protocol,
      but sites creating new AFS cells SHOULD use names that follow the
      structure of DNS and which 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.  AFS
   clients which use a weighted algorithm to determine which server to
   contact MUST therefore assign a sufficiently distinct weight to
   targets with different priorities such that targets with a higher-
   numbered priority are only contacted if all targets with a lower-
   numbered priority are inaccessible.

   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.  In the presence of records containing weights greater than
   0, 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.

   Several AFS implementations use a weighted algorithm that assigns
   numbers to each server when the client first contacts that AFS cell
   and then prefers the server with the lowest weight unless that server
   goes down.  Clients using this algorithm should assign their weights
   as follows:

   1.  Sort targets by priority and assign a base weight to each target
       based on its priority.  Each base weight MUST be sufficiently
       different from the base weight assigned to any higher-numbered
       priority that higher-numbered targets will only be attempted if
       lower-numbered targets cannot be reached.

   2.  For each group of targets with the same priority, follow the
       algorithm in [RFC2782] to order those targets.  Then, assign
       those targets weights formed by incrementing the base weight for

Allbery                   Expires April 6, 2010                 [Page 5]

Internet-Draft      DNS SRV Resource Records for AFS        October 2009

       that priority such that the first selected target has the lowest
       weight, the second selected target has the next lowest weight,
       and so on.

5.  Use of AFSDB RRs

   Since many AFS client implementations currently support AFSDB RRs but
   do not support DNS SRV RRs, AFS cells providing DNS SRV RRs SHOULD
   also provide AFSDB RRs.  However, be aware that AFSDB RRs do not
   provide priority or weighting information; all servers listed in
   ASFDB RRs are treated as equal.  AFSDB RRs also do not provide port

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

   o  The server provides both VLDB and PTS service on the standard
      ports (7003 and 7002) respectively.

   o  The server provides these services over UDP.

   o  The server either has the lowest-numbered priority of those listed
      in the DNS SRV RRs or the AFS cell administrator believes it
      reasonable for clients using AFSDB RRs to use this server by

   The above is a default recommendation.  AFS cell administrators MAY
   use different lists of servers in the AFSDB RRs and DNS SRV RRs if
   desired for specific effects based on local knowledge of which
   clients use AFSDB RRs and which clients use DNS SRV RRs.  However,
   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 at least one PTS server
   providing service on the standard ports of 7003 and 7002,
   respectively, since clients without DNS SRV RR support cannot locate
   servers on non-standard ports.

   Clients SHOULD query DNS SRV RRs by default but SHOULD then fall back
   on AFSDB RRs if no DNS SRV RRs are found.  All servers listed in 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 <host>
       _afs3-prserver._udp.<cell> <ttl> IN SRV 0 0 7002 <host>

Allbery                   Expires April 6, 2010                 [Page 6]

Internet-Draft      DNS SRV Resource Records for AFS        October 2009

   <cell> is the label of the AFSDB RR, <tt> is its TTL, and <host> is
   the <hostname> value, following the specification in [RFC1183].

6.  Example

   The following example includes TCP AFS services, separation of a PTS
   server from a VLDB server, and use of non-standard ports, all
   features that either assume future AFS protocol development or are
   not widely supported by current clients.  This example is intended to
   show the range of possibilities for AFS DNS SRV RRs, not as a
   practical example for an existing cell.  This is a part of the zone
   file for a fictional example.com domain with AFS services.

       $ORIGIN example.com.
       @                    SOA   server.example.com. root.example.com.
                                   ( 2009100201 3600 3600 604800 86400 )
                            NS    server.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 7008 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.

       afsdb1               A
       afsdb2               A
       afsdb3               A

   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 have weights indicating that
   afsdb1 should get about twice as many clients as afsdb2. afsdb3
   should only be used for UDP VLDB service if afsdb1 and afsdb2 are not
   accessible and provides that service on a non-standard port (7008).

   Only one host, afsdb1, provides UDP PTS service.

   afsdb3 provides a theoretical TCP version of AFS VLDB and PTS service
   on the standard ports and is the only server providing these services
   over TCP for this cell.

Allbery                   Expires April 6, 2010                 [Page 7]

Internet-Draft      DNS SRV Resource Records for AFS        October 2009

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

7.  Security Considerations

   Use of DNS SRV RRs for AFS service location pose the same security
   issues as the existing AFSDB RRs.  Specifically, unless the integrity
   and authenticity of the DNS response is checked, an attacker may
   forge DNS replies and thereby direct clients at a VLDB or PTS server
   under the control of the attacker.  From there, the attacker may
   decieve 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 security
   of the client and trick it into taking actions under the attacker's

   This attack can be ameliorated if the client is authenticated using
   the Kerberos-based authentication provided by the AFS protocol, since
   the client can then detect a failure to authenticate to the
   attacker's servers and thereby detect possible impersonation.
   However, this applies only to authenticated AFS access, and much AFS
   access is unauthenticated.  Furthermore, clients after failure to
   authenticate may fall back to unauthenticated access, which the
   attacker's servers may permit.

   This vulnerability is inherent in the current AFS protocol and may be
   exploited in ways other than DNS spoofing, such as by spoofing the
   results of VLDB queries for an AFS cell.  Addressing it properly
   requires changes to the AFS protocol allowing clients to always
   authenticate AFS services and discard unauthenticated data.  Addition
   of DNS SRV RRs does not make this vulnerability more severe, only
   opens another equivalent point of attack.

8.  References

   [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

Allbery                   Expires April 6, 2010                 [Page 8]

Internet-Draft      DNS SRV Resource Records for AFS        October 2009

              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

Author's Address

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

   Email: rra@stanford.edu
   URI:   http://www.eyrie.org/~eagle/

Allbery                   Expires April 6, 2010                 [Page 9]

Html markup produced by rfcmarkup 1.114, available from https://tools.ietf.org/tools/rfcmarkup/