Internet DRAFT - draft-ohta-urlsrv
draft-ohta-urlsrv
INTERNET DRAFT M. Ohta
draft-ohta-urlsrv-00.txt Tokyo Institute of Technology
Intended status: Informational September 29, 2011
Expires: March 29, 2012
Using DNS SRV RRs with URLs
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 http://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) 2011 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.
Abstract
DNS SRV RRs of a domain implicitly specify servers and port numbers
corresponding to the domain.
By combining URLs and SRV RRs, no port numbers have to be specified
explicitly in URLs, even if non-default port numbers are used, which
makes URLs more concise for port based virtual and real hosting,
where port based real hosting means that multiple servers sharing an
IP address are distinguished by port numbers to give service for
different URLs, which is the case for port forwarded servers behind
M. Ohta Expires on March 29, 2012 [Page 1]
INTERNET DRAFT Using DNS SRV RRs with URLs September 2011
NAT and servers with realm specific IP.
1. Introduction
This memo specifies informative guidelines on how to use DNS SRV RRs
[SRV] with URLs [URI].
Without explicitly specifying port numbers in URLs, SRV RR is useful
to map a <reg-name> to IP addresses and port numbers of one or more
servers, which can make URLs more concise for port based virtual and
real hosting, where port based real hosting means that multiple
servers sharing an IP address are distinguished by port numbers to
give service for different URLs, which is the case for port forwarded
servers behind NAT [NAT] and servers with realm specific IP [RSIP].
For SRV RRs usable for a URL, the URL must include <reg-name>, a
domain name, that is, have the following syntax [URI]:
<scheme>://[<userinfo>@]<reg-name>[:<port0>]<path>[?<query>]
It is also required that <reg-name> corresponds to a DNS hostname:
<hostname>.
The URL means a client and a <server> communicate over a protocol
named <proto> using a single port number. In this memo, it is assumed
that the client can deduce one or more <proto> from <scheme>.
<proto> and <scheme> may be defined globally in Assigned Numbers or
locally at <hostname> [SRV].
2. SRV Look Up
First, SRV RRs of a DNS node, _<scheme>._<proto>.<hostname>, is
looked up.
If the node does not have any SRV RR, DNS derived address(es) of
<hostname> is the address(es) of the server and <port0> (or default
port of <scheme>) is the port number to be used.
Otherwise, if the node has at least one SRV RR [SRV]:
_<scheme>._<proto>.<hostname> SRV <priority> <weight>
<port1> <target>
<target> is the server to be used by the client. If there are
multiple SRV RRs of the node, multiple <target>s are contacted in the
order described by [SRV].
M. Ohta Expires on March 29, 2012 [Page 2]
INTERNET DRAFT Using DNS SRV RRs with URLs September 2011
If there are multiple <proto> names corresponding to <scheme>, all
the SRV RRs for all the <proto> names are looked up and they are
mixed together and tried in the order described by [SRV] as if all
the RRs are located in a single domain. Note that the ordering rule
in [SRV] is preserved between SRV RRs with same <proto>, even after
mixing.
If <port0> exists, <port0>+<port1> (with 16bit arithmetic) is the
port number to be used. The reason of addition is that, if <port0> is
explicitly specified, there is no reason to ignore it, but SRV RRs
assumes all the <target> may not use a same port number, which will
be the case with port forwarding with NAT and realm specific IP. So,
<port0> is interpreted as an offset and added to <port1>.
If <port0> does not exist, <port1> is the port number to be used,
unless <port1> is 0. If <port1> is 0, <scheme> default port number
should be used.
If a server requests the client tell the URL used, reply should be
the original URL:
<scheme>://[<userinfo>@]<reg-name>[:<port0>]<path>[?<query>]
not:
<scheme>://[<userinfo>@]<target>:<port1>[+<port0>]<path>[?<query>]
which enables name based virtual hosting by <reg-name> and improves
security (see "Security Considerations" section).
3. Caching
As SRV RRs of _<scheme>._<proto>.<hostname> are looked up before
address(es) of <hostname>, if _<scheme>._<proto>.<hostname> does not
exist, extra DNS query is repeated every time <reg-name> appears in a
URL.
Thus, DNS should support negative caching.
In addition, clients should remember non existence of the node
_<scheme>._<proto>.<hostname> for a few minutes.
Managers of a <hostname>, which does not need SRV, may also set up an
SRV RR as:
_<scheme>._<proto>.<hostname> SRV 0 1 0 <hostname>
in addition to address RRs for <hostname>, which act as a positive
M. Ohta Expires on March 29, 2012 [Page 3]
INTERNET DRAFT Using DNS SRV RRs with URLs September 2011
cache with no effect (including an effect on port number, following
zero replacing rules in the previous section).
4. Security Considerations
Be aware that DNS look up of SRV RR may not be very secure.
For example, SSL key of https://<reg-name> should be derived from not
<target> but <hostname>.
5. IANA Considerations
This document has no actions for IANA.
Informative References
[SRV] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying
the location of services (DNS SRV)", RFC2782, February 2000.
[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC3986, January 2005.
[NAT] P. Srisuresh, K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC3022, January 2001.
[RSIP] M. Borella, J. Lo, D. Grabelsky, G. Montenegro, "Realm
Specific IP: Framework", RFC3102, October 2001.
Author's Address
Masataka Ohta
Graduate School of Information Science and Engineering
Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku
Tokyo 152-8552, JAPAN
Phone: +81-3-5734-3299
Fax: +81-3-5734-3299
EMail: mohta@necom830.hpcl.titech.ac.jp
M. Ohta Expires on March 29, 2012 [Page 4]
