INTERNET-DRAFT David Nicol Category: Experimental - Best Current Practice Oct 2003 Expires: Apr 1, 2004 Named lists of IP addresses within domains draft-nicol-dns-addresslists-00.txt Status of this Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document suggests a method for listing an arbitrary number of addresses under a DNS domain and a service name, for the purpose of unifying various proposals in which list addresses and are envisioned as being maintained by the operators of specific domains. Table of Contents 1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.0 Advantages of abstraction . . . . . . . . . . . . . . . . . . . 2.0.1 Semantic clarity . . . . . . . . . . . . . . . . . . . . . . . 2.0.2 Implementation reuse . . . . . . . . . . . . . . . . . . . . . 2.1 Named address lists . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Name Collisions . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Definition of service names . . . . . . . . . . . . . . . . . 2.1.3 delegation of defined service names . . . . . . . . . . . . . 2.2 Adequacy of A records for short lists . . . . . . . . . . . . 2.3. Inadequacy of A records when listing large lists . . . . . . . 3. Proposed solution . . . . . . . . . . . . . . . . . . . . . . . . 3.1 proposed framework for naming lists of addresses . . . . . . . . David L. Nicol Experimental - Best Current Practice [Page 1] nicol_01 Named lists of IP addresses October 2003 3.1.1 wrap address list names with dashes . . . . . . . . . . . . . 3.1.2 the list of address list names . . . . . . . . . . . . . . . . 3.1.2.1 Some list names will be listed in this document . . . . . . 3.1.2.1.1 X for local use . . . . . . . . . . . . . . . . . . . . . 3.1.3 Delegation of list service names . . . . . . . . . . . . . . . 3.2 Use A records for short lists . . . . . . . . . . . . . . . . . 3.3 Use extended syntax for longer lists and IPv6 . . . . . . . . . 3.3.1 reserved response signifying absence . . . . . . . . . . . . . Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 1. General Issues 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 [2119]. "example.com" and "example.net" are used as examples in accordance with RFC 2606 [2606]. 2. Problem Several proposals in several problem domains have been made that each independently and incompatably solve the general problem of listing several IP addresses in a way that is intended to be decentralized and widely adopted by administrators of internet equipment. 2.0 Advantages of abstraction 2.0.1 Semantic clarity By abstracting out the listing mechanism from proposals requiring address lists, the semantic differences between host listing proposal can be weighed orthogonally to the implementation of the listing. 2.0.2 Implementation reuse By abstracting the listing mechanism out from proposals requiring address lists, implementors of multiple proposals can deliver an implementation layer providing an in_list_p(IP_address,domain,name) function which can be used by multiple systems that require that membership of addresses in named lists to be ascertained. 2.1 Named address lists It is desirable to have a system in which an arbitrary list of IP addresses can be presented using only the A [RFC1035] record type. 2.1.1 Name Collisions David L. Nicol Experimental - Best Current Practice [Page 2] nicol_01 Named lists of IP addresses October 2003 A service name SHOULD NOT cause confusion by having the same name as a machine in use in a domain. 2.1.2 Definition of service names Service names SHOULD be well defined by each service that requires a listing facility 2.1.3 delegation of defined service names Service names SHOULD be delegable by service, so that one service can define multiple named lists 2.2 Adequacy of A records for short lists When listing eight or fewer addresses with a name, putting them all into an A record works. 2.3. Inadequacy of A records when listing large lists. Although DNS software allows an arbitrary number of A records to be associated with a name, a subset are served on any given request. 3. Proposed solution This document uses "serv" as the example name of the service being provided by the IP addresses listed in the examples. 3.1 proposed framework for naming lists of addresses 3.1.1 wrap address list names with dashes To avoid confusion with host machines that may have the same name as an address list, address list names have dashes pre and postpended. 3.1.2 the list of address list names A specification of what the named list names is required before it is reasonable to expect widespread adoption of the practice of publishing any list. Address list names will be assigned on a Specification Required basis [IANA-CONSIDERATIONS]. 3.1.2.1 Some list names will be listed in this document. 3.1.2.1.1 X for local use the X name is reserved for local use and testing of proposed address listing systems. 3.1.3 Delegation of list service names. David L. Nicol Experimental - Best Current Practice [Page 3] nicol_01 Named lists of IP addresses October 2003 Within a list service type, service name definition may be delegated. The definition of service SERV may change to include service names SERV-ONE and SERV-TWO without registering the extended, subordinate names. 3.2 Use A records for short lists When there are seven or fewer IP addresses in the list, listing all the IP addresses as A records for -serv-.example.com is sufficient. A domain MAY use extended syntax as well. For example, if example.com provides the service described in a document defining the "serv" named address list on machines hosted at 192.0.2.2, 192.0.2.27, 192.0.2.143 and 192.0.2.205 the example.com DNS would return four A records with those numbers in response to requests for the A records associated with the name -serv-.example.com. 3.3 Use extended syntax for longer lists and IPv6 When there are eight or more IP addresses in the list, in addition to listing at least eight of them as A records, A records MUST be provided for the numeric representation of the numbers. Numbers are divided into dotted quad notation, reversed, and prepended to the dash-wrapped list name. Example: example.net provides service SERV at ten IPv4 addresses with numbers 192.0.2.28 through 192.0.2.37 and ten IPv6 addresses with numbers 1080:0:0:0:8:800:200C:417A through 1080:0:0:0:8:800:200C:4184. In addition to listing A records for all ten IPv4 addresses, example. provides A records mapping as follows: 28.2.0.192.-serv-.example.net --> 192.0.2.28 29.2.0.192.-serv-.example.net --> 192.0.2.29 30.2.0.192.-serv-.example.net --> 192.0.2.30 31.2.0.192.-serv-.example.net --> 192.0.2.31 32.2.0.192.-serv-.example.net --> 192.0.2.32 33.2.0.192.-serv-.example.net --> 192.0.2.33 34.2.0.192.-serv-.example.net --> 192.0.2.34 35.2.0.192.-serv-.example.net --> 192.0.2.35 36.2.0.192.-serv-.example.net --> 192.0.2.36 37.2.0.192.-serv-.example.net --> 192.0.2.37 and AAAA records providing non-zero mappings for 417A.200C.800.8.0.0.0.1080.-serv-.example.net through 4184.200C.800.8.0.0.0.1080.-serv-.example.net David L. Nicol Experimental - Best Current Practice [Page 4] nicol_01 Named lists of IP addresses October 2003 3.3.1 reserved response signifying absence A domain using extended syntax MAY return A records of 0.0.0.0 for queries that are not on the list. Similar null IPv6 records may be returned as well. 4. References [RFC1035] Mockpetris, "Domain Implementation and Specification", RFC 1035, November 1987 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. [RFC 3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 20 declares "test-net" at 192.0.2.0/24 Draft History: 5 October 2003: posted draft of this document to ASRG list, received no comments. Author's Address: David Nicol post office box 45163 Kansas City, Missouri USA 64171-8163 Comments Please send comments to addresslist-rfc@davidnicol.com Expiry This drafts expires on Apr 1, 2004.