external/bsd/bind/dist/doc/rfc/rfc3123.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            P. Koch
   8 Request for Comments: 3123                        Universitaet Bielefeld
   9 Category: Experimental                                         June 2001
  10
  11
  12           A DNS RR Type for Lists of Address Prefixes (APL RR)
  13
  14 Status of this Memo
  15
  16    This memo defines an Experimental Protocol for the Internet
  17    community.  It does not specify an Internet standard of any kind.
  18    Discussion and suggestions for improvement are requested.
  19    Distribution of this memo is unlimited.
  20
  21 Copyright Notice
  22
  23    Copyright (C) The Internet Society (2001).  All Rights Reserved.
  24
  25 Abstract
  26
  27    The Domain Name System (DNS) is primarily used to translate domain
  28    names into IPv4 addresses using A RRs (Resource Records).  Several
  29    approaches exist to describe networks or address ranges.  This
  30    document specifies a new DNS RR type "APL" for address prefix lists.
  31
  32 1. Conventions used in this document
  33
  34    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  35    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  36    document are to be interpreted as described in [RFC2119].
  37
  38    Domain names herein are for explanatory purposes only and should not
  39    be expected to lead to useful information in real life [RFC2606].
  40
  41 2. Background
  42
  43    The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
  44    associate addresses and other Internet infrastructure elements with
  45    hierarchically built domain names.  Various types of resource records
  46    have been defined, especially those for IPv4 and IPv6 [RFC2874]
  47    addresses.  In [RFC1101] a method is described to publish information
  48    about the address space allocated to an organisation.  In older BIND
  49    versions, a weak form of controlling access to zone data was
  50    implemented using TXT RRs describing address ranges.
  51
  52    This document specifies a new RR type for address prefix lists.
  53
  54
  55
  56
  57
  58 Koch                          Experimental                      [Page 1]
  59 \f
  60 RFC 3123                       DNS APL RR                      June 2001
  61
  62
  63 3. APL RR Type
  64
  65    An APL record has the DNS type of "APL" and a numeric value of 42
  66    [IANA].  The APL RR is defined in the IN class only.  APL RRs cause
  67    no additional section processing.
  68
  69 4. APL RDATA format
  70
  71    The RDATA section consists of zero or more items (<apitem>) of the
  72    form
  73
  74       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  75       |                          ADDRESSFAMILY                        |
  76       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  77       |             PREFIX            | N |         AFDLENGTH         |
  78       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  79       /                            AFDPART                            /
  80       |                                                               |
  81       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  82
  83       ADDRESSFAMILY     16 bit unsigned value as assigned by IANA
  84                         (see IANA Considerations)
  85       PREFIX            8 bit unsigned binary coded prefix length.
  86                         Upper and lower bounds and interpretation of
  87                         this value are address family specific.
  88       N                 negation flag, indicates the presence of the
  89                         "!" character in the textual format.  It has
  90                         the value "1" if the "!" was given, "0" else.
  91       AFDLENGTH         length in octets of the following address
  92                         family dependent part (7 bit unsigned).
  93       AFDPART           address family dependent part.  See below.
  94
  95    This document defines the AFDPARTs for address families 1 (IPv4) and
  96    2 (IPv6).  Future revisions may deal with additional address
  97    families.
  98
  99 4.1. AFDPART for IPv4
 100
 101    The encoding of an IPv4 address (address family 1) follows the
 102    encoding specified for the A RR by [RFC1035], section 3.4.1.
 103
 104    PREFIX specifies the number of bits of the IPv4 address starting at
 105    the most significant bit.  Legal values range from 0 to 32.
 106
 107    Trailing zero octets do not bear any information (e.g., there is no
 108    semantic difference between 10.0.0.0/16 and 10/16) in an address
 109    prefix, so the shortest possible AFDLENGTH can be used to encode it.
 110    However, for DNSSEC [RFC2535] a single wire encoding must be used by
 111
 112
 113
 114 Koch                          Experimental                      [Page 2]
 115 \f
 116 RFC 3123                       DNS APL RR                      June 2001
 117
 118
 119    all.  Therefore the sender MUST NOT include trailing zero octets in
 120    the AFDPART regardless of the value of PREFIX.  This includes cases
 121    in which AFDLENGTH times 8 results in a value less than PREFIX.  The
 122    AFDPART is padded with zero bits to match a full octet boundary.
 123
 124    An IPv4 AFDPART has a variable length of 0 to 4 octets.
 125
 126 4.2. AFDPART for IPv6
 127
 128    The 128 bit IPv6 address (address family 2) is encoded in network
 129    byte order (high-order byte first).
 130
 131    PREFIX specifies the number of bits of the IPv6 address starting at
 132    the most significant bit.  Legal values range from 0 to 128.
 133
 134    With the same reasoning as in 4.1 above, the sender MUST NOT include
 135    trailing zero octets in the AFDPART regardless of the value of
 136    PREFIX.  This includes cases in which AFDLENGTH times 8 results in a
 137    value less than PREFIX.  The AFDPART is padded with zero bits to
 138    match a full octet boundary.
 139
 140    An IPv6 AFDPART has a variable length of 0 to 16 octets.
 141
 142 5. Zone File Syntax
 143
 144    The textual representation of an APL RR in a DNS zone file is as
 145    follows:
 146
 147    <owner>   IN   <TTL>   APL   {[!]afi:address/prefix}*
 148
 149    The data consists of zero or more strings of the address family
 150    indicator <afi>, immediately followed by a colon ":", an address,
 151    immediately followed by the "/" character, immediately followed by a
 152    decimal numeric value for the prefix length.  Any such string may be
 153    preceded by a "!" character.  The strings are separated by
 154    whitespace.  The <afi> is the decimal numeric value of that
 155    particular address family.
 156
 157 5.1. Textual Representation of IPv4 Addresses
 158
 159    An IPv4 address in the <address> part of an <apitem> is in dotted
 160    quad notation, just as in an A RR.  The <prefix> has values from the
 161    interval 0..32 (decimal).
 162
 163
 164
 165
 166
 167
 168
 169
 170 Koch                          Experimental                      [Page 3]
 171 \f
 172 RFC 3123                       DNS APL RR                      June 2001
 173
 174
 175 5.2. Textual Representation of IPv6 Addresses
 176
 177    The representation of an IPv6 address in the <address> part of an
 178    <apitem> follows [RFC2373], section 2.2.  Legal values for <prefix>
 179    are from the interval 0..128 (decimal).
 180
 181 6. APL RR usage
 182
 183    An APL RR with empty RDATA is valid and implements an empty list.
 184    Multiple occurrences of the same <apitem> in a single APL RR are
 185    allowed and MUST NOT be merged by a DNS server or resolver.
 186    <apitems> MUST be kept in order and MUST NOT be rearranged or
 187    aggregated.
 188
 189    A single APL RR may contain <apitems> belonging to different address
 190    families.  The maximum number of <apitems> is upper bounded by the
 191    available RDATA space.
 192
 193    RRSets consisting of more than one APL RR are legal but the
 194    interpretation is left to the particular application.
 195
 196 7. Applicability Statement
 197
 198    The APL RR defines a framework without specifying any particular
 199    meaning for the list of prefixes.  It is expected that APL RRs will
 200    be used in different application scenarios which have to be
 201    documented separately.  Those scenarios may be distinguished by
 202    characteristic prefixes placed in front of the DNS owner name.
 203
 204    An APL application specification MUST include information on
 205
 206    o  the characteristic prefix, if any
 207
 208    o  how to interpret APL RRSets consisting of more than one RR
 209
 210    o  how to interpret an empty APL RR
 211
 212    o  which address families are expected to appear in the APL RRs for
 213       that application
 214
 215    o  how to deal with APL RR list elements which belong to other
 216       address families, including those not yet defined
 217
 218    o  the exact semantics of list elements negated by the "!" character
 219
 220
 221
 222
 223
 224
 225
 226 Koch                          Experimental                      [Page 4]
 227 \f
 228 RFC 3123                       DNS APL RR                      June 2001
 229
 230
 231    Possible applications include the publication of address ranges
 232    similar to [RFC1101], description of zones built following [RFC2317]
 233    and in-band access control to limit general access or zone transfer
 234    (AXFR) availability for zone data held in DNS servers.
 235
 236    The specification of particular application scenarios is out of the
 237    scope of this document.
 238
 239 8. Examples
 240
 241    The following examples only illustrate some of the possible usages
 242    outlined in the previous section.  None of those applications are
 243    hereby specified nor is it implied that any particular APL RR based
 244    application does exist now or will exist in the future.
 245
 246   ; RFC 1101-like announcement of address ranges for foo.example
 247   foo.example.             IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
 248
 249   ; CIDR blocks covered by classless delegation
 250   42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
 251                                   1:192.168.42.128/25 )
 252
 253   ; Zone transfer restriction
 254   _axfr.sbo.example.       IN APL 1:127.0.0.1/32 1:172.16.64.0/22
 255
 256   ; List of address ranges for multicast
 257   multicast.example.       IN APL 1:224.0.0.0/4  2:FF00:0:0:0:0:0:0:0/8
 258
 259    Note that since trailing zeroes are ignored in the first APL RR the
 260    AFDLENGTH of both <apitems> is three.
 261
 262 9. Security Considerations
 263
 264    Any information obtained from the DNS should be regarded as unsafe
 265    unless techniques specified in [RFC2535] or [RFC2845] were used.  The
 266    definition of a new RR type does not introduce security problems into
 267    the DNS, but usage of information made available by APL RRs may
 268    compromise security.  This includes disclosure of network topology
 269    information and in particular the use of APL RRs to construct access
 270    control lists.
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Koch                          Experimental                      [Page 5]
 283 \f
 284 RFC 3123                       DNS APL RR                      June 2001
 285
 286
 287 10. IANA Considerations
 288
 289    This section is to be interpreted as following [RFC2434].
 290
 291    This document does not define any new namespaces.  It uses the 16 bit
 292    identifiers for address families maintained by IANA in
 293    http://www.iana.org/numbers.html.
 294
 295    The IANA assigned numeric RR type value 42 for APL [IANA].
 296
 297 11. Acknowledgements
 298
 299    The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
 300    Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
 301    and constructive comments.
 302
 303 12. References
 304
 305    [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
 306              STD 13, RFC 1034, November 1987.
 307
 308    [RFC1035] Mockapetris, P., "Domain Names - Implementation and
 309              Specification", STD 13, RFC 1035, November 1987.
 310
 311    [RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other
 312              Types", RFC 1101, April 1989.
 313
 314    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 315              Requirement Levels", BCP 14, RFC 2119, March 1997.
 316
 317    [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
 318              Specification", RFC 2181, July 1997.
 319
 320    [RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
 321              ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
 322
 323    [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
 324              Architecture", RFC 2373, July 1998.
 325
 326    [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
 327              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
 328              October 1998.
 329
 330    [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
 331              2535, March 1999.
 332
 333    [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
 334              BCP 32, RFC 2606, June 1999.
 335
 336
 337
 338 Koch                          Experimental                      [Page 6]
 339 \f
 340 RFC 3123                       DNS APL RR                      June 2001
 341
 342
 343    [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
 344              "Secret Key Transaction Authentication for DNS (TSIG)", RFC
 345              2845, May 2000.
 346
 347    [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
 348              IPv6 Address Aggregation and Renumbering", RFC 2874, July
 349              2000.
 350
 351    [IANA]    http://www.iana.org/assignments/dns-parameters
 352
 353 13. Author's Address
 354
 355    Peter Koch
 356    Universitaet Bielefeld
 357    Technische Fakultaet
 358    D-33594 Bielefeld
 359    Germany
 360
 361    Phone: +49 521 106 2902
 362    EMail: pk@TechFak.Uni-Bielefeld.DE
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Koch                          Experimental                      [Page 7]
 395 \f
 396 RFC 3123                       DNS APL RR                      June 2001
 397
 398
 399 14. Full Copyright Statement
 400
 401    Copyright (C) The Internet Society (2001).  All Rights Reserved.
 402
 403    This document and translations of it may be copied and furnished to
 404    others, and derivative works that comment on or otherwise explain it
 405    or assist in its implementation may be prepared, copied, published
 406    and distributed, in whole or in part, without restriction of any
 407    kind, provided that the above copyright notice and this paragraph are
 408    included on all such copies and derivative works.  However, this
 409    document itself may not be modified in any way, such as by removing
 410    the copyright notice or references to the Internet Society or other
 411    Internet organizations, except as needed for the purpose of
 412    developing Internet standards in which case the procedures for
 413    copyrights defined in the Internet Standards process must be
 414    followed, or as required to translate it into languages other than
 415    English.
 416
 417    The limited permissions granted above are perpetual and will not be
 418    revoked by the Internet Society or its successors or assigns.
 419
 420    This document and the information contained herein is provided on an
 421    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 422    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 423    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 424    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 425    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 426
 427 Acknowledgement
 428
 429    Funding for the RFC Editor function is currently provided by the
 430    Internet Society.
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Koch                          Experimental                      [Page 8]
 451 \f