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 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 , a domain name, that is, have the following syntax [URI]: ://[@][:][?] It is also required that corresponds to a DNS hostname: . The URL means a client and a communicate over a protocol named using a single port number. In this memo, it is assumed that the client can deduce one or more from . and may be defined globally in Assigned Numbers or locally at [SRV]. 2. SRV Look Up First, SRV RRs of a DNS node, _._., is looked up. If the node does not have any SRV RR, DNS derived address(es) of is the address(es) of the server and (or default port of ) is the port number to be used. Otherwise, if the node has at least one SRV RR [SRV]: _._. SRV is the server to be used by the client. If there are multiple SRV RRs of the node, multiple 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 names corresponding to , all the SRV RRs for all the 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 , even after mixing. If exists, + (with 16bit arithmetic) is the port number to be used. The reason of addition is that, if is explicitly specified, there is no reason to ignore it, but SRV RRs assumes all the may not use a same port number, which will be the case with port forwarding with NAT and realm specific IP. So, is interpreted as an offset and added to . If does not exist, is the port number to be used, unless is 0. If is 0, default port number should be used. If a server requests the client tell the URL used, reply should be the original URL: ://[@][:][?] not: ://[@]:[+][?] which enables name based virtual hosting by and improves security (see "Security Considerations" section). 3. Caching As SRV RRs of _._. are looked up before address(es) of , if _._. does not exist, extra DNS query is repeated every time appears in a URL. Thus, DNS should support negative caching. In addition, clients should remember non existence of the node _._. for a few minutes. Managers of a , which does not need SRV, may also set up an SRV RR as: _._. SRV 0 1 0 in addition to address RRs for , 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:// should be derived from not but . 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]