One document matched: draft-ietf-dnsind-apl-rr-00.txt

INTERNET-DRAFT                                                Peter Koch
Expires: May 1999                                 Universitaet Bielefeld
Updates: RFC1034, RFC 1035                                 November 1998

        A DNS RR Type for Lists of IP Address Prefixes (APL RR)
                    draft-ietf-dnsind-apl-rr-00.txt


Status of this Memo

   This document is an Internet-Draft.  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."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Comments should be sent to the author or the DNSIND WG mailing list
   <namedroppers@internic.net>.

Abstract

   The Domain Name System is primarily used to translate domain names
   into IPv4 addresses using A RRs. Several approaches exist to describe
   networks or address ranges. This document proposes a new DNS RR type
   "APL" for address prefix lists.

1. Conventions used in this document

   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 [RFC2119].

   Domain names herein are for explanatory purposes only and should not
   be expected to lead to useful information in real life.

2. Background

   The Domain Name System [RFC1034], [RFC1035] provides a mechanism to



Koch                        Expires May 1999                    [Page 1]

INTERNET-DRAFT                 DNS APL RR                  November 1998


   assign addresses and other internet infrastructure elements to
   hierarchically built domain names. Various types of resource records
   have been defined, especially those for IPv4 and IPv6 addresses. In
   [RFC1101] a method is described to publish information about the
   address space allocated to an organisation. In older BIND versions, a
   weak form of access control to zone data was implemented using TXT
   RRs to describe address ranges.

   This document proposes a new RR type for address prefix lists.

3. Zone File Syntax

   An APL record has the DNS type of "APL" [draft: not yet applied for]
   and a numeric value of [draft:to be assigned]. The APL RR is defined
   in the IN class only.

           <owner> IN <TTL> APL {[!]address/prefix}*

   The data consists of zero or more strings of an IP address in the
   same format as in an A RR, immediately followed by the "/" character,
   immediately followed by a decimal numeric value for the prefix length
   (1..32). Any such string may be preceeded by a "!" character. The
   strings are separated by whitespace.

4. APL RDATA format

   The RDATA section consists of zero or more strings of the form

          +---+---+---+---+---+---+---+---+---+------//------+
          |     Z     | N |       PREFIX      |    ADDRESS   |
          +---+---+---+---+---+---+---+---+---+------//------+

   PREFIX is the binary coded prefix length (0-31). The value is one
         lower than that actually found in the textual representation.
   N negation flag, indicates the presence of the "!" character in the
         textual format. It has the value "1" if the "!" was given, "0"
         else.
   Z reserved, must be zero
   ADDRESS 32 bit IP address, same format as in an A RR

   Every single code/address string has a fixed length of five octets.
   The maximum number of strings is upperbounded by the available RDATA
   space.  The actual number of strings can be determined from the
   RDLENGTH information.  Future extensions may allow other string
   formats, probably leading to different string lengths.

5. APL RR usage




Koch                        Expires May 1999                    [Page 2]

INTERNET-DRAFT                 DNS APL RR                  November 1998


   An APL RR with empty RDATA is valid and implements an empty list.
   Multiple occurences of the same code/address string in a single APL
   RR are allowed and MUST NOT be merged by a DNS server or resolver.
   Prefixes must be kept in order and MUST NOT be rearranged or
   aggregated.

   Possible applications include the publication of address ranges
   similar to [RFC1101], description of zones built following [RFC2317]
   and in-band access control to limit general access or zone transfer
   (AXFR) availability for zone data held in DNS servers.

   RRSets consisting of more than one APL RR are legal but the
   interpretation is left to the particular application. It may choose
   to join the lists or treat them as alternatives.

6. Examples

        foo.example              APL 192.168.32.0/21 !192.168.38.0/28

        42.168.192.IN-ADDR.ARPA  APL 192.168.42.0/26 192.168.42.64/26 \
                                     192.168.42.128/25

        _axfr_.sbo.example       APL 127.0.0.1/32 172.16.64.0/22

7. Security Considerations

   Any information obtained from the DNS should be regarded as unsafe
   unless techniques specified in [RFC2065] or [TSIGRR] were used. The
   definition of a new RR type does not introduce security problems into
   the DNS, but usage of information made available by APL RRs may
   compromise security. This includes disclosure of network topology
   information and in particular the use of APL RRs to construct access
   control lists.

8. References

   [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
             RFC 1034, STD 13, November 1987

   [RFC1035] Mockapetris,P., "Domain Names - Implementation and
             Specification", RFC 1035, STD 13, November 1987

   [RFC1101] Mockapetris,P., "DNS Encoding of Network Names and Other
             Types", RFC 1101, April 1989

   [RFC2065] Eastlake,D., Kaufman,C. "Domain Name System Security
             Extensions", RFC 2065, January 1997




Koch                        Expires May 1999                    [Page 3]

INTERNET-DRAFT                 DNS APL RR                  November 1998


   [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, BCP 14, March 1997

   [RFC2181] Elz,R., Bush,R., "Clarifications to the DNS Specification",
             RFC 2181, July 1997

   [TSIGRR ] Vixie,P., Gudmundsson,O., Eastlake,D., "Secret Key
             Transaction Signatures for DNS (TSIG)", <draft-ietf-
             dnsind-tsig-XX.txt>, work in progress

9. Author's Address

   Peter Koch
   Universitaet Bielefeld
   Technische Fakultaet
   Postfach 10 01 31
   D-33501 Bielefeld
   Germany
   +49 521 106 2902
   <pk@TechFak.Uni-Bielefeld.DE>































Koch                        Expires May 1999                    [Page 4]