idnits 2.17.1 draft-hallambaker-web-service-discovery-02.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 (April 4, 2019) is 1846 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 437 == Missing Reference: 'RFC2119' is mentioned on line 144, 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 April 4, 2019 4 Intended status: Informational 5 Expires: October 6, 2019 7 DNS Web Service Discovery 8 draft-hallambaker-web-service-discovery-02 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 October 6, 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 6.1. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . 9 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 7.2. Informative References . . . . . . . . . . . . . . . . . 9 76 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 Web services are traditionally identified by means of a URI 82 specifying a Web Service Endpoint (WSE). This is approach is 83 unsatisfactory in many situations: 85 o Specification of the Web Service requires the transport and 86 presentation protocols to be fixed. 88 o The discovery mechanism does not provide support for load 89 balancing or fault tolerance. 91 o The identifiers are unsuited for human interaction. 93 The last consideration is a particular concern where an account 94 identifier is exposed to the user. Attempts to 'teach' users to use 95 URIs as account identifiers have been predictably unsuccessful. 97 Users expect and require accounts to be of the form user@example.com 98 and not http://service.example.com/service/user. 100 The Web Service discovery process described in this specification 101 builds on the approach specified in DNS-Based Service Discovery 102 [RFC6763] . This uses DNS SRV records as the basis for service 103 discovery and TXT records as the basis for service description. This 104 approach allows Web Services to make use of the load balancing and 105 fault tolerance features of SRV and the service negotiation 106 capabilities provided by the service description. 108 One difficulty that is frequently encountered in attempting to make 109 use of DNS records for service discovery is that it is not always 110 possible for an application process to access this information. 111 Specifications address the world as it actually is rather than as 112 some believe it should be have proven more robust in real world 113 deployment than those that do not. The discovery process defined 114 includes a fallback strategy to enable clients to achieve Web Service 115 discovery in these circumstances. 117 Another difficulty that is encountered is that the SRV record maps 118 service names to host names rather than Web Service Endpoints. A 119 convention is thus required to map a host name and protocol prefix to 120 a Web Service Endpoint. The HTTP Well Known Service [RFC5785] 121 mechanism is used for this purpose. 123 While the approach adopted in this specification closely follows that 124 of [RFC6763] , there is an important difference in that the earlier 125 specification sets out a framework which Web Services may apply to 126 develop a discovery approach that suits their particular needs while 127 this specification defines exactly one such approach. In particular, 128 the use of a common set of TXT keys to specify service parameters 129 enables service discovery and negotiation to be delegated to common 130 support libraries rather than being implemented independently in each 131 application. 133 2. Definitions 135 This section presents the related specifications and standard, the 136 terms that are used as terms of art within the documents and the 137 terms used as requirements language. 139 2.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 2.2. Defined Terms 147 Web Service An Internet service provided by one or more Web Service 148 Hosts that are addressable by a single Web Service Endpoint and 149 are intended to provide logically equivalent services. 151 Web Service Endpoint (WSE) A URI that specifies a Web Service or Web 152 Service Host. 154 Web Service Host The actual machine (physical or virtual) that 155 provides a Web Service 157 3. Service Discovery 159 Service discovery is the process of resolving the address of a Web 160 Service to a Web Service Endpoint, a URI [RFC3986] at which the 161 service is provided. 163 3.1. Host Identification 165 The first step in service discovery is to resolve the and 166 identifiers to the IP address of a host that provides that 167 service. 169 3.1.1. SRV Host discovery 171 A client attempting to connect to the service first attempts to 172 locate an SRV record [RFC2782] for the specified service: 174 _._tcp. SRV 176 Where is the IANA assigned service name, and 177 are the SRV priority and weight parameters specified in 178 [RFC2782] , is the TCP port number and is the DNS name 179 of the host for which the service advertisement is made. 181 If no SRV records are found, the client MAY abort the connection or 182 attempt use of the Fallback Discovery process described below. 184 3.2. Service Description 186 The second step in service discovery is to identify the attributes of 187 the Web Service and Web Service Hosts providing that service. 189 3.2.1. TXT Service and Host Description 191 A service MAY advertise service and/or host description information 192 using TXT records as described in DNS-Based Service Discovery 193 [RFC6763] . These have the following format: 195 _._tcp. TXT "= [=]*" 196 _._tcp. TXT "= [=]*" 198 Where and are the domain names specified in the 199 corresponding SRV records. 201 Service descriptions specified under the domain address of the 202 service apply to all host instances of the service. Descriptions 203 specified under the domain address of a host instance apply only to 204 that host instance and take precedence over values specified at the 205 service level. 207 The following keys are currently defined: 209 path The path to use to construct the Web Service Endpoint. 211 version The service version(s) supported in the format - 213 encoding An IANA media type specifying a supported encoding format 215 3.3. Service Selection 217 Web Service Hosts that do not meet the requirements of the client 218 attempting to create a connection are eliminated before applying SRV 219 service selection criteria specified in [RFC2782] . 221 Clients SHOULD limit the number of connections attempted before 222 abandoning the attempt to connect. 224 3.4. Web Service Endpoint Determination 226 Having selected a Web Service Host, the client determines the Web 227 Service Endpoint as follows: 229 o If the description of the host specifies a path key, the 230 corresponding value is used as the path, otherwise, 232 o if the description of the service specifies a path key, the 233 corresponding value is used as the path, otherwise, 235 o the path is /.well-known/srv/ 237 3.5. DNS Fallback 239 Despite the fact that SRV records have been a part of the DNS 240 standard for 20 years, it is not uncommon for network intermediaries 241 to implement SRV record resolution incorrectly or block it entirely. 242 If no SRV record is found, a client MAY perform fallback discovery if 243 explicitly authorized to do so by the corresponding Web Service 244 protocol specification. 246 The Web Service Endpoint used is: 248 https://./.well-known/srv/ 250 Fallback discovery constrains the service provider to use a specific 251 DNS configuration and provides inferior load balancing or fault 252 tolerance capabilities to use of SRV records. It does however ensure 253 that the service is reachable in situations where it would otherwise 254 be unavailable. 256 3.6. Example 258 The Mathematical Mesh has the Well-Known Service name of 'MMM'. 259 Accounts used in the Mathematical Mesh follow the [RFC5322] format of 260 @. 262 Alice has the account alice@example.com and the DNS configuration 263 file for example.com has the following entries: 265 _mmm._tcp.example.com SRV host1.example.com 0 10 80 host1.example.com 266 _mmm._tcp.example.com SRV host2.example.com 0 40 80 host2.example.com 267 _mmm._tcp.example.com TXT "version=1.0-2.0" 268 mmm.example.com CNAME host3.example.com 269 host1.example.com A 10.0.1.1 270 host2.example.com A 10.0.1.2 271 _mmm._tcp.host2.example.com TXT "path=/service" 272 host3.example.com A 10.0.1.1 273 host3.example.com A 10.0.1.2 275 The client attempts to resolve the address alice@example.com as 276 follows: 278 1. Client attempts to resolve SRV and TXT records for 279 _mmm._tcp.example.com 281 2. DNS resolver returns two SRV entries and one TXT entry 283 3. Client makes a random selection between host1 (20% weighting) 284 and host2 (80% weighting). Chooses host1. 286 4. Client resolves A/AAAA for host1.example.com and TXT for 287 _mmm._tcp.host1.example.com 289 5. DNS resolver returns A=10.0.1.1 and TXT=none 291 6. Client attempts to POST Web Service request to 292 http://host1example.com/.well-known/srv/mmm at host address 293 10.0.1.1 295 7. The host at 10.0.1.1 returns 503 Service Unavailable 297 8. Client resolves A/AAAA for host2.example.com and TXT for 298 _mmm._tcp.host2.example.com 300 9. DNS resolver returns A=10.0.1.2 and TXT "path=/service" 302 10. Client attempts to POST Web Service request to 303 http://host2example.com/service at host address 10.0.1.2 305 11. Request succeeds, session proceeds. 307 If the same client is used in a network location where the SRV record 308 resolution fails due to a faulty firewall configuration, the 309 resolution proceeds as follows: 311 1. Client attempts to resolve SRV record for _mmm._tcp.example.com 313 2. DNS resolver returns 'not found' 315 3. Client attempts to resolve A and AAAA record 317 4. DNS resolver returns 10.0.1.1, 10.0.1.2 319 5. Client makes a random selection between 10.0.1.1 (50% weighting) 320 and 10.0.1.2 (50% weighting). Chooses host1. 322 6. Client attempts to POST Web Service request to 323 http://example.com/.well-known/srv/mmm at host address 10.0.1.1 325 7. The host at 10.0.1.1 returns 503 Service Unavailable 327 8. Client attempts to POST Web Service request to 328 http://example.com/.well-known/srv/mmm at host address 10.0.1.2 330 9. Request succeeds, session proceeds. 332 Note that the main differences between these two scenarios is that 333 the use of the SRV record allows the service configuration to account 334 for load balancing with tiers of fallback support and use of service 335 description information while the use of round robin A/AAAA records 336 does not. 338 4. Further Work 340 4.1. Additional Description Keys 342 The use of service and host descriptions to specify security 343 enhancements is currently being considered. This provides a superset 344 of the capabilities specified in [RFC6698] . 346 o Specify minimum TLS version. 348 o Specify trust roots more flexibly 350 o Specify client authentication requirements 352 o Use of security enhancements other than TLS. 354 o Publish public keys to be used to protect negotiation of security 355 enhancements 357 The use of service and host descriptions to specify use of non-HTTP 358 presentation transports is currently being considered. 360 4.2. Service Scaling 362 This document considers the problem of establishing a connection to a 363 Host providing a particular Web Service. When constructing services 364 at very large scale (e.g. millions of concurrent users), it becomes 365 desirable to enable discovery of a Web Service Host responsible for a 366 particular partition of that data (e.g. a particular user account). 368 Since this is clearly a different problem, it is judged that the best 369 approach is to give it a different name and rule it out of scope of 370 the present work. 372 5. Security Considerations 374 A treatment of the security considerations will follow. 376 6. IANA Considerations 378 The following registrations are required: 380 6.1. Well-Known URIs 382 The following registration is requested in the well-known URI 383 registry in accordance with [RFC5785] 385 URI suffix 387 srv 389 Change controller 391 Phillip Hallam-Baker, phill@hallambaker.com 393 Specification document(s): 395 [This document] 397 Related information 399 [draft-hallambaker-web-service-discovery] 401 7. References 403 7.1. Normative References 405 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 406 specifying the location of services (DNS SRV)", RFC 2782, 407 DOI 10.17487/RFC2782, February 2000. 409 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 410 Resource Identifier (URI): Generic Syntax", STD 66, 411 RFC 3986, DOI 10.17487/RFC3986, January 2005. 413 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 414 Uniform Resource Identifiers (URIs)", RFC 5785, 415 DOI 10.17487/RFC5785, April 2010. 417 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 418 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013. 420 7.2. Informative References 422 [draft-hallambaker-web-service-discovery] 423 Hallam-Baker, P., "DNS Web Service Discovery", draft- 424 hallambaker-web-service-discovery-01 (work in progress), 425 February 2019. 427 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 428 DOI 10.17487/RFC5322, October 2008. 430 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 431 of Named Entities (DANE) Transport Layer Security (TLS) 432 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 433 2012. 435 7.3. URIs 437 [1] http://mathmesh.com/Documents/draft-hallambaker-web-service- 438 discovery.html 440 Author's Address 442 Phillip Hallam-Baker 444 Email: phill@hallambaker.com