idnits 2.17.1 draft-edx-edge-exchanger-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 4, 2019) is 1576 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Sweta Jaiswal 3 Karthikeyan A. 4 Intended status: Standards Track Jamsheeed M. P. 5 Expires: April 25, 2020 Siva Sabareesh D. 6 Madhan Raj K. 7 December 4, 2019 9 EDX - Edge Exchanger 10 draft-edx-edge-exchanger-00 12 Abstract 14 This document describes a new DNS resource record (RR) type, called 15 the Edge Exchanger (EDX) RR, that is used to find services and 16 location of the server(s) for any specific domain (the word domain is 17 used here in the strict RFC1034 sense). 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Applicability Statement . . . . . . . . . . . . . . . . . . . . 3 53 3. EDX Resource Record Format . . . . . . . . . . . . . . . . . . 3 54 3.1. Example Data . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. EDX RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 56 4. Usage Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1. Query without knowing the service name . . . . . . . . . . 6 59 5.2. A new way to explore available services . . . . . . . . . . 6 60 5.3. Discover the edge servers . . . . . . . . . . . . . . . . . 7 61 5.4. A platform to advertise the available services . . . . . . 7 62 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 7.1. Attacker Tampering with an Insecure EDX RR . . . . . . . . 7 65 7.2. Response Data . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.3. Error Handling . . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 This document proposes a new Resource Record (RR) named Edge 75 Exchanger (EDX) for the Domain Name System (DNS) [RFC1034] and its 76 application usage. This document specifies how this DNS resource 77 record helps client in finding lowest latency servers and also 78 facilitate service discovery given the correct domain name. 80 Currently, the service discovery can be done using SRV resource 81 record type where the client requests for a specific service and 82 protocol for a domain name and receives the target host and port 83 where the service instance can be reached. To connect to the target 84 host client needs to perform DNS resolution to fetch the IP address. 85 Hence, we propose DNS EDX RR which provides a platform for clients to 86 discover the services available for a domain name with list of 87 primary IP address, running services and port information. 89 At present, there is no way to find all the services available in a 90 server using one DNS query. The new RR EDX allow servers to advertise 91 its services to all users as well as it enables client to find the 92 low latency edge servers for a service using the service and location 93 information. 95 Querying the EDX Resource Record does not mean replacement of SRV 97 [RFC2782] and LOC [RFC1876] Resource record. Instead, EDX RR provides 98 a complimentary mechanism to find the list of services as well as 99 location, port and IP address of the primary servers present for the 100 corresponding services for a domain, using just one query. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in BCP 14, RFC 2119 105 [RFC2119]. 107 2. Applicability Statement 109 In general, it is expected that EDX records will be used by clients 110 for applications to find the hosted services and locations for a 111 specific hostname. Clients pass a hostname with EDX Service Field and 112 get back the services, protocol and target names of all available 113 servers. One example is when an organization provides more than one 114 services running on multiple primary and backup servers but the 115 clients are unaware of these services. Clients can discover these set 116 of services using EDX RR type queries. 118 3. EDX Resource Record Format 120 The master file format of EDX RR type is defined below. 122 owner TTL Class EDX (Edge Port Lat Long Priority Version Address 123 _Service._Proto.Target-host) 125 ( The parentheses are used for multi-line data as specified in [RFC 126 1035] section 5.1. ) 128 Owner : The domain-name for which these RR refers to. 130 TTL : Standard DNS meaning [RFC1035]. 132 Class : Standard DNS meaning [RFC1035]. EDX records occur in 133 the IN Class. 135 Edge : A flag to set the target host as edge or remote server. 137 Service : The symbolic name of the services supported by the 138 owner. An underscore (_) is prepend to the service 139 identifier to avoid collisions with DNS labels that occur 140 in nature. Valid service parameters are those registered 141 by IANA in the "Service Name and Transport Protocol Port 142 Number Registry" as mentioned in [RFC6335]. The Service is 143 case insensitive. 145 Proto : The symbolic name of the protocol supported by target 146 host, with an underscore (_) prepend to prevent collisions 147 with DNS labels that occur in nature. Valid protocol 148 parameters are those registered by IANA in the "Service 149 Name and Transport Protocol Port Number Registry" as 150 mentioned in [RFC2782]. _TCP and _UDP are at present the 151 most useful values for this field, though any name defined 152 by Assigned Numbers or locally may be used (as for 153 Service). The Proto is case insensitive. 155 Target-host : The domain name of the target host. There MUST be one 156 or more address records for this name, the name MUST NOT 157 be an alias (in the sense of [RFC1034]). 159 Port : The port on this target host of this service. The range 160 is 0-65535. This is a 16 bit unsigned integer in network 161 byte order. This is often as specified in Assigned Numbers 162 but need not be. 164 Lat : The latitude of the center of the sphere described by 165 the SIZE field, expressed as a 32-bit integer, most 166 significant octet first (network standard byte order), in 167 thousandth of a second of arc. 2^31 represents the 168 equator; numbers above that are north latitude. 170 Long : The longitude of the center of the sphere described by 171 the SIZE field, expressed as a 32-bit integer, most 172 significant octet first (network standard byte order), in 173 thousandths of a second of arc, rounded away from the 174 prime meridian. 2^31 represents the prime meridian; 175 numbers above that are east longitude. 177 Priority : The priority of this target host. A client MUST attempt 178 to contact the target host with the lowest-numbered 179 priority it can reach; target hosts with the same priority 180 SHOULD be tried in an order defined by the weight field. 181 The range is 0-65535. This is a 16 bit unsigned integer in 182 network byte order. 184 Version : The Internet Protocol (IP) Version defines the type of 185 target host IP address. It MUST BE 4 for "A" [RFC1035] 186 type or 6 for "AAAA" [RFC3596] type. 188 Address : A 128 bit Internet address. The IP addresses may 189 belong to A [RFC1035] or AAAA [RFC3596] Resource Record 190 Sets. The IP address will range from 32 bit to 128 bit. 192 3.1. Example Data 193 ; 194 ; Please note that these data are fictional and not appear in any 195 ; zone file 196 ; EDX RR data are derived from SRV RR & ZIP data combined together 197 ; 199 $ORIGIN sribsamsung.example.com. 200 3600 IN EDX (0 389 23.000 32.000 2 4 198.51.100.110 201 _quic._tcp.sribsamsung.example.com.) 203 3600 IN EDX (0 80 23.000 32.000 4 6 204 2001:0db8:85a3:0000:0000:8a2e:0370:7334 205 _http._tcp.sribsamsung.example.com.) 207 3600 IN EDX (0 443 23.000 32.000 1 4 198.51.100.112 208 _https._tcp.sribsamsung.example.com.) 210 3.2. EDX RDATA Wire Format 212 The RDATA of EDX RR consist fixed length as well as variable length 213 parameters. 215 MSB LSB 216 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 217 | EDGE | 218 2 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 219 | PORT | 220 4 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 221 | LATITUDE | 222 6 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 223 | LONGITUDE | 224 8 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 225 | PRIORITY | 226 10 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 227 | IP VERSION | 228 12 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 229 | | 230 | IP ADDRESS | 231 | | 232 28 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 233 / / 234 / _service_proto.target / 235 / / 236 28+x +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 237 (octet) 239 Edge flag and Port are unsigned 16 bit integer. Edge Flag is 0 or 1 240 for remote server or edge server respectively, whereas the value of 241 port ranges from 0-65535. It is expressed in network byte order. 243 Latitude and Longitude are signed integers expressed in network byte 244 order. 246 Priority and IP Version are unsigned integers in network byte order. 248 IP Address can vary from 32 to 128 bit unsigned integer based on IP 249 Address Type "A" or "AAAA". 251 Finally, the RDATA consists of a variable length Target field which 252 consist of service, protocol and target name. The length of the 253 Target Field MUST be greater than zero. 255 4. Usage Rules 257 A EDX-cognizant client SHOULD use this procedure to discover the list 258 of services and the location of these servers: 260 Do a lookup for QNAME=domain-name, QTYPE=EDX. 262 5. Usage Scenarios 264 In this section, a number of scenarios showing the usage and 265 practical applications of EDX RR are explained briefly. 267 5.1. Query without knowing the service name 269 Client need not know the service name for querying the domain for any 270 service related information. The EDX resource record can be viewed as 271 a broader extension of SRV RR. Unlike SRV RR, where SHOULD know the 272 domain name, the service name and the protocol name, EDX RR can be 273 used without knowing the service name. Just the correct domain name 274 is enough to fetch the available services and its related 275 information. 277 5.2. A new way to explore available services 279 Client can now explore a domain for its available services. An 280 organization having specific domain name providing many services like 281 FTP archive, http and https services can be browsed by any client 282 knowing the domain name. For example, the organization with domain 283 name sribsamsung.example.com. can have these entries in DNS master 284 file. 286 $ORIGIN sribsamsung.example.com. 288 3600 IN EDX (0 21 23.000 32.000 4 4 198.51.100.113 289 _ftp._tcp.sribsamsung.example.com.) 291 3600 IN EDX (0 80 23.000 32.000 5 4 198.51.100.111 292 _http._tcp.sribsamsung.example.com.) 294 3600 IN EDX (0 443 23.000 32.000 3 4 198.51.100.112 295 _https._tcp.sribsamsung.example.com.) 297 These services provided by sribsamsung.example.com can be fetched 298 using just one DNS EDX RR query using the domain name and without 299 knowing all the services and protocols. With the EDX RR responses the 300 clients can use these available services. 302 The number of answers and its sequence in EDX RR MUST be based on 303 server Resource Record configuration and the maximum limit of 304 response data. This document does not specify any priority criteria, 305 based on service name or location information. 307 5.3. Discover the edge servers 309 Clients can use the edge flag and the location information of EDX 310 response to locate the low latency servers among all for any 311 services. 313 5.4. A platform to advertise the available services 315 This new EDX RR provides servers a platform to advertise their 316 services to clients by updating their running services and target 317 host information as EDX resource record. 318 6. IANA considerations 320 This RFC defines the format of a new Resource Record (RR) for the 321 Domain Name System (DNS), and reserves a corresponding DNS type 322 mnemonic (EDX) and numerical code (234) if accepted by IANA. IANA is 323 requested to assign a DNS RR data type value of 234 and DNS type 324 mnemonic EDX for this new DNS EDX RR. No other IANA services are 325 required by this document. 327 7. Security Considerations 329 This section contains a description of the known threats involved 330 with the usage of the DNS EDX RR. 332 7.1. Attacker Tampering with an Insecure EDX RR 334 With EDX, DNS spoofers can supply false port numbers, locations as 335 well as target names and addresses. Because this vulnerability exists 336 already, with names and addresses, this is not a new vulnerability, 337 merely a slightly extended one, with little practical effect. 339 To avoid the same, an EDX client SHOULD obtain EDX RRs from a trusted 340 party through a secure channel ensuring data integrity and 341 authenticity of the RRs. DNSSEC [RFC4033] [RFC4034] [RFC4035] 342 provides such a secure channel. However, it should be emphasized that 343 DNSSEC only offers data integrity and authenticity guarantees to the 344 channel between the DNS server publishing a zone and the HIP node. 345 DNSSEC does not ensure that the entity publishing the zone is 346 trusted. 348 7.2. Response Data 350 In the absence of secure channel, the Authoritative DNS servers MAY 351 validate the client IP Address. An Authoritative DNS server MAY 352 prevent returning EDX records over UDP unless the source IP address 353 has been confirmed with DNS Cookies. If a query is received via UDP 354 without source IP address verification, the server MUST NOT return 355 REFUSED but answer the query with an empty answer section and the 356 truncation flag set ("TC=1"). 358 7.3. Error Handling 360 It is also possible that the EDX in the resource record type has 361 errors in it. Applications using the EDX resource record type for 362 resolution SHOULD behave similarly as if the user typed the correct 363 domain name without any resource records. At least it must be clear 364 to the user that the error is not due to any error from his side. 366 8. References 368 8.1. Normative References 370 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 371 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 372 . 374 [RFC1035] Mockapetris, P., "Domain names - implementation and 375 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 376 November 1987, . 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, DOI 380 10.17487/RFC2119, March 1997, . 383 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 384 specifying the location of services (DNS SRV)", RFC 2782, 385 DOI 10.17487/RFC2782, February 2000, . 388 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 389 "DNS Extensions to Support IP Version 6", RFC 3596, DOI 390 10.17487/RFC3596, October 2003, . 393 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 394 Rose, "DNS Security Introduction and Requirements", 395 RFC 4033, DOI 10.17487/RFC4033, March 2005, 396 . 398 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 399 Rose, "Resource Records for the DNS Security Extensions", 400 RFC 4034, DOI 10.17487/RFC4034, March 2005, 401 . 403 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 404 Rose, "Protocol Modifications for the DNS Security 405 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 406 . 408 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 409 Cheshire, "Internet Assigned Numbers Authority (IANA) 410 Procedures for the Management of the Service Name and 411 Transport Protocol Port Number Registry", BCP 165, 412 RFC 6335, DOI 10.17487/RFC6335, August 2011, 413 . 415 8.2. Informative References 417 [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A 418 Means for Expressing Location Information in the Domain 419 Name System", RFC 1876, DOI 10.17487/RFC1876, January 420 1996, . 422 Author's Addresses 424 Sweta Jaiswal 425 Samsung R&D Institute India - Bangalore 426 Karnataka - 560037 427 India. 428 Email: sweta.j@samsung.com 430 Karthikeyan Arunachalam 431 Samsung R&D Institute India - Bangalore 432 Karnataka - 560037 433 India. 434 Email: karthikeya.a@samsung.com 436 Jamsheed Manja Ppallan 437 Samsung R&D Institute India - Bangalore 438 Karnataka - 560037 439 India. 440 Email: jamsheed.mp@samsung.com 442 Dronamraju Siva Sabareesh 443 Samsung R&D Institute India - Bangalore 444 Karnataka - 560037 445 India. 446 Email: s.sabareesh@samsung.com 448 Madhan Raj Kanagarathinam 449 Samsung R&D Institute India - Bangalore 450 Karnataka - 560037 451 India. 452 Email: madhan.raj@samsung.com