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.