As per Relevance of the word experimental, we have this rfc below:
Network Working Group P.
Request for Comments: 3123 Universitaet
Category: Experimental June 2001
A DNS RR Type for Lists of Address Prefixes (APL RR
Status of this
This memo defines an Experimental Protocol for the
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
Copyright (C) The Internet Society (2001). All Rights Reserved
The Domain Name System (DNS) is primarily used to translate
names into IPv4 addresses using A RRs (Resource Records).
approaches exist to describe networks or address ranges.
document specifies a new DNS RR type "APL" for address prefix lists
1. Conventions used in this
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2119].
Domain names herein are for explanatory purposes only and should
be expected to lead to useful information in real life [RFC2606].
2.
The Domain Name System [RFC1034], [RFC1035] provides a mechanism
associate addresses and other Internet infrastructure elements
hierarchically built domain names. Various types of resource
have been defined, especially those for IPv4 and IPv6 [RFC2874]
addresses. In [RFC1101] a method is described to publish
about the address space allocated to an organisation. In older
versions, a weak form of controlling access to zone data
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
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
no additional section processing
4. APL RDATA
The RDATA section consists of zero or more items () of
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ADDRESSFAMILY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| PREFIX | N | AFDLENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AFDPART /
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
ADDRESSFAMILY 16 bit unsigned value as assigned by
(see IANA Considerations
PREFIX 8 bit unsigned binary coded prefix length
Upper and lower bounds and interpretation
this value are address family specific
N negation flag, indicates the presence of
"!" character in the textual format. It
the value "1" if the "!" was given, "0" else
AFDLENGTH length in octets of the following
family dependent part (7 bit unsigned).
AFDPART address family dependent part. See below
This document defines the AFDPARTs for address families 1 (IPv4)
2 (IPv6). Future revisions may deal with additional
families
4.1. AFDPART for IPv
The encoding of an IPv4 address (address family 1) follows
encoding specified for the A RR by [RFC1035], section 3.4.1.
PREFIX specifies the number of bits of the IPv4 address starting
the most significant bit. Legal values range from 0 to 32.
Trailing zero octets do not bear any information (e.g., there is
semantic difference between 10.0.0.0/16 and 10/16) in an
prefix, so the shortest possible AFDLENGTH can be used to encode it
However, for DNSSEC [RFC2535] a single wire encoding must be used
Koch Experimental [Page 2]
RFC 3123 DNS APL RR June 2001
all. Therefore the sender MUST NOT include trailing zero octets
the AFDPART regardless of the value of PREFIX. This includes
in which AFDLENGTH times 8 results in a value less than PREFIX.
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 IPv
The 128 bit IPv6 address (address family 2) is encoded in
byte order (high-order byte first).
PREFIX specifies the number of bits of the IPv6 address starting
the most significant bit. Legal values range from 0 to 128.
With the same reasoning as in 4.1 above, the sender MUST NOT
trailing zero octets in the AFDPART regardless of the value
PREFIX. This includes cases in which AFDLENGTH times 8 results in
value less than PREFIX. The AFDPART is padded with zero bits
match a full octet boundary
An IPv6 AFDPART has a variable length of 0 to 16 octets
5. Zone File
The textual representation of an APL RR in a DNS zone file is
follows
IN APL {[!]afi:address/prefix}*
The data consists of zero or more strings of the address
indicator , immediately followed by a colon ":", an address
immediately followed by the "/" character, immediately followed by
decimal numeric value for the prefix length. Any such string may
preceded by a "!" character. The strings are separated
whitespace. The is the decimal numeric value of
particular address family
5.1. Textual Representation of IPv4
An IPv4 address in the part of an is in
quad notation, just as in an A RR. The has values from
interval 0..32 (decimal).
Koch Experimental [Page 3]
RFC 3123 DNS APL RR June 2001
5.2. Textual Representation of IPv6
The representation of an IPv6 address in the part of
follows [RFC2373], section 2.2. Legal values for
are from the interval 0..128 (decimal).
6. APL RR
An APL RR with empty RDATA is valid and implements an empty list
Multiple occurrences of the same in a single APL RR
allowed and MUST NOT be merged by a DNS server or resolver
MUST be kept in order and MUST NOT be rearranged
aggregated
A single APL RR may contain belonging to different
families. The maximum number of is upper bounded by
available RDATA space
RRSets consisting of more than one APL RR are legal but
interpretation is left to the particular application
7. Applicability
The APL RR defines a framework without specifying any
meaning for the list of prefixes. It is expected that APL RRs
be used in different application scenarios which have to
documented separately. Those scenarios may be distinguished
characteristic prefixes placed in front of the DNS owner name
An APL application specification MUST include information
o the characteristic prefix, if
o how to interpret APL RRSets consisting of more than one
o how to interpret an empty APL
o which address families are expected to appear in the APL RRs
that
o how to deal with APL RR list elements which belong to
address families, including those not yet
o the exact semantics of list elements negated by the "!"
Koch Experimental [Page 4]
RFC 3123 DNS APL RR June 2001
Possible applications include the publication of address
similar to [RFC1101], description of zones built following [RFC2317]
and in-band access control to limit general access or zone
(AXFR) availability for zone data held in DNS servers
The specification of particular application scenarios is out of
scope of this document
8.
The following examples only illustrate some of the possible
outlined in the previous section. None of those applications
hereby specified nor is it implied that any particular APL RR
application does exist now or will exist in the future
; RFC 1101-like announcement of address ranges for foo.
foo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
; CIDR blocks covered by classless
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
_axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22
; List of address ranges for
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
AFDLENGTH of both is three
9. Security
Any information obtained from the DNS should be regarded as
unless techniques specified in [RFC2535] or [RFC2845] were used.
definition of a new RR type does not introduce security problems
the DNS, but usage of information made available by APL RRs
compromise security. This includes disclosure of network
information and in particular the use of APL RRs to construct
control lists
Koch Experimental [Page 5]
RFC 3123 DNS APL RR June 2001
10. IANA
This section is to be interpreted as following [RFC2434].
This document does not define any new namespaces. It uses the 16
identifiers for address families maintained by IANA
http://www.iana.org/numbers.html
The IANA assigned numeric RR type value 42 for APL [IANA].
11.
The author would like to thank Mark Andrews, Olafur Gudmundsson,
Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their
and constructive comments
12.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation
Specification", STD 13, RFC 1035, November 1987.
[RFC1101] Mockapetris, P., "DNS Encoding of Network Names and
Types", RFC 1101, April 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the
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
Architecture", RFC 2373, July 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
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)",
2845, May 2000.
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to
IPv6 Address Aggregation and Renumbering", RFC 2874,
2000.
[IANA] http://www.iana.org/assignments/dns-
13. Author's
Peter
Universitaet
Technische
D-33594
Phone: +49 521 106 2902
EMail: pk@TechFak.Uni-Bielefeld.
Koch Experimental [Page 7]
RFC 3123 DNS APL RR June 2001
14. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Koch Experimental [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
