idnits 2.17.1 draft-hallambaker-web-service-discovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 13 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2019) is 1885 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 413 == Missing Reference: 'RFC2119' is mentioned on line 142, but not defined ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft February 25, 2019 4 Intended status: Informational 5 Expires: August 29, 2019 7 DNS Web Service Discovery 8 draft-hallambaker-web-service-discovery-01 10 Abstract 12 This document describes a standardized approach to discovering Web 13 Service Endpoints from a DNS name. Services are advertised using the 14 DNS SRV and TXT records and the HTTP Well Known Service conventions. 16 This document is also available online at 17 http://mathmesh.com/Documents/draft-hallambaker- web-service- 18 discovery.html [1] . 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 29, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Host Identification . . . . . . . . . . . . . . . . . . . 4 60 3.1.1. SRV Host discovery . . . . . . . . . . . . . . . . . 4 61 3.2. Service Description . . . . . . . . . . . . . . . . . . . 4 62 3.2.1. TXT Service and Host Description . . . . . . . . . . 5 63 3.3. Service Selection . . . . . . . . . . . . . . . . . . . . 5 64 3.4. Web Service Endpoint Determination . . . . . . . . . . . 5 65 3.5. DNS Fallback . . . . . . . . . . . . . . . . . . . . . . 6 66 3.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Further Work . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. Additional Description Keys . . . . . . . . . . . . . . . 8 69 4.2. Service Scaling . . . . . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 7.2. Informative References . . . . . . . . . . . . . . . . . 9 75 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 Web services are traditionally identified by means of a URI 81 specifying a Web Service Endpoint (WSE). This is approach is 82 unsatisfactory in many situations: 84 o Specification of the Web Service requires the transport and 85 presentation protocols to be fixed. 87 o The discovery mechanism does not provide support for load 88 balancing or fault tolerance. 90 o The identifiers are unsuited for human interaction. 92 The last consideration is a particular concern where an account 93 identifier is exposed to the user. Attempts to 'teach' users to use 94 URIs as account identifiers have been predictably unsuccessful. 95 Users expect and require accounts to be of the form user@example.com 96 and not http://service.example.com/service/user. 98 The Web Service discovery process described in this specification 99 builds on the approach specified in DNS-Based Service Discovery 100 [RFC6763] . This uses DNS SRV records as the basis for service 101 discovery and TXT records as the basis for service description. This 102 approach allows Web Services to make use of the load balancing and 103 fault tolerance features of SRV and the service negotiation 104 capabilities provided by the service description. 106 One difficulty that is frequently encountered in attempting to make 107 use of DNS records for service discovery is that it is not always 108 possible for an application process to access this information. 109 Specifications address the world as it actually is rather than as 110 some believe it should be have proven more robust in real world 111 deployment than those that do not. The discovery process defined 112 includes a fallback strategy to enable clients to achieve Web Service 113 discovery in these circumstances. 115 Another difficulty that is encountered is that the SRV record maps 116 service names to host names rather than Web Service Endpoints. A 117 convention is thus required to map a host name and protocol prefix to 118 a Web Service Endpoint. The HTTP Well Known Service [RFC5785] 119 mechanism is used for this purpose. 121 While the approach adopted in this specification closely follows that 122 of [RFC6763] , there is an important difference in that the earlier 123 specification sets out a framework which Web Services may apply to 124 develop a discovery approach that suits their particular needs while 125 this specification defines exactly one such approach. In particular, 126 the use of a common set of TXT keys to specify service parameters 127 enables service discovery and negotiation to be delegated to common 128 support libraries rather than being implemented independently in each 129 application. 131 2. Definitions 133 This section presents the related specifications and standard, the 134 terms that are used as terms of art within the documents and the 135 terms used as requirements language. 137 2.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2.2. Defined Terms 145 Web Service An Internet service provided by one or more Web Service 146 Hosts that are addressable by a single Web Service Endpoint and 147 are intended to provide logically equivalent services. 149 Web Service Endpoint (WSE) A URI that specifies a Web Service or Web 150 Service Host. 152 Web Service Host The actual machine (physical or virtual) that 153 provides a Web Service 155 3. Service Discovery 157 Service discovery is the process of resolving the address of a Web 158 Service to a Web Service Endpoint, a URI [RFC3986] at which the 159 service is provided. 161 3.1. Host Identification 163 The first step in service discovery is to resolve the and 164 identifiers to the IP address of a host that provides that 165 service. 167 3.1.1. SRV Host discovery 169 A client attempting to connect to the service first attempts to 170 locate an SRV record [RFC2782] for the specified service: 172 _._tcp. SRV 174 Where is the IANA assigned service name, and 175 are the SRV priority and weight parameters specified in 176 [RFC2782] , is the TCP port number and is the DNS name 177 of the host for which the service advertisement is made. 179 If no SRV records are found, the client MAY abort the connection or 180 attempt use of the Fallback Discovery process described below. 182 3.2. Service Description 184 The second step in service discovery is to identify the attributes of 185 the Web Service and Web Service Hosts providing that service. 187 3.2.1. TXT Service and Host Description 189 A service MAY advertise service and/or host description information 190 using TXT records as described in DNS-Based Service Discovery 191 [RFC6763] . These have the following format: 193 _._tcp. TXT "= [=]*" 194 _._tcp. TXT "= [=]*" 196 Where and are the domain names specified in the 197 corresponding SRV records. 199 Service descriptions specified under the domain address of the 200 service apply to all host instances of the service. Descriptions 201 specified under the domain address of a host instance apply only to 202 that host instance and take precedence over values specified at the 203 service level. 205 The following keys are currently defined: 207 path The path to use to construct the Web Service Endpoint. 209 version The service version(s) supported in the format - 211 encoding An IANA media type specifying a supported encoding format 213 3.3. Service Selection 215 Web Service Hosts that do not meet the requirements of the client 216 attempting to create a connection are eliminated before applying SRV 217 service selection criteria specified in [RFC2782] . 219 Clients SHOULD limit the number of connections attempted before 220 abandoning the attempt to connect. 222 3.4. Web Service Endpoint Determination 224 Having selected a Web Service Host, the client determines the Web 225 Service Endpoint as follows: 227 o If the description of the host specifies a path key, the 228 corresponding value is used as the path, otherwise, 230 o if the description of the service specifies a path key, the 231 corresponding value is used as the path, otherwise, 233 o the path is /.well-known/srv/ 235 3.5. DNS Fallback 237 Despite the fact that SRV records have been a part of the DNS 238 standard for 20 years, it is not uncommon for network intermediaries 239 to implement SRV record resolution incorrectly or block it entirely. 240 If no SRV record is found, a client MAY perform fallback discovery if 241 explicitly authorized to do so by the corresponding Web Service 242 protocol specification. 244 The Web Service Endpoint used is: 246 https://./.well-known/srv/ 248 Fallback discovery constrains the service provider to use a specific 249 DNS configuration and provides inferior load balancing or fault 250 tolerance capabilities to use of SRV records. It does however ensure 251 that the service is reachable in situations where it would otherwise 252 be unavailable. 254 3.6. Example 256 The Mathematical Mesh has the Well-Known Service name of 'MMM'. 257 Accounts used in the Mathematical Mesh follow the [RFC5322] format of 258 @. 260 Alice has the account alice@example.com and the DNS configuration 261 file for example.com has the following entries: 263 _mmm._tcp.example.com SRV host1.example.com 0 10 80 host1.example.com 264 _mmm._tcp.example.com SRV host2.example.com 0 40 80 host2.example.com 265 _mmm._tcp.example.com TXT "version=1.0-2.0" 266 mmm.example.com CNAME host3.example.com 267 host1.example.com A 10.0.1.1 268 host2.example.com A 10.0.1.2 269 _mmm._tcp.host2.example.com TXT "path=/service" 270 host3.example.com A 10.0.1.1 271 host3.example.com A 10.0.1.2 273 The client attempts to resolve the address alice@example.com as 274 follows: 276 1. Client attempts to resolve SRV and TXT records for 277 _mmm._tcp.example.com 279 2. DNS resolver returns two SRV entries and one TXT entry 281 3. Client makes a random selection between host1 (20% weighting) 282 and host2 (80% weighting). Chooses host1. 284 4. Client resolves A/AAAA for host1.example.com and TXT for 285 _mmm._tcp.host1.example.com 287 5. DNS resolver returns A=10.0.1.1 and TXT=none 289 6. Client attempts to POST Web Service request to 290 http://host1example.com/.well-known/srv/mmm at host address 291 10.0.1.1 293 7. The host at 10.0.1.1 returns 503 Service Unavailable 295 8. Client resolves A/AAAA for host2.example.com and TXT for 296 _mmm._tcp.host2.example.com 298 9. DNS resolver returns A=10.0.1.2 and TXT "path=/service" 300 10. Client attempts to POST Web Service request to 301 http://host2example.com/service at host address 10.0.1.2 303 11. Request succeeds, session proceeds. 305 If the same client is used in a network location where the SRV record 306 resolution fails due to a faulty firewall configuration, the 307 resolution proceeds as follows: 309 1. Client attempts to resolve SRV record for _mmm._tcp.example.com 311 2. DNS resolver returns 'not found' 313 3. Client attempts to resolve A and AAAA record 315 4. DNS resolver returns 10.0.1.1, 10.0.1.2 317 5. Client makes a random selection between 10.0.1.1 (50% weighting) 318 and 10.0.1.2 (50% weighting). Chooses host1. 320 6. Client attempts to POST Web Service request to 321 http://example.com/.well-known/srv/mmm at host address 10.0.1.1 323 7. The host at 10.0.1.1 returns 503 Service Unavailable 325 8. Client attempts to POST Web Service request to 326 http://example.com/.well-known/srv/mmm at host address 10.0.1.2 328 9. Request succeeds, session proceeds. 330 Note that the main differences between these two scenarios is that 331 the use of the SRV record allows the service configuration to account 332 for load balancing with tiers of fallback support and use of service 333 description information while the use of round robin A/AAAA records 334 does not. 336 4. Further Work 338 4.1. Additional Description Keys 340 The use of service and host descriptions to specify security 341 enhancements is currently being considered. This provides a superset 342 of the capabilities specified in [RFC6698] . 344 o Specify minimum TLS version. 346 o Specify trust roots more flexibly 348 o Specify client authentication requirements 350 o Use of security enhancements other than TLS. 352 o Publish public keys to be used to protect negotiation of security 353 enhancements 355 The use of service and host descriptions to specify use of non-HTTP 356 presentation transports is currently being considered. 358 4.2. Service Scaling 360 This document considers the problem of establishing a connection to a 361 Host providing a particular Web Service. When constructing services 362 at very large scale (e.g. millions of concurrent users), it becomes 363 desirable to enable discovery of a Web Service Host responsible for a 364 particular partition of that data (e.g. a particular user account). 366 Since this is clearly a different problem, it is judged that the best 367 approach is to give it a different name and rule it out of scope of 368 the present work. 370 5. Security Considerations 372 A treatment of the security considerations will follow. 374 6. IANA Considerations 376 The following registrations are required: 378 Well-Known URIs /.well-known/srv/ 380 [Or change registry to FCFS] 382 7. References 384 7.1. Normative References 386 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 387 specifying the location of services (DNS SRV)", RFC 2782, 388 DOI 10.17487/RFC2782, February 2000. 390 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 391 Resource Identifier (URI): Generic Syntax", STD 66, 392 RFC 3986, DOI 10.17487/RFC3986, January 2005. 394 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 395 Uniform Resource Identifiers (URIs)", RFC 5785, 396 DOI 10.17487/RFC5785, April 2010. 398 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 399 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013. 401 7.2. Informative References 403 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 404 DOI 10.17487/RFC5322, October 2008. 406 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 407 of Named Entities (DANE) Transport Layer Security (TLS) 408 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 409 2012. 411 7.3. URIs 413 [1] http://mathmesh.com/Documents/draft-hallambaker- web-service- 414 discovery.html 416 Author's Address 418 Phillip Hallam-Baker 420 Email: phill@hallambaker.com