452 lines
14 KiB
Plaintext
452 lines
14 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group P. Koch
|
||
Request for Comments: 3123 Universitaet Bielefeld
|
||
Category: Experimental June 2001
|
||
|
||
|
||
A DNS RR Type for Lists of Address Prefixes (APL RR)
|
||
|
||
Status of this Memo
|
||
|
||
This memo defines an Experimental Protocol for the Internet
|
||
community. It does not specify an Internet standard of any kind.
|
||
Discussion and suggestions for improvement are requested.
|
||
Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
The Domain Name System (DNS) is primarily used to translate domain
|
||
names into IPv4 addresses using A RRs (Resource Records). Several
|
||
approaches exist to describe networks or address ranges. This
|
||
document specifies 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 [RFC2606].
|
||
|
||
2. Background
|
||
|
||
The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
|
||
associate addresses and other Internet infrastructure elements with
|
||
hierarchically built domain names. Various types of resource records
|
||
have been defined, especially those for IPv4 and IPv6 [RFC2874]
|
||
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 controlling access to zone data was
|
||
implemented using TXT RRs describing address ranges.
|
||
|
||
This document specifies a new RR type for address prefix lists.
|
||
|
||
|
||
|
||
|
||
|
||
Koch Experimental [Page 1]
|
||
|
||
RFC 3123 DNS APL RR June 2001
|
||
|
||
|
||
3. APL RR Type
|
||
|
||
An APL record has the DNS type of "APL" and a numeric value of 42
|
||
[IANA]. The APL RR is defined in the IN class only. APL RRs cause
|
||
no additional section processing.
|
||
|
||
4. APL RDATA format
|
||
|
||
The RDATA section consists of zero or more items (<apitem>) of the
|
||
form
|
||
|
||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||
| ADDRESSFAMILY |
|
||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||
| PREFIX | N | AFDLENGTH |
|
||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||
/ AFDPART /
|
||
| |
|
||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||
|
||
ADDRESSFAMILY 16 bit unsigned value as assigned by IANA
|
||
(see IANA Considerations)
|
||
PREFIX 8 bit unsigned binary coded prefix length.
|
||
Upper and lower bounds and interpretation of
|
||
this value are address family specific.
|
||
N negation flag, indicates the presence of the
|
||
"!" character in the textual format. It has
|
||
the value "1" if the "!" was given, "0" else.
|
||
AFDLENGTH length in octets of the following address
|
||
family dependent part (7 bit unsigned).
|
||
AFDPART address family dependent part. See below.
|
||
|
||
This document defines the AFDPARTs for address families 1 (IPv4) and
|
||
2 (IPv6). Future revisions may deal with additional address
|
||
families.
|
||
|
||
4.1. AFDPART for IPv4
|
||
|
||
The encoding of an IPv4 address (address family 1) follows the
|
||
encoding specified for the A RR by [RFC1035], section 3.4.1.
|
||
|
||
PREFIX specifies the number of bits of the IPv4 address starting at
|
||
the most significant bit. Legal values range from 0 to 32.
|
||
|
||
Trailing zero octets do not bear any information (e.g., there is no
|
||
semantic difference between 10.0.0.0/16 and 10/16) in an address
|
||
prefix, so the shortest possible AFDLENGTH can be used to encode it.
|
||
However, for DNSSEC [RFC2535] a single wire encoding must be used by
|
||
|
||
|
||
|
||
Koch Experimental [Page 2]
|
||
|
||
RFC 3123 DNS APL RR June 2001
|
||
|
||
|
||
all. Therefore the sender MUST NOT include trailing zero octets in
|
||
the AFDPART regardless of the value of PREFIX. This includes cases
|
||
in which AFDLENGTH times 8 results in a value less than PREFIX. The
|
||
AFDPART is padded with zero bits to match a full octet boundary.
|
||
|
||
An IPv4 AFDPART has a variable length of 0 to 4 octets.
|
||
|
||
4.2. AFDPART for IPv6
|
||
|
||
The 128 bit IPv6 address (address family 2) is encoded in network
|
||
byte order (high-order byte first).
|
||
|
||
PREFIX specifies the number of bits of the IPv6 address starting at
|
||
the most significant bit. Legal values range from 0 to 128.
|
||
|
||
With the same reasoning as in 4.1 above, the sender MUST NOT include
|
||
trailing zero octets in the AFDPART regardless of the value of
|
||
PREFIX. This includes cases in which AFDLENGTH times 8 results in a
|
||
value less than PREFIX. The AFDPART is padded with zero bits to
|
||
match a full octet boundary.
|
||
|
||
An IPv6 AFDPART has a variable length of 0 to 16 octets.
|
||
|
||
5. Zone File Syntax
|
||
|
||
The textual representation of an APL RR in a DNS zone file is as
|
||
follows:
|
||
|
||
<owner> IN <TTL> APL {[!]afi:address/prefix}*
|
||
|
||
The data consists of zero or more strings of the address family
|
||
indicator <afi>, immediately followed by a colon ":", an address,
|
||
immediately followed by the "/" character, immediately followed by a
|
||
decimal numeric value for the prefix length. Any such string may be
|
||
preceded by a "!" character. The strings are separated by
|
||
whitespace. The <afi> is the decimal numeric value of that
|
||
particular address family.
|
||
|
||
5.1. Textual Representation of IPv4 Addresses
|
||
|
||
An IPv4 address in the <address> part of an <apitem> is in dotted
|
||
quad notation, just as in an A RR. The <prefix> has values from the
|
||
interval 0..32 (decimal).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Koch Experimental [Page 3]
|
||
|
||
RFC 3123 DNS APL RR June 2001
|
||
|
||
|
||
5.2. Textual Representation of IPv6 Addresses
|
||
|
||
The representation of an IPv6 address in the <address> part of an
|
||
<apitem> follows [RFC2373], section 2.2. Legal values for <prefix>
|
||
are from the interval 0..128 (decimal).
|
||
|
||
6. APL RR usage
|
||
|
||
An APL RR with empty RDATA is valid and implements an empty list.
|
||
Multiple occurrences of the same <apitem> in a single APL RR are
|
||
allowed and MUST NOT be merged by a DNS server or resolver.
|
||
<apitems> MUST be kept in order and MUST NOT be rearranged or
|
||
aggregated.
|
||
|
||
A single APL RR may contain <apitems> belonging to different address
|
||
families. The maximum number of <apitems> is upper bounded by the
|
||
available RDATA space.
|
||
|
||
RRSets consisting of more than one APL RR are legal but the
|
||
interpretation is left to the particular application.
|
||
|
||
7. Applicability Statement
|
||
|
||
The APL RR defines a framework without specifying any particular
|
||
meaning for the list of prefixes. It is expected that APL RRs will
|
||
be used in different application scenarios which have to be
|
||
documented separately. Those scenarios may be distinguished by
|
||
characteristic prefixes placed in front of the DNS owner name.
|
||
|
||
An APL application specification MUST include information on
|
||
|
||
o the characteristic prefix, if any
|
||
|
||
o how to interpret APL RRSets consisting of more than one RR
|
||
|
||
o how to interpret an empty APL RR
|
||
|
||
o which address families are expected to appear in the APL RRs for
|
||
that application
|
||
|
||
o how to deal with APL RR list elements which belong to other
|
||
address families, including those not yet defined
|
||
|
||
o the exact semantics of list elements negated by the "!" character
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Koch Experimental [Page 4]
|
||
|
||
RFC 3123 DNS APL RR June 2001
|
||
|
||
|
||
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.
|
||
|
||
The specification of particular application scenarios is out of the
|
||
scope of this document.
|
||
|
||
8. Examples
|
||
|
||
The following examples only illustrate some of the possible usages
|
||
outlined in the previous section. None of those applications are
|
||
hereby specified nor is it implied that any particular APL RR based
|
||
application does exist now or will exist in the future.
|
||
|
||
; RFC 1101-like announcement of address ranges for foo.example
|
||
foo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
|
||
|
||
; CIDR blocks covered by classless delegation
|
||
42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
|
||
1:192.168.42.128/25 )
|
||
|
||
; Zone transfer restriction
|
||
_axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22
|
||
|
||
; List of address ranges for multicast
|
||
multicast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
|
||
|
||
Note that since trailing zeroes are ignored in the first APL RR the
|
||
AFDLENGTH of both <apitems> is three.
|
||
|
||
9. Security Considerations
|
||
|
||
Any information obtained from the DNS should be regarded as unsafe
|
||
unless techniques specified in [RFC2535] or [RFC2845] 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Koch Experimental [Page 5]
|
||
|
||
RFC 3123 DNS APL RR June 2001
|
||
|
||
|
||
10. IANA Considerations
|
||
|
||
This section is to be interpreted as following [RFC2434].
|
||
|
||
This document does not define any new namespaces. It uses the 16 bit
|
||
identifiers for address families maintained by IANA in
|
||
http://www.iana.org/numbers.html.
|
||
|
||
The IANA assigned numeric RR type value 42 for APL [IANA].
|
||
|
||
11. Acknowledgements
|
||
|
||
The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
|
||
Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
|
||
and constructive comments.
|
||
|
||
12. References
|
||
|
||
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
|
||
STD 13, RFC 1034, November 1987.
|
||
|
||
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
|
||
Specification", STD 13, RFC 1035, November 1987.
|
||
|
||
[RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other
|
||
Types", RFC 1101, April 1989.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
|
||
Specification", RFC 2181, July 1997.
|
||
|
||
[RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
|
||
ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
|
||
|
||
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
|
||
Architecture", RFC 2373, July 1998.
|
||
|
||
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
|
||
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
|
||
October 1998.
|
||
|
||
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
|
||
2535, March 1999.
|
||
|
||
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
|
||
BCP 32, RFC 2606, June 1999.
|
||
|
||
|
||
|
||
Koch Experimental [Page 6]
|
||
|
||
RFC 3123 DNS APL RR June 2001
|
||
|
||
|
||
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
|
||
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
|
||
2845, May 2000.
|
||
|
||
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
|
||
IPv6 Address Aggregation and Renumbering", RFC 2874, July
|
||
2000.
|
||
|
||
[IANA] http://www.iana.org/assignments/dns-parameters
|
||
|
||
13. Author's Address
|
||
|
||
Peter Koch
|
||
Universitaet Bielefeld
|
||
Technische Fakultaet
|
||
D-33594 Bielefeld
|
||
Germany
|
||
|
||
Phone: +49 521 106 2902
|
||
EMail: pk@TechFak.Uni-Bielefeld.DE
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Koch Experimental [Page 7]
|
||
|
||
RFC 3123 DNS APL RR June 2001
|
||
|
||
|
||
14. Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Koch Experimental [Page 8]
|
||
|