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:

   _<hostname>._host[.<domain>] <TTL> IN SRV <Prio> <Weight> 0 <Target>

   The <hostname> component is of the format described for a <label> in
   section 2.3.1 of [RFC1035].  Where the domain is example.com,
   resolution for the addresses of server.example.org could perform an
   SRV lookup for the record "_server._host.example.org".




Daley & Ng                Expires July 4, 2010                  [Page 4]

Internet-Draft       SRV Records for Host selection        December 2009


   Returned records detailing host specification SHOULD have the Port
   field set to 0, as shown above.  This is because the lookup is for
   general host resolution, rather than a particular application
   service.

   In order to ensure that devices are able to resolve addresses without
   the host SRV record, address lookup records (e.g.  A or AAAA) SHOULD
   be installed for the domain name.  The Target field in the host SRV
   field can be different to that in the address lookup record.

   Where specific services at a host are required, standard SRV syntax
   may used instead.  For example, to select WWW services, it may be
   possible to create a request for "_http._tcp.server.example.org",
   rather than "_server._host.example.org" [RFC2782].

3.1.  Target Address Lookups

   Responses to the host SRV lookup contain Target fields which may be
   resolvable locally (for example if the Name Server was
   authoritative).  As described in [RFC2782] these records will be
   placed within the response.  Where these Targets cannot be resolved,
   additional address lookup queries (A or AAAA) will be required.


4.  Client Behaviour

   Clients wishing to use Priority and Weight information to determine
   connectivity can use the _host record query, as a first query for a
   host, where specific SRV service queries are not required.

   In order to resolve a host's address, the domain name is separated
   into the components <hostname>.<domain>, where <hostname> is the
   component of the domain name preceding the first "." character and
   <domain> contains the remaining portion of the domain name (if
   required).

   The client sends a query containing the following parameters:

       QTYPE=SRV,
       QCLASS=IN,
       QNAME=_<hostname>._host[.<domain>]

   Should there be a negative response for this query, the client SHOULD
   fall back to AAAA or A for the original domain name, as described by
   local address selection policy.

   Where a client requires service resolution on a host, it performs
   standard SRV resolution, with the service and protocol defined before



Daley & Ng                Expires July 4, 2010                  [Page 5]

Internet-Draft       SRV Records for Host selection        December 2009


   the standard hostname, as described in [RFC2782].  However if it is
   not possible to find a response for articular service, the client MAY
   fall back to host SRV resolution prior to AAAA or A name lookup.

4.1.  Actions following resolution

   Where performed, successful service specific record discovery SHOULD
   always be preferred to host SRV resolution, but where service
   specific connectivity is unreachable, _host records MAY be used once
   specific service records are exhausted.

   When the client has resolved the host SRV record, and determined name
   lookups for the target addresses, the client SHOULD attempt to
   connect to services on the machine, with the lowest Priority value.
   Where name lookup for a Target is not possible, the address family
   (e.g.  IPv4) of the destination is not suitable, or lower Priority
   valued servers are not reachable, these destinations may be
   discounted from destination selection, and the destination selection
   mechanism can proceed according to the algorithm presented in
   [RFC2782] with the remaining entries.

   Note though that host SRV entries do not provide Port resolution (all
   responses contain Port=0), and destination port numbers are required
   to be determined either by use of well known service numbers or by
   prior configuration.


5.  Example Records and Queries

   During initial investigation a number of records were constructed on
   Windows Server 2008's DNS Service.  These records have been
   transliterated to reflect reserved documentation prefixes and domain
   names [RFC2606][RFC3330][RFC3849].

   Please note that Time To Live (TTL) values have been omitted for
   clarity in record entries [RFC1035].

5.1.  Example1: IPv4 Only Record

   The following example illustrates a host record with only IPv4
   bindings.  The records below show host SRV entries, the address
   lookup records for the Targets, and the fallback A record for the
   host:








Daley & Ng                Expires July 4, 2010                  [Page 6]

Internet-Draft       SRV Records for Host selection        December 2009


   _hostname1._host.example.com IN SRV 10 10 0 stream2.au.example.com
   _hostname1._host.example.com IN SRV 10 10 0 stream1.au.example.com

   hostname1.example.com        IN A   192.0.2.10

   stream2.au.example.com       IN A   192.0.2.90
   stream1.au.example.com       IN A   192.0.2.91

                     Figure 2: Example 1 - DNS Records

   As described in Section 4, an initial query for SRV or ANY
   (QTYPE=255)


   >set type=any

   > _hostname1._host.example.com
   Server:  [192.0.2.1]
   Address:  192.0.2.1
   DNS request timed out.
       timeout was 2 seconds.
   _hostname1._host.example.com      SRV service location:
             priority       = 10
             weight         = 10
             port           = 0
             svr hostname   = stream2.au.example.com
   _hostname1._host.example.com      SRV service location:
             priority       = 10
             weight         = 10
             port           = 0
             svr hostname   = stream1.au.example.com
   stream2.au.example.com   internet address = 192.0.2.90
   stream1.au.example.com   internet address = 192.0.2.91

                  Figure 3: Example 1 - Client Behaviour

   A system which doesn't support the host SRV records may still be
   serviced by name lookup queries as shown in Figure 4.

   > hostname1.example.com
   Server:  [192.0.2.1]
   Address:  192.0.2.1
   DNS request timed out.
       timeout was 2 seconds.
   hostname1.example.com    internet address = 192.0.2.10
   >

                 Figure 4: Example 1 - Address Lookup only



