Network Working Group G. Daley Internet-Draft NetStar Networks Intended status: Experimental R. Ng Expires: July 4, 2010 Thomas Duryea Consulting December 31, 2009 Use of DNS SRV records for host selection draft-daley-dnsext-host-srv-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 4, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Where multiple application servers are able to receive inbound connections from clients, it is desirable provide some policy control Daley & Ng Expires July 4, 2010 [Page 1] Internet-Draft SRV Records for Host selection December 2009 over client behaviour. This specification allows application service providers to provide addresses of multiple servers in response to DNS queries, while specifying failover and load balancing behaviours. Multiple servers are specified using existing protocol mechanisms for DNS Service records (SRV). An experimental record definition is described, which can be implemented on existing systems. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Host Service Records . . . . . . . . . . . . . . . . . . . . . 4 3.1. Target Address Lookups . . . . . . . . . . . . . . . . . . 5 4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Actions following resolution . . . . . . . . . . . . . . . 6 5. Example Records and Queries . . . . . . . . . . . . . . . . . 6 5.1. Example1: IPv4 Only Record . . . . . . . . . . . . . . . . 6 5.2. Example 2: IPv4/IPv6 Host records . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Comparison with Wildcards . . . . . . . . . . . . . . 11 Appendix B. Interactions with existing address lookups . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Daley & Ng Expires July 4, 2010 [Page 2] Internet-Draft SRV Records for Host selection December 2009 1. Introduction On the Internet today, domain name to IP address resolution is performed using the domain name system [RFC1034][RFC1035]. Currently, few applications are able to identify specific hosts as being more favoured targets for communication than another. DNS A and AAAA queries allow hostname to IP address lookups that are not order preserving, and client initiated communications may arrive on any of a set of addresses without any server side control [RFC1794]. One widely successful application which specifies preference order for inbound connections is SMTP [RFC5321]. SMTP makes use of the DNS MX record, which contains a preference value [RFC1035]. Similarly, DNS SRV records provide preference based specification of the availability of services within a domain [RFC2782]. While service records are defined for definition of operations for a particular protocol or application set in a zone, existing name system operation is target protocol agnostic, which allows for lookup of hosts for which no pre-defined protocol number or SRV service type exists. Additionally, where service provider's address preference policies are not based on the protocol level, but site or address-block, it makes sense to be able to determine address preferences in a general way, for all protocols associated with a fully qualified domainname. This document uses the inbuilt Priority and Weight mechanisms defined for SRV in order to control host target address selection for clients. The key words "MUST", "MUST NOT", "REQUIRED", "S.ALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Background In order to determine the applicability of service records for host lookup it is necessary to understand the behaviour of the existing Service Record behaviour. DNS SRV records are defined by their Protocol and Service names, and in addition to standard record fields contain attributes for Priority, Weight and Port. The response for a Service query includes a Target field which defines the canonical name of the device running a service: Daley & Ng Expires July 4, 2010 [Page 3] Internet-Draft SRV Records for Host selection December 2009 _Service._Proto.Name TTL Class SRV Priority Weight Port Target The Protocol field is typically bound to a transport layer such as TCP or UDP, but may be associated with an overlay protocol such as SIP [I-D.gudmundsson-dns-srv-iana-registry]. Symbolic names for Services are often based upon assigned names for application-layer protocols such as HTTP [RFC2616], but also encompasses subsets of operations within a protocol set such as presence, which resides within SIP/SIMPLE [RFC3856][RFC5509]. Examples of these records are shown below: _http._tcp.example.net IN SRV 10 10 80 www2.example.net _http._tcp.example.net IN SRV 5 10 80 www4.example.net _pres._sip.example.net IN SRV 10 10 5060 proxy1.example.net Figure 1: Service Record (SRV) Example Formats Definition of a new SRV record is required to outline the symbolic names in use for a service, and any security considerations which arise from its use [RFC2782]. This document follows the SRV guidelines to define a new Protocol field for SRV queries. This allows construction of new records without DNS server modification. Alternatives which achieve the same level of client control but may require protocol or record modification are discussed in Appendix B. 3. Host Service Records This document defines Host service records and their use in resolving destination addresses for preference and load balancing (weighting). Host service records allow recording of the host name portion of a fully qualified domain name, as a Service, within SRV records whose protocol is host resolution (represented as Protocol: _host). Wherever the protocol is received as _host, the service field represents the hostname portion of the fully qualified domain name: _._host[.] IN SRV 0 The component is of the format described for a