One document matched: draft-daley-dnsext-host-srv-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:29:31 |