Daley & Ng                Expires July 4, 2010                  [Page 7]

Internet-Draft       SRV Records for Host selection        December 2009


5.2.  Example 2: IPv4/IPv6 Host records

   This example illustrates responses when responses arrive with Targets
   that resolve in different address families.  Until the resolution is
   performed, the recipient is unaware what protocol a device is hosted
   at.

   The records in this zone identify that the most preferred server is
   only reachable via IPv6.


   _ares2._host.example.com IN SRV  10 10 80 serve.example.com
   _ares2._host.example.com IN SRV  5  5  80 serv2.example.com

   serve.example.com        IN A    192.0.2.12
   serv2.example.com        IN AAAA 2001:DB8:100:344:216:aff:fee1:97df

                     Figure 5: Example 2 - DNS Records

   For a client which receives these specifications, it SHOULD attempt
   to contact the IPv6 host, unless it is unable to create connections
   which match the scope of the IPv6 address [RFC4291].


> _ares2._host.ares2.example.com
Server:  [192.0.2.1]
Address:  192.0.2.1
DNS request timed out.
    timeout was 2 seconds.
_ares2._host.example.com   SRV service location:
          priority       = 10
          weight         = 10
          port           = 80
          svr hostname   = serve.example.com
_ares2._host.example.com   SRV service location:
          priority       = 5
          weight         = 5
          port           = 80
          svr hostname   = serv2.example.com
serve.example.com  internet address = 192.0.2.12
serv2.example.com  AAAA address     = 2001:DB8:100:344:216:aff:fee1:97df

             Figure 6: Example 2 - Client Behaviour Host Query

   Similarly, were the Priority and Weight to favour IPv4 destinations,
   communications should be attempted given that appropriate IP
   addresses are available on the client [RFC3927].




Daley & Ng                Expires July 4, 2010                  [Page 8]

Internet-Draft       SRV Records for Host selection        December 2009


6.  IANA Considerations

   There are currently efforts to create a registry for DNS SRV entries
   [I-D.gudmundsson-dns-srv-iana-registry].  In order to specify the
   _host SRV protocol and its behaviour, this registry would need to be
   updated.


7.  Security Considerations

   Use of host SRV records can cause additional DNS requests to be made,
   which can cause additional pressure on a zone's DNS server.
   References to a domain name on an Internet site could then cause
   domain name lookups for the host SRV record, as well as for the A or
   AAAA records, even where no _host record entries are defined for a
   zone.  This can lead to a two fold increase in inbound DNS queries to
   a server.

   Fake DNS SRV records can be used to control access to particular host
   or service.  This is different to AAAA and A records only in that an
   entry can be forced to be tried first, using the Priority value in
   the SRV record.  Existing security mechanisms which verify the
   authenticity of DNS records can be deployed to ensure record origin
   authenticity.


8.  Acknowledgments

   Brian Carpenter suggested Greg pursue DNS records with strict
   preference in a discussion on IPv6 multihoming.


9.  References

9.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,



Daley & Ng                Expires July 4, 2010                  [Page 9]

Internet-Draft       SRV Records for Host selection        December 2009


              May 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

