idnits 2.17.1 draft-allbery-afs-srv-records-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1183, updated by this document, for RFC5378 checks: 1990-10-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 24, 2010) is 5174 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 1183 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Allbery 3 Internet-Draft Stanford University 4 Updates: 1183 (if approved) February 24, 2010 5 Intended status: Standards Track 6 Expires: August 28, 2010 8 DNS SRV Resource Records for AFS 9 draft-allbery-afs-srv-records-05 11 Abstract 13 This document specifies how to use DNS (Domain Name Service) SRV RRs 14 (Resource Records) to locate services for the AFS distributed file 15 system and how the priority and weight values of the SRV RR should be 16 interpreted in the server ranking system used by AFS. It updates RFC 17 1183 to deprecate use of the AFSDB RR to locate AFS cell database 18 servers and provides guidance for backward compatibility. 20 Internet Draft Comments 22 Comments are solicited. Please include the AFS Standardization 23 mailing list at afs3-standardization@openafs.org as a recipient of 24 any comments. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on August 28, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . . 3 67 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 69 4. DNS SRV RRs for AFS . . . . . . . . . . . . . . . . . . . . . 4 70 4.1. Interpretation as AFS Preference Ranks . . . . . . . . . . 6 71 5. Use of AFSDB RRs . . . . . . . . . . . . . . . . . . . . . . . 7 72 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Overview and Rationale 82 AFS (a registered trademark of IBM Corporation) is a distributed file 83 system (see [AFS1] and [AFS2]). Its most widely-used implementations 84 are [OPENAFS] and [ARLA]. 86 AFS is organized administratively into cells. Each AFS cell consists 87 of one or more Volume Location Database (VLDB) servers, one or more 88 Protection Service (PTS) servers, and one or more file servers and 89 volume servers, plus possibly additional services not relevant to 90 this document. Data stored in AFS is divided into collections of 91 files called volumes. An AFS protocol client, when accessing a file 92 within a specific AFS cell, first contacts a VLDB server for that 93 cell to determine the file server for the AFS volume in which that 94 file is located, and then contacts that file server directly to 95 access the file. A client may also need to contact a PTS server for 96 that cell to register before accessing files in that cell or to query 97 protection database information. 99 An AFS client therefore needs to determine, for a given AFS cell, the 100 VLDB and possibly the PTS servers for that cell. (Traditionally, the 101 VLDB and PTS servers are provided by the same host.) Once the client 102 is in contact with the VLDB server, it locates file and volume 103 servers through AFS protocol queries to the VLDB server. Originally, 104 VLDB server information was configured separately on each client in a 105 file called the CellServDB file. [RFC1183] specified the DNS RR 106 (Resource Record) AFSDB to locate VLDB servers for AFS. 108 Subsequent to [RFC1183], a general DNS RR was defined by [RFC2782] 109 for service location for any service. This DNS SRV RR has several 110 advantages over the AFSDB RR: 112 o AFSDB RRs do not support priority or ranking, leaving AFS cell 113 administrators without a way to indicate which VLDB servers 114 clients should prefer. 116 o AFSDB RRs do not include protocol or port information, implicitly 117 assuming that all VLDB servers will be contacted over the standard 118 port and the UDP protocol. Future changes to the AFS protocol may 119 require separate VLDB server lists for UDP and TCP traffic, and 120 some uses of AFS, such as providing VLDB service for multiple 121 cells from the same systems, require use of different ports. 123 o Clients using AFSDB RRs must assume that VLDB and PTS services are 124 provided by the same host, but it may be useful to separate VLDB 125 servers from PTS servers. 127 o DNS SRV RRs are in widespread use, whereas AFSDB RRs are a little- 128 known and little-supported corner of the DNS protocol. 130 For those reasons, it is desirable to move AFS service location from 131 the AFSDB RR to DNS SRV RRs. 133 2. Scope 135 This document describes the format and use of DNS SRV RRs for AFS 136 service location and deprecates the AFSDB RR. It also provides 137 guidance for transition from the AFSDB RR to DNS SRV RRs and 138 recommendations for backward compatibility. 140 Documentation of the AFS protocol, the exact purpose and use of the 141 VLDB and PTS services, and other information about AFS are outside 142 the scope of this document. 144 AFSDB RRs may also be used for locating servers for the Open Software 145 Foundation's (OSF) Distributed Computing Environment (DCE) 146 authenticated naming system, as described in [RFC1183]. Service 147 location for DCE servers is outside the scope of this document and 148 not modified by this specification. 150 3. Requirements Notation 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 4. DNS SRV RRs for AFS 158 The label of a DNS SRV RR, as defined in [RFC2782], is: 160 _._. 162 The following values for advertise servers providing AFS 163 services: 165 afs3-vlserver: servers providing AFS VLDB services. 167 afs3-prserver: servers providing AFS PTS services. 169 Other AFS services, such as file and volume management services, are 170 located through the VLDB service and therefore do not use DNS SRV 171 RRs. 173 MUST be "udp" for the current AFS protocol, which uses Rx 174 over UDP. Other values may be used for future revisions of the AFS 175 protocol supporting other protocols, such as Rx over TCP. 177 MUST be the AFS cell name for which the identified server 178 provides AFS services. Clients MUST query DNS SRV RRs only for a 179 value exactly matching the AFS cell of interest. They MUST 180 NOT remove leading components to search for more general DNS SRV RRs. 181 The AFS cell "prod.example.com" and the AFS cell "example.com" are 182 entirely different cells in the AFS protocol and VLDB servers for the 183 latter cannot provide information for the former. 185 NOTE: As with AFSDB RRs, this means that DNS SRV RRs can only be 186 used to locate AFS services for cells whose naming matches the 187 structure of the DNS. This is not a requirement of the AFS 188 protocol, but sites creating new AFS cells SHOULD use names that 189 follow the structure of the DNS and which result in DNS SRV RRs 190 under their administrative control. This both permits use of DNS 191 SRV RRs instead of client configuration and helps avoid naming 192 conflicts between separate AFS cells. 194 DNS SRV RRs include a priority and a weight. As defined in the DNS 195 SRV RR specification [RFC2782], clients MUST attempt to contact the 196 target host with the lowest-numbered priority they can reach. AFS 197 clients which use a ranked algorithm to determine which server to 198 contact MUST therefore assign a sufficiently distinct ranks to 199 targets with different priorities such that targets with a higher- 200 numbered priority are only contacted if all targets with a lower- 201 numbered priority are inaccessible. See Section 4.1 for more 202 information. 204 If there are multiple targets with an equal priority, the weight 205 value of the DNS SRV RR SHOULD be used as input to a weighted 206 algorithm for selecting servers. As specified by [RFC2782], larger 207 weights SHOULD be given a proportionately higher probability of being 208 selected. In the presence of records containing weights greater than 209 0, records with weight 0 should have a very small chance of being 210 selected. A weight of 0 SHOULD be used if all targets with that 211 priority are weighted equally. AFS clients MAY take into account 212 network performance and other protocol metrics along with SRV RR 213 weights when selecting servers, thereby possibly selecting different 214 servers than a system based purely on the SRV RRs would indicate. 215 However, such information MUST NOT override the priority information 216 in the SRV RR. 218 DNS SRV RRs, like all DNS RRs, have a time-to-live (TTL), after which 219 the SRV record information is no longer valid (see [RFC1034]). DNS 220 RRs SHOULD be discarded after their TTL, and the DNS query repeated. 222 This applies to DNS SRV RRs for AFS as to any other DNS RR. Any 223 information derived from the DNS SRV RRs, such as preference ranks, 224 MUST be discarded when the DNS SRV RR is expired. 226 Implementations are not required to re-run the weighted server 227 selection algorithm for each call. They MAY instead reuse the 228 results of the algorithm until the DNS SRV RRs expire. Clients could 229 therefore use a specific server for the lifetime of the DNS SRV 230 records, which may affect the load distribution properties that DNS 231 SRV records provide. Server operators should account for this effect 232 when setting the TTL of those records. 234 AFS clients MAY remember which targets are inaccessible by that 235 client and ignore those targets when determining which server to 236 contact first. Clients which do this SHOULD have a mechanism to 237 retry targets which were previously inaccessible and reconsider them 238 according to their current priority and weight if they become 239 accessible again. 241 4.1. Interpretation as AFS Preference Ranks 243 Several AFS implementations use a ranking algorithm that assigns 244 numbers representing a preference rank to each server when the client 245 first contacts that AFS cell and then prefers the server with the 246 lowest rank unless that server goes down. Clients using this 247 algorithm SHOULD assign their ranks as follows: 249 1. Sort targets by priority and assign a base rank value to each 250 target based on its priority. Each base rank value MUST be 251 sufficiently different from the base rank assigned to any higher- 252 numbered priority that higher-numbered targets will only be 253 attempted if lower-numbered targets cannot be reached. It MUST, 254 in other words, be farther from the base rank of any distinct 255 priority than any possible automatic adjustment in the rank. 256 When calculating base ranks, observe that the numeric value of a 257 priority has no meaning. Only the ordering of distinct priority 258 values between multiple SRV RR targets needs to be reflected in 259 the base ranks. 261 2. For each group of targets with the same priority, follow the 262 algorithm in [RFC2782] to order those targets. Then, assign 263 those targets ranks formed by incrementing the base weight for 264 that priority such that the first selected target has the lowest 265 rank, the second selected target has the next lowest rank, and so 266 on. 268 After assignment of ranks, the AFS client MAY then adjust the ranks 269 dynamically based on network performance and other protocol metrics, 270 provided that such adjustments are sufficiently small compared to the 271 difference between base ranks that they cannot cause servers with a 272 higher-numbered priority to be contacted instead of a server with a 273 lower-numbered priority. 275 The TTL of the DNS SRV RRs MUST be honored by invalidating and 276 regenerating the server preference ranks with new DNS information 277 once that TTL has expired. However, accumulated network and protocol 278 metrics may be retained and reapplied to the new rankings. 280 AFS server preference ranks are conventionally numbers between 1 and 281 65535. DNS SRV RR priorities are numbers between 0 and 65535. 282 Implementations following this algorithm could therefore encounter 283 problems assigning sufficiently distinct base rank values in 284 exceptional cases of very large numbers of DNS SRV RR targets with 285 different priorities. However, an AFS cell configuration with 286 thousands of DNS SRV RR targets for an AFS VLDB or PTS service with 287 meaningfully distinct priorities is highly improbable. AFS client 288 implementations encountering a DNS SRV RR containing targets with 289 more distinct priority values than can be correctly represented as 290 base ranks SHOULD fall back to generating ranks based solely on 291 priorities, ignoring other rank inputs, and disabling dynamic 292 adjustment of ranks. Implementations MUST be able to assign distinct 293 base ranks as described above for at least ten distinct priority 294 values. 296 5. Use of AFSDB RRs 298 Since many AFS client implementations currently support AFSDB RRs but 299 do not support DNS SRV RRs, AFS cells providing DNS SRV RRs SHOULD 300 also provide AFSDB RRs. However, be aware that AFSDB RRs do not 301 provide priority or weighting information; all servers listed in 302 ASFDB RRs are treated as equal. AFSDB RRs also do not provide port 303 information. 305 An AFS cell using DNS SRV RRs SHOULD therefore also provide an AFSDB 306 RR listing all AFS servers for which the following statements are all 307 true: 309 o The server provides both VLDB and PTS service on the standard 310 ports (7003 and 7002) respectively. 312 o The server provides these services via Rx over UDP. 314 o The server either has the lowest-numbered priority of those listed 315 in the DNS SRV RRs or the AFS cell administrator believes it 316 reasonable for clients using AFSDB RRs to use this server by 317 preference. 319 The above is a default recommendation. AFS cell administrators MAY 320 use different lists of servers in the AFSDB RRs and DNS SRV RRs if 321 desired for specific effects based on local knowledge of which 322 clients use AFSDB RRs and which clients use DNS SRV RRs. However, 323 AFS servers SHOULD NOT be advertised with AFSDB RRs unless they 324 provide VLDB and PTS services via UDP on the standard ports. (This 325 falls shy of MUST NOT because it may be useful in some unusual 326 circumstances to advertise via an AFSDB RR a server that provides 327 only one of the two services, but be aware that such a configuration 328 may confuse legacy clients.) 330 An AFS cell SHOULD have at least one VLDB and at least one PTS server 331 providing service on the standard ports of 7003 and 7002, 332 respectively, since clients without DNS SRV RR support cannot locate 333 servers on non-standard ports. 335 Clients SHOULD query DNS SRV RRs by default but SHOULD then fall back 336 on AFSDB RRs if no DNS SRV RRs are found. In the absence of DNS SRV 337 RRs, an AFSDB RR of 1 SHOULD be treated as equivalent to 338 the following pair of DNS SRV RRs: 340 _afs3-vlserver._udp. IN SRV 0 0 7003 341 _afs3-prserver._udp. IN SRV 0 0 7002 343 is the label of the AFSDB RR, is its TTL, and 344 is the value of the AFSDB RR as specified in [RFC1183]. 345 This is the fully-qualified domain name of the server. 347 6. Example 349 The following example includes TCP AFS services, separation of a PTS 350 server from a VLDB server, and use of non-standard ports, all 351 features that either assume future AFS protocol development or are 352 not widely supported by current clients. This example is intended to 353 show the range of possibilities for AFS DNS SRV RRs, not as a 354 practical example for an existing cell. This is a part of the zone 355 file for a fictional example.com domain with AFS services. 357 $ORIGIN example.com. 358 @ SOA dns.example.com. root.example.com. ( 359 2009100201 3600 3600 604800 86400 ) 360 NS dns.example.com. 361 _afs3-vlserver._udp SRV 0 2 7003 afsdb1.example.com. 362 _afs3-vlserver._udp SRV 0 4 7003 afsdb2.example.com. 363 _afs3-vlserver._udp SRV 1 0 65500 afsdb3.example.com. 365 _afs3-vlserver._tcp SRV 0 0 7003 afsdb3.example.com. 367 _afs3-prserver._udp SRV 0 0 7002 afsdb1.example.com. 369 _afs3-prserver._tcp SRV 0 0 7002 afsdb3.example.com. 371 @ AFSDB 1 afsdb1.example.com. 373 dns A 192.0.2.9 374 afsdb1 A 192.0.2.10 375 afsdb2 A 192.0.2.11 376 afsdb3 A 192.0.2.12 378 In this example, the AFS cell name is example.com. 380 afsdb1, afsdb2, and afsdb3 all provide VLDB service via UDP. The 381 first two have the same priority but have weights indicating that 382 afsdb1 should get about twice as many clients as afsdb2. afsdb3 383 should only be used for UDP VLDB service if afsdb1 and afsdb2 are not 384 accessible and provides that service on a non-standard port (65500). 386 Only one host, afsdb1, provides UDP PTS service. 388 afsdb3 provides a hypothetical TCP version of AFS VLDB and PTS 389 service on the standard ports and is the only server providing these 390 services over TCP for this cell. Such a TCP-based AFS protocol did 391 not exist at the time this document was written. This example only 392 shows what the record would look like in a hypothetical future if 393 such a protocol were developed. 395 An AFSDB RR is provided for backward compatibility with older 396 clients. It lists only afsdb1, since only that host provides both 397 VLDB and PTS service over UDP on the standard ports. 399 7. Security Considerations 401 Use of DNS SRV RRs for AFS service location poses the same security 402 issues as the existing AFSDB RRs. Specifically, unless the integrity 403 and authenticity of the DNS response are checked, an attacker may 404 forge DNS replies and thereby direct clients at a VLDB or PTS server 405 under the control of the attacker. From there, the attacker may 406 deceive an AFS client about the volumes and file servers in a cell 407 and about the contents of files and directories in that cell. If the 408 client uses cell data in a trusted way, such as by executing programs 409 out of that AFS cell or using data from the cell as input to other 410 programs, the attacker may be able to further compromise the security 411 of the client and trick it into taking actions under the attacker's 412 control. 414 This attack can be prevented if the server is authenticated, since 415 the client can then detect a failure to authenticate the attacker's 416 servers and thereby detect possible impersonation. However, this 417 applies only to authenticated AFS access, and much AFS access is 418 unauthenticated. Furthermore, clients after failure to authenticate 419 may fall back to unauthenticated access, which the attacker's servers 420 may permit. 422 Using an integrity-protected DNS system such as DNSSEC [RFC4033] can 423 prevent this attack via DNS. However, the underlying vulnerability 424 is inherent in the current AFS protocol and may be exploited in ways 425 other than DNS forgery, such as by forging the results of VLDB 426 queries for an AFS cell. Addressing it properly requires changes to 427 the AFS protocol allowing clients to always authenticate AFS services 428 and discard unauthenticated data. Even in the absence of a DNS 429 system with integrity protection, addition of DNS SRV RRs does not 430 make this vulnerability more severe, only opens another equivalent 431 point of attack. 433 8. IANA Considerations 435 This document has no actions for IANA. 437 9. References 438 9.1. Normative References 440 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 441 STD 13, RFC 1034, November 1987. 443 [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. 444 Mockapetris, "New DNS RR Definitions", RFC 1183, 445 October 1990. 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, March 1997. 450 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 451 specifying the location of services (DNS SRV)", RFC 2782, 452 February 2000. 454 9.2. Informative References 456 [AFS1] Howard, J., Kazar, M., Menees, S., Nichols, D., 457 Satyanarayanan, M., Sidebotham, R., and M. West, "Scale 458 and Performance in a Distributed File System", ACM Trans. 459 on Computer Systems 6(1), February 1988. 461 [AFS2] Howard, J., "An Overview of the Andrew File System", CMU- 462 ITC 88-062, February 1988. 464 [ARLA] Assar Westerlund, et al., "Arla", May 2001, 465 . 467 [OPENAFS] IBM Corporation, et al., "OpenAFS Documentation", 468 April 2000, . 470 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 471 Rose, "DNS Security Introduction and Requirements", 472 RFC 4033, March 2005. 474 Author's Address 476 Russ Allbery 477 Stanford University 478 P.O. Box 20066 479 Stanford, CA 94309 480 US 482 Email: rra@stanford.edu 483 URI: http://www.eyrie.org/~eagle/