Re: [dnsop] Underscore registration summary
Mark Andrews <Mark_Andrews@isc.org> Tue, 18 July 2006 22:40 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2yF7-0002Z5-Fz for dnsop-archive@lists.ietf.org; Tue, 18 Jul 2006 18:40:41 -0400
Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2yF3-0006Tc-Nx for dnsop-archive@lists.ietf.org; Tue, 18 Jul 2006 18:40:41 -0400
Received: from mailapps.uoregon.edu (IDENT:U2FsdGVkX18lHI8/K+a5GIxwl4QtwcCCVrOPglHKrH8@localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.7/8.13.7) with ESMTP id k6ILwWrX003814; Tue, 18 Jul 2006 14:58:32 -0700
Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.7/8.13.7/Submit) id k6ILwWgT003812; Tue, 18 Jul 2006 14:58:32 -0700
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by mailapps.uoregon.edu (8.13.7/8.13.7) with ESMTP id k6ILwWsd003807 for <dnsop@lists.uoregon.edu>; Tue, 18 Jul 2006 14:58:32 -0700
Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id E0818E601F for <dnsop@lists.uoregon.edu>; Tue, 18 Jul 2006 21:58:25 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.6/8.13.6) with ESMTP id k6ILwBQs084686; Wed, 19 Jul 2006 07:58:12 +1000 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200607182158.k6ILwBQs084686@drugs.dv.isc.org>
To: Bill Fenner <fenner@research.att.com>
Cc: "Olaf M. Kolkman" <olaf@nlnetlabs.nl>, Edward Lewis <Ed.Lewis@neustar.biz>, DNSOP IETF Working Group <dnsop@lists.uoregon.edu>, dcrocker@bbiw.net
From: Mark Andrews <Mark_Andrews@isc.org>
Subject: Re: [dnsop] Underscore registration summary
In-reply-to: Your message of "Tue, 18 Jul 2006 07:06:46 MST." <200607181406.k6IE6kwf024608@bright.research.att.com>
Date: Wed, 19 Jul 2006 07:58:11 +1000
X-Virus-Scanned: ClamAV 0.88.3/1606/Tue Jul 18 13:56:15 2006 on mailapps
X-Virus-Status: Clean
Sender: owner-dnsop@lists.uoregon.edu
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79
> > >> How to move forward? In a way, it's a question of one registry > >> or two. If draft-crocker-dns-attrleaf intends to have all > >> protocols and services used in SRV records as well as the other > >> contents, it could serve as both. However, given the history, I > >> think SRV records need a little bit different registration rules, > >> so it may make sense to split them out into a different registry. > >> The question there would be whether it's just the top-most > >> prefixed label that gets registered in draft-crocker-dns-attrleaf > >> or all of them. > > > >Could you elaborate on that history and why you think you need > >different registration rules? > > RFC 2782 says that the service name is "from RFC1700" and doesn't > say which section. I've seen varying interpretations, from meaning > "any name registered anywhere in any IANA registry" to "the name > from the port-numbers registry". The latter is particularly > odd (you need to have a statically assigned port number in order > to get a name to be able to use the record that allows you to use > a dynamic port number), but seems fairly prevalent. > > I think that these names need different rules for two reasons: > a) I don't think there's a need to have globally unique > values for the "service" of a SRV record - it's OK if there's > an _spf._udp.example.com even if _spf is reserved as the "top > level" reserved label. > b) It's too high a barrier to require people who have validly > been using values such as _http._tcp.example.com under the > RFC 2782 rules to write an RFC in order to register the usage. Have you looked at what you need to do to migrate from non srv http to srv http? I did and it is not as straight forward as it would appear at first glance. I even wrote a I-D to describe the transition. It was reasons like this that the WG decided that existing protocols needed a RFC to transition to SRV usage. Mark INTERNET-DRAFT M. Andrews (ISC) <draft-andrews-http-srv-02.txt> T. Kottelin Updates: RFC 2616, RFC 2782 February 2002 Use of SRV records in conjuction with HTTP and URIs. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Comments should be sent to the authors. This draft expires on August 2002 Copyright Notice Copyright (C) The Internet Society (2002). All rights reserved. Abstract The combined use of SRV records for HTTP along with URIs is not as straight forward as it would appear at first glance. This document Expires August 2002 [Page 1] INTERNET-DRAFT SRV-URI February 2002 looks at the issues involved and recommends solutions. Introduction Many of todays HTTP sites are virtual, that is they are hosted on a machine that is not known by the name the HTTP site is known by. This leads to the problem of how to rationally give these HTTP sites IP addresses. This has traditionally been done by using CNAMES [RFC1034][RFC1035] or by using explicit IP address records where CNAMES are illegal due to restrictions in the DNS. Both of these solutions have undesired side effects. CNAMES are not protocol specific. Using IP address records is a logistic nightmare for large servers with many virtual sites. This is becoming a bigger problem as companies move away from identifying their HTTP site with a ``www'' prefix and just use their delegated domain name, e.g. ``http://example.com/''. Using SRV [RFC2782] records would seem to be a natural solution to this problem in that they are protocol specific and will work where CNAMES are illegal in the DNS. There are problems with doing this without thought however in that URIs [RFC1738] can specify a port and SRV records do specify a port. When this occurs which one do you honour? In addition to this SRV records provide for load balancing. For most protocols this is straight forward as there will only be a single connection made. For HTTP however there are often many connections made in a session. Should each of these individual connections be load balanced or should the load balancing be on a per session basis? The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1. URIs without an explicit port specification If the URI does not explicitly specify a port to connect to, i.e. the URI does not contain a ``:<port>'' part, there is no port conflict. In this case a client MUST follow the logic specified in [RFC2782], including the server selection mechanism provided by the priority and weight fields. If SRV records do not exist then the client MUST fall Expires August 2002 [Page 2] INTERNET-DRAFT SRV-URI February 2002 back to looking for IP address records. Once a server is selected it SHOULD be continued to be used for the rest of the session if possible after an initial connection is made. If a server has multiple addresses the client SHOULD continue to use the same address while possible taking into consideration ttl values on address records. If connections to this address fail it SHOULD try the other addresses for the server first before attempting other servers. The use of a SRV record does not affect the contents of the "Host:" field of the HTTP transaction. Its only effect is to potentially change the address and port the client connects to. All other parts of the HTTP transaction are not affected by the presence of a SRV record. Examples: Single SRV record: URI: http://example.com/ SRV RR: _http._tcp.example.com. SRV 10 0 8080 host1.example.com. A RRs: example.com. A 10.0.0.2 host1.example.com. A 10.0.1.1 Connect to: 10.0.1.1 port 8080 Multiple SRV records: URI: http://example.com/ SRV RRs: _http._tcp.example.com. SRV 10 1 8080 host1.example.com. _http._tcp.example.com. SRV 10 3 8080 host2.example.com. _http._tcp.example.com. SRV 20 0 8080 host3.example.com. A RRs: example.com. A 10.0.0.4 host1.example.com. A 10.0.1.2 host2.example.com. A 10.0.2.2 host3.example.com. AAAA 1080::8:800:200C:417A Connect to: 10.0.1.2 port 8080 or 10.0.2.2 port 8080 if either is available (the probability of being selected should be 25% for 10.0.1.2 port 8080, and 75% for 10.0.2.2 port 8080); otherwise, try 1080::8:800:200C:417A port 8080. Expires August 2002 [Page 3] INTERNET-DRAFT SRV-URI February 2002 2. URIs with a explicit port specification If the URI does explicitly specify a port to connect to then there is a potential conflict in the port specification between the URI and the SRV records, and the SRV record is ignored. In this case the user agent MUST query for address records for the host name in the URI (instead of SRV records). If the server has multiple addresses the client SHOULD continue to use the same address while possible taking into consideration ttl values on address records. Note [RFC2616], Section 3.2.3 URI Comparison, states that URIs with a port value equal to the default port (80) are identical to those with no port or a empty port. URIs with port are no longer treated as identical to those without a port or with a empty port. Examples: Default port specified: URI: http://example.com:80/ SRV RR: _http._tcp.example.com. SRV 10 1 8080 host2.example.com. A RRs: example.com. A 10.0.0.1 host2.example.com. A 10.0.2.2 Connect to: 10.0.0.1 port 80 Non-default port specified: URI: http://example.com:8080/ SRV RR: _http._tcp.example.com. SRV 10 1 80 host2.example.com. CNAME RR: example.com. CNAME host1.example.com. A RRs: host1.example.com. A 10.0.0.1 host2.example.com. AAAA 1080::8:800:200C:417A Connect to: 10.0.0.1 port 8080 3. Transitioning Considerations When transitioning from using a non-SRV solution to using a SRV based solution old, non-SRV aware, clients will continue to look for address records. It may be necessary to use redirection at the HTTP layer to direct these clients to the new servers if the SRV records Expires August 2002 [Page 4] INTERNET-DRAFT SRV-URI February 2002 point to a different <address, port> tuple. It will also be necessary to continue to provide the existing address / CNAME records until there is a significant percentage of SRV aware clients. Experience has shown that this should be within one to two years of the introduction of the first SRV aware client. In cases where you are just trying to replace the A or CNAME record referring to a service providers machine with a SRV record the following should suffice. The service provider is hosting the service on machine.example.net and you are example.com. example.com. A <IP address of machine.example.net> _http._tcp.example.com. SRV 0 0 80 machine.example.net. Security Considerations The authors believe the algorithm described in this document to not cause any new security problems. However care should be taken as SRV and non-SRV aware clients may be directed to different locations. IANA Considerations A well known label has to be allocated for the first label of the http SRV record. This document has used ``_http''. References [RFC1034] Domain names - concepts and facilities. P.V. Mockapetris. Nov-01-1987. STD 0013, RFC 1034. [RFC1035] Domain names - implementation and specification. P.V. Mockapetris. Nov-01-1987. STD 0013, RFC 1035. Expires August 2002 [Page 5] INTERNET-DRAFT SRV-URI February 2002 [RFC1738] Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter, M. McC ahill. December 1994. RFC 1738. [RFC2616] Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999. RFC 2616. [RFC2782] A DNS RR for specifying the location of services (DNS SRV). A. Gul brandsen, P. Vixie, L. Esibov. February 2000. RFC 2782. Authors' Addresses Mark Andrews Internet Software Consortium 1 Seymour St. Dundas Valley, NSW 2117, Australia +61 2 9871 4742 Mark.Andrews@isc.org Thor Kottelin Laivalahden puistotie 10 C 37 FIN-00810 Helsinki, Finland +358 400878169 thor@anta.net Expires August 2002 [Page 6] > Bill > . > dnsop resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
- [dnsop] Underscore registration summary Bill Fenner
- Re: [dnsop] Underscore registration summary Edward Lewis
- Re: [dnsop] Underscore registration summary Olaf M. Kolkman
- Re: [dnsop] Underscore registration summary Bill Fenner
- Re: [dnsop] Underscore registration summary Peter Koch
- Re: [dnsop] Underscore registration summary Douglas Otis
- Re: [dnsop] Underscore registration summary Joe Abley
- Re: [dnsop] Underscore registration summary Douglas Otis
- Re: [dnsop] Underscore registration summary Mark Andrews
- Re: [dnsop] Underscore registration summary Mark Andrews
- Re: [dnsop] Underscore registration summary Dave Crocker
- Re: [dnsop] Underscore registration summary Olaf M. Kolkman
- Re: [dnsop] Underscore registration summary Dave Crocker
- Re: [dnsop] Underscore registration summary Mark Andrews
- [dnsop] Removing hurdles Dave Crocker
- Re: [dnsop] Underscore registration summary Douglas Otis
- [dnsop] Re: Removing hurdles Mark Andrews
- [dnsop] Re: Removing hurdles Dave Crocker
- Re: [dnsop] Removing hurdles Olaf M. Kolkman
- Re: [dnsop] Underscore registration summary Peter Koch
- [dnsop] comments about SRV Edward Lewis
- Re: [dnsop] Underscore registration summary Dave Crocker
- Re: [dnsop] comments about SRV Dave Crocker
- Re: [dnsop] comments about SRV Joe Abley
- Re: [dnsop] comments about SRV Doug Barton
- Re: [dnsop] comments about SRV Mark Andrews
- Re: [dnsop] comments about SRV Dave Crocker