Internet Draft Sweta Jaiswal Karthikeyan A. Intended status: Standards Track Jamsheeed M. P. Expires: April 25, 2020 Siva Sabareesh D. Madhan Raj K. December 4, 2019 EDX - Edge Exchanger draft-edx-edge-exchanger-00 Abstract This document describes a new DNS resource record (RR) type, called the Edge Exchanger (EDX) RR, that is used to find services and location of the server(s) for any specific domain (the word domain is used here in the strict RFC1034 sense). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." Copyright Notice Copyright (c) 2019 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Expires June 6, 2020 [Page 1] Internet Draft December 04, 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Applicability Statement . . . . . . . . . . . . . . . . . . . . 3 3. EDX Resource Record Format . . . . . . . . . . . . . . . . . . 3 3.1. Example Data . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. EDX RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 4. Usage Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Query without knowing the service name . . . . . . . . . . 6 5.2. A new way to explore available services . . . . . . . . . . 6 5.3. Discover the edge servers . . . . . . . . . . . . . . . . . 7 5.4. A platform to advertise the available services . . . . . . 7 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7.1. Attacker Tampering with an Insecure EDX RR . . . . . . . . 7 7.2. Response Data . . . . . . . . . . . . . . . . . . . . . . . 8 7.3. Error Handling . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction This document proposes a new Resource Record (RR) named Edge Exchanger (EDX) for the Domain Name System (DNS) [RFC1034] and its application usage. This document specifies how this DNS resource record helps client in finding lowest latency servers and also facilitate service discovery given the correct domain name. Currently, the service discovery can be done using SRV resource record type where the client requests for a specific service and protocol for a domain name and receives the target host and port where the service instance can be reached. To connect to the target host client needs to perform DNS resolution to fetch the IP address. Hence, we propose DNS EDX RR which provides a platform for clients to discover the services available for a domain name with list of primary IP address, running services and port information. At present, there is no way to find all the services available in a server using one DNS query. The new RR EDX allow servers to advertise its services to all users as well as it enables client to find the low latency edge servers for a service using the service and location information. Querying the EDX Resource Record does not mean replacement of SRV Expires June 6, 2020 [Page 2] Internet Draft December 04, 2019 [RFC2782] and LOC [RFC1876] Resource record. Instead, EDX RR provides a complimentary mechanism to find the list of services as well as location, port and IP address of the primary servers present for the corresponding services for a domain, using just one query. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Applicability Statement In general, it is expected that EDX records will be used by clients for applications to find the hosted services and locations for a specific hostname. Clients pass a hostname with EDX Service Field and get back the services, protocol and target names of all available servers. One example is when an organization provides more than one services running on multiple primary and backup servers but the clients are unaware of these services. Clients can discover these set of services using EDX RR type queries. 3. EDX Resource Record Format The master file format of EDX RR type is defined below. owner TTL Class EDX (Edge Port Lat Long Priority Version Address _Service._Proto.Target-host) ( The parentheses are used for multi-line data as specified in [RFC 1035] section 5.1. ) Owner : The domain-name for which these RR refers to. TTL : Standard DNS meaning [RFC1035]. Class : Standard DNS meaning [RFC1035]. EDX records occur in the IN Class. Edge : A flag to set the target host as edge or remote server. Service : The symbolic name of the services supported by the owner. An underscore (_) is prepend to the service identifier to avoid collisions with DNS labels that occur in nature. Valid service parameters are those registered by IANA in the "Service Name and Transport Protocol Port Number Registry" as mentioned in [RFC6335]. The Service is case insensitive. Expires June 6, 2020 [Page 3] Internet Draft December 04, 2019 Proto : The symbolic name of the protocol supported by target host, with an underscore (_) prepend to prevent collisions with DNS labels that occur in nature. Valid protocol parameters are those registered by IANA in the "Service Name and Transport Protocol Port Number Registry" as mentioned in [RFC2782]. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Proto is case insensitive. Target-host : The domain name of the target host. There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of [RFC1034]). Port : The port on this target host of this service. The range is 0-65535. This is a 16 bit unsigned integer in network byte order. This is often as specified in Assigned Numbers but need not be. Lat : The latitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandth of a second of arc. 2^31 represents the equator; numbers above that are north latitude. Long : The longitude of the center of the sphere described by the SIZE field, expressed as a 32-bit integer, most significant octet first (network standard byte order), in thousandths of a second of arc, rounded away from the prime meridian. 2^31 represents the prime meridian; numbers above that are east longitude. Priority : The priority of this target host. A client MUST attempt to contact the target host with the lowest-numbered priority it can reach; target hosts with the same priority SHOULD be tried in an order defined by the weight field. The range is 0-65535. This is a 16 bit unsigned integer in network byte order. Version : The Internet Protocol (IP) Version defines the type of target host IP address. It MUST BE 4 for "A" [RFC1035] type or 6 for "AAAA" [RFC3596] type. Address : A 128 bit Internet address. The IP addresses may belong to A [RFC1035] or AAAA [RFC3596] Resource Record Sets. The IP address will range from 32 bit to 128 bit. 3.1. Example Data Expires June 6, 2020 [Page 4] Internet Draft December 04, 2019 ; ; Please note that these data are fictional and not appear in any ; zone file ; EDX RR data are derived from SRV RR & ZIP data combined together ; $ORIGIN sribsamsung.example.com. 3600 IN EDX (0 389 23.000 32.000 2 4 198.51.100.110 _quic._tcp.sribsamsung.example.com.) 3600 IN EDX (0 80 23.000 32.000 4 6 2001:0db8:85a3:0000:0000:8a2e:0370:7334 _http._tcp.sribsamsung.example.com.) 3600 IN EDX (0 443 23.000 32.000 1 4 198.51.100.112 _https._tcp.sribsamsung.example.com.) 3.2. EDX RDATA Wire Format The RDATA of EDX RR consist fixed length as well as variable length parameters. MSB LSB 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | EDGE | 2 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PORT | 4 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | LATITUDE | 6 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | LONGITUDE | 8 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PRIORITY | 10 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | IP VERSION | 12 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | IP ADDRESS | | | 28 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / / / _service_proto.target / / / 28+x +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ (octet) Edge flag and Port are unsigned 16 bit integer. Edge Flag is 0 or 1 Expires June 6, 2020 [Page 5] Internet Draft December 04, 2019 for remote server or edge server respectively, whereas the value of port ranges from 0-65535. It is expressed in network byte order. Latitude and Longitude are signed integers expressed in network byte order. Priority and IP Version are unsigned integers in network byte order. IP Address can vary from 32 to 128 bit unsigned integer based on IP Address Type "A" or "AAAA". Finally, the RDATA consists of a variable length Target field which consist of service, protocol and target name. The length of the Target Field MUST be greater than zero. 4. Usage Rules A EDX-cognizant client SHOULD use this procedure to discover the list of services and the location of these servers: Do a lookup for QNAME=domain-name, QTYPE=EDX. 5. Usage Scenarios In this section, a number of scenarios showing the usage and practical applications of EDX RR are explained briefly. 5.1. Query without knowing the service name Client need not know the service name for querying the domain for any service related information. The EDX resource record can be viewed as a broader extension of SRV RR. Unlike SRV RR, where SHOULD know the domain name, the service name and the protocol name, EDX RR can be used without knowing the service name. Just the correct domain name is enough to fetch the available services and its related information. 5.2. A new way to explore available services Client can now explore a domain for its available services. An organization having specific domain name providing many services like FTP archive, http and https services can be browsed by any client knowing the domain name. For example, the organization with domain name sribsamsung.example.com. can have these entries in DNS master file. $ORIGIN sribsamsung.example.com. Expires June 6, 2020 [Page 6] Internet Draft December 04, 2019 3600 IN EDX (0 21 23.000 32.000 4 4 198.51.100.113 _ftp._tcp.sribsamsung.example.com.) 3600 IN EDX (0 80 23.000 32.000 5 4 198.51.100.111 _http._tcp.sribsamsung.example.com.) 3600 IN EDX (0 443 23.000 32.000 3 4 198.51.100.112 _https._tcp.sribsamsung.example.com.) These services provided by sribsamsung.example.com can be fetched using just one DNS EDX RR query using the domain name and without knowing all the services and protocols. With the EDX RR responses the clients can use these available services. The number of answers and its sequence in EDX RR MUST be based on server Resource Record configuration and the maximum limit of response data. This document does not specify any priority criteria, based on service name or location information. 5.3. Discover the edge servers Clients can use the edge flag and the location information of EDX response to locate the low latency servers among all for any services. 5.4. A platform to advertise the available services This new EDX RR provides servers a platform to advertise their services to clients by updating their running services and target host information as EDX resource record. 6. IANA considerations This RFC defines the format of a new Resource Record (RR) for the Domain Name System (DNS), and reserves a corresponding DNS type mnemonic (EDX) and numerical code (234) if accepted by IANA. IANA is requested to assign a DNS RR data type value of 234 and DNS type mnemonic EDX for this new DNS EDX RR. No other IANA services are required by this document. 7. Security Considerations This section contains a description of the known threats involved with the usage of the DNS EDX RR. 7.1. Attacker Tampering with an Insecure EDX RR With EDX, DNS spoofers can supply false port numbers, locations as well as target names and addresses. Because this vulnerability exists Expires June 6, 2020 [Page 7] Internet Draft December 04, 2019 already, with names and addresses, this is not a new vulnerability, merely a slightly extended one, with little practical effect. To avoid the same, an EDX client SHOULD obtain EDX RRs from a trusted party through a secure channel ensuring data integrity and authenticity of the RRs. DNSSEC [RFC4033] [RFC4034] [RFC4035] provides such a secure channel. However, it should be emphasized that DNSSEC only offers data integrity and authenticity guarantees to the channel between the DNS server publishing a zone and the HIP node. DNSSEC does not ensure that the entity publishing the zone is trusted. 7.2. Response Data In the absence of secure channel, the Authoritative DNS servers MAY validate the client IP Address. An Authoritative DNS server MAY prevent returning EDX records over UDP unless the source IP address has been confirmed with DNS Cookies. If a query is received via UDP without source IP address verification, the server MUST NOT return REFUSED but answer the query with an empty answer section and the truncation flag set ("TC=1"). 7.3. Error Handling It is also possible that the EDX in the resource record type has errors in it. Applications using the EDX resource record type for resolution SHOULD behave similarly as if the user typed the correct domain name without any resource records. At least it must be clear to the user that the error is not due to any error from his side. 8. References 8.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Expires June 6, 2020 [Page 8] Internet Draft December 04, 2019 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, DOI 10.17487/RFC3596, October 2003, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . 8.2. Informative References [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC 1876, DOI 10.17487/RFC1876, January 1996, . Author's Addresses Sweta Jaiswal Samsung R&D Institute India - Bangalore Expires June 6, 2020 [Page 9] Internet Draft December 04, 2019 Karnataka - 560037 India. Email: sweta.j@samsung.com Karthikeyan Arunachalam Samsung R&D Institute India - Bangalore Karnataka - 560037 India. Email: karthikeya.a@samsung.com Jamsheed Manja Ppallan Samsung R&D Institute India - Bangalore Karnataka - 560037 India. Email: jamsheed.mp@samsung.com Dronamraju Siva Sabareesh Samsung R&D Institute India - Bangalore Karnataka - 560037 India. Email: s.sabareesh@samsung.com Madhan Raj Kanagarathinam Samsung R&D Institute India - Bangalore Karnataka - 560037 India. Email: madhan.raj@samsung.com Expires June 6, 2020 [Page 10]