9.2.  Informative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1794]  Brisco, T., "DNS Support for Load Balancing", RFC 1794,
              April 1995.

   [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
              Names", BCP 32, RFC 2606, June 1999.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3330]  IANA, "Special-Use IPv4 Addresses", RFC 3330,
              September 2002.

   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
              Reserved for Documentation", RFC 3849, July 2004.

   [RFC3856]  Rosenberg, J., "A Presence Event Package for the Session
              Initiation Protocol (SIP)", RFC 3856, August 2004.

   [RFC4472]  Durand, A., Ihren, J., and P. Savola, "Operational
              Considerations and Issues with IPv6 DNS", RFC 4472,
              April 2006.

   [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
              System", RFC 4592, July 2006.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5509]  Loreto, S., "Internet Assigned Numbers Authority (IANA)
              Registration of Instant Messaging and Presence DNS SRV RRs
              for the Session Initiation Protocol (SIP)", RFC 5509,
              April 2009.

   [I-D.gudmundsson-dns-srv-iana-registry]
              Gudmundsson, O. and A. Hoenes, "Creation of a Registry for
              DNS SRV Record Service Prefixes",
              draft-gudmundsson-dns-srv-iana-registry-04 (work in



Daley & Ng                Expires July 4, 2010                 [Page 10]

Internet-Draft       SRV Records for Host selection        December 2009


              progress), October 2009.


Appendix A.  Comparison with Wildcards

   Wildcard records are described in [RFC4592], which updates their
   specification in [RFC1035].  These records have an asterisk as a
   label, and will match any record subordinate to them which is not
   covered by a more specific record.

   As described in [RFC4592] wildcard records for SRV records within a
   domain, or for a host may exist.  A query for
   _http._tcp.hostname1.example will succeed where following wildcard
   record exists:

   *.hostname1.example.  IN SRV 23 10 80 www1.example.

   As the Port specification exists within the SRV entry, it will match
   even inappropriate entries, such as if QNAME=_ldap._tcp.example.com.
   Such behaviour is clearly erroneous, and correction would either
   require specification of a zero port number in wildcard responses
   (requiring client changes), or of service to port number lookup on
   the DNS server (requiring server changes).

   Neither of these options is palatable.  As such, investigation of a
   separate naming convention (rather than wildcard matching any SRV
   entry) is sought.

   Even if such solutions were available, allocation of SRC Service
   types is strictly controlled [RFC2782].  Where no allocation of a
   Service type has been performed (for example with a new protocol),
   inbound communications could not use a Service specific query to
   perform lookups.


Appendix B.  Interactions with existing address lookups

   With traditional forward name resolution, clients query using either
   A (IPv4) or AAAA (IPv6) address lookup.  For a host with connectivity
   only via one IP protocol, this query (or a retransmission) will
   determine whether or not a useful address record exists.

   Where both protocols are available, it is not reliable to perform an
   ANY (QTYPE=255) query as these responses may fail to carry responses
   for all QTYPEs if intermediate caches have incomplete information.

   When considering the deployment model for _host SRV records, it is
   useful to consider what happens if only the basic address record



Daley & Ng                Expires July 4, 2010                 [Page 11]

Internet-Draft       SRV Records for Host selection        December 2009


   exists.  Since the name presented in the _host record is
   syntactically different to the query name for A and AAAA, an ANY (or
   SRV) query will not succeed nor will basic queries for host addresses
   at the same string.

   In the case the _host SRV record doesn't exist and is requested
   first, a response can be expected indicating this.  Where the first
   transmission provides this Negative Acknowledgement, there is a delay
   of a round-trip (perhaps 3-500ms in some environments).  Subsequent
   queries will determine if an address record exists.

   As such, the base case is where no _host SRV records exist in the
   Internet, and all records are either AAAA or A, then clients
   configured to use host SRV records will take twice as long and use
   twice as many messages to perform lookups.  Where all servers on the
   Internet have _host SRV records, devices will have a single query to
   resolve hosts to Target hostnames.  This response will also contain
   resolved IP addresses, if the DNS server is able to provide A or AAAA
   records for Targets mentioned by SRV.

   A protocol and record modifying alternative is to adapt RFC2782 SRV
   records to be sent without defining a service and protocol.  This
   would allow the same QNAME to be set as for SRV and A/AAAA queries,
   allowing an ANY query to operate on the same records.  If this were
   possible, records would be structured as follows:


   hostname1.example.com  IN SRV 10 10 0 stream2.au.example.com
   hostname1.example.com  IN SRV 10 10 0 stream1.au.example.com

   hostname1.example.com  IN A   192.0.2.10

   stream2.au.example.com IN A   192.0.2.90
   stream1.au.example.com IN A   192.0.2.91

      Figure 7: Uniform version of Host Service Record (SRV) Example

   In that responses to ANY queries may omit QTYPES, based on
   intermediate cache state, individual queries for SRV, AAAA and A
   would be more appropriate.

   Where modification of the SRV record is not viable, creation of a new
   query type with the same Weight and Priority behaviour could be
   defined.  In each case (uniform host SRV records and a new type),
   modification of DNS servers and clients would be required.






Daley & Ng                Expires July 4, 2010                 [Page 12]

Internet-Draft       SRV Records for Host selection        December 2009


Authors' Addresses

   Greg Daley
   NetStar Australia Pty Ltd
   Lvl 9/636 St Kilda Rd
   Melbourne, Victoria  3004
   Australia

   Phone: +61 401 772 770
   Email: gdaley@netstarnetworks.com


   Raymond Ng
   Thomas Duryea Consulting
   79-81 Coppin St
   Richmond, VIC 3121
   Australia

   Email: rng@td.com.au
































Daley & Ng                Expires July 4, 2010                 [Page 13]