contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                                  D. Senie
   8 Category: BCP                                     Amaranth Networks Inc.
   9 Expires in six months                                          July 2005
  10
  11                Encouraging the use of DNS IN-ADDR Mapping
  12                     draft-ietf-dnsop-inaddr-required-07.txt
  13
  14 Status of this Memo
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups.  Note that
  23    other groups may also distribute working documents as Internet-
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six months
  27    and may be updated, replaced, or obsoleted by other documents at any
  28    time.  It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html
  36
  37 Abstract
  38
  39    Mapping of addresses to names has been a feature of DNS.  Many sites,
  40    implement it, many others don't.  Some applications attempt to use it
  41    as a part of a security strategy. The goal of this document is to
  42    encourage proper deployment of address to name mappings, and provide
  43    guidance for their use.
  44
  45 Copyright Notice
  46
  47    Copyright (C) The Internet Society. (2005)
  48
  49 1. Introduction
  50
  51    The Domain Name Service has provision for providing mapping of IP
  52    addresses to host names. It is common practice to ensure both name to
  53    address, and address to name mappings are provided for networks. This
  54    practice, while documented, has never been required, though it is
  55    generally encouraged.  This document both encourages the presence of
  56
  57
  58
  59 Senie                                                           [Page 1]
  60 \f
  61 Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
  62
  63
  64    these mappings and discourages reliance on such mappings for security
  65    checks.
  66
  67    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  68    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  69    document are to be interpreted as described in RFC 2119 [RFC2119].
  70
  71 2. Discussion
  72
  73
  74    From the early days of the Domain Name Service [RFC883] a special
  75    domain has been set aside for resolving mappings of IP addresses to
  76    domain names.  This was refined in [RFC1035], describing the .IN-
  77    ADDR.ARPA in use today.  For the in the IPv6 address space, .IP6.ARPA
  78    was added [RFC3152]. This document uses IPv4 CIDR block sizes and
  79    allocation strategy where there are differences and uses IPv4
  80    terminology.  Aside from these differences, this document can and
  81    should be applied to both address spaces.
  82
  83    The assignment of blocks of IP address space was delegated to three
  84    regional registries. Guidelines for the registries are specified in
  85    [RFC2050], which requires regional registries to maintain IN-ADDR
  86    records on the large blocks of space issued to ISPs and others.
  87
  88    ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
  89    allocations. For smaller allocations, ARIN can provide IN-ADDR for
  90    /24 and shorter prefixes. [ARIN].  APNIC provides methods for ISPs to
  91    update IN-ADDR, however the present version of its policy document
  92    for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
  93    copies of this document. As of this writing, it appears APNIC has no
  94    actual policy on IN-ADDR.  RIPE appears to have the strongest policy
  95    in this area [RIPE302] indicating Local Internet Registries should
  96    provide IN-ADDR services, and delegate those as appropriate when
  97    address blocks are delegated.
  98
  99    As we can see, the regional registries have their own policies for
 100    recommendations and/or requirements for IN-ADDR maintenance. It
 101    should be noted, however, that many address blocks were allocated
 102    before the creation of the regional registries, and thus it is
 103    unclear whether any of the policies of the registries are binding on
 104    those who hold blocks from that era.
 105
 106    Registries allocate address blocks on CIDR [RFC1519] boundaries.
 107    Unfortunately the IN-ADDR zones are based on classful allocations.
 108    Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
 109    exist, but are not always implemented.
 110
 111 3. Examples of impact of missing IN-ADDR
 112
 113
 114
 115 Senie                                                           [Page 2]
 116 \f
 117 Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
 118
 119
 120    These are some examples of problems that may be introduced by
 121    reliance on IN-ADDR.
 122
 123    Some applications use DNS lookups for security checks. To ensure
 124    validity of claimed names, some applications will look up IN-ADDR
 125    records to get names, and then look up the resultant name to see if
 126    it maps back to the address originally known. Failure to resolve
 127    matching names is seen as a potential security concern.
 128
 129    Some FTP sites will flat-out reject users, even for anonymous FTP, if
 130    the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
 131    itself resolved, does not match. Some Telnet servers also implement
 132    this check.
 133
 134    Web sites are in some cases using IN-ADDR checks to verify whether
 135    the client is located within a certain geopolitical entity. This
 136    approach has been employed for downloads of crypto software, for
 137    example, where export of that software is prohibited to some locales.
 138    Credit card anti-fraud systems also use these methods for geographic
 139    placement purposes.
 140
 141    The popular TCP Wrappers program found on most Unix and Linux systems
 142    has options to enforce IN-ADDR checks and to reject any client that
 143    does not resolve. This program also has a way to check to see that
 144    the name given by a PTR record then resolves back to the same IP
 145    address. This method provdes more comfort but no appreciable
 146    additional security.
 147
 148    Some anti-spam (anti junk email) systems use IN-ADDR to verify the
 149    presence of a PTR record, or validate the PTR value points back to
 150    the same address.
 151
 152    Many web servers look up the IN-ADDR of visitors to be used in log
 153    analysis.  This adds to the server load, but in the case of IN-ADDR
 154    unavailability, it can lead to delayed responses for users.
 155
 156    Traceroutes with descriptive IN-ADDR naming proves useful when
 157    debugging problems spanning large areas. When this information is
 158    missing, the traceroutes take longer, and it takes additional steps
 159    to determine that network is the cause of problems.
 160
 161    Wider-scale implementation of IN-ADDR on dialup, wireless access and
 162    other such client-oriented portions of the Internet would result in
 163    lower latency for queries (due to lack of negative caching), and
 164    lower name server load and DNS traffic.
 165
 166 4. Recommendations
 167
 168
 169
 170
 171 Senie                                                           [Page 3]
 172 \f
 173 Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
 174
 175
 176    4.1 Delegation Recommendations
 177
 178
 179    Regional Registries and any Local Registries to whom they delegate
 180    should establish and convey a policy to those to whom they delegate
 181    blocks that IN-ADDR mappings are recommended.  Policies should
 182    recommend those receiving delegations to provide IN-ADDR service
 183    and/or delegate to downstream customers.
 184
 185    Network operators should define and implement policies and procedures
 186    which delegate IN-ADDR to their clients who wish to run their own IN-
 187    ADDR DNS services, and provide IN-ADDR services for those who do not
 188    have the resources to do it themselves.  Delegation mechanisms should
 189    permit the downstream customer to implement and comply with IETF
 190    recommendations application of IN-ADDR to CIDR [RFC2317].
 191
 192    All IP address space assigned and in use should be resolved by IN-
 193    ADDR records. All PTR records must use canonical names.
 194
 195    All IP addresses in use within a block should have an IN-ADDR
 196    mapping. Those addresses not in use, and those that are not valid for
 197    use (zeros or ones broadcast addresses within a CIDR block) need not
 198    have mappings.
 199
 200    It should be noted that due to CIDR, many addresses that appear to be
 201    otherwise valid host addresses may actually be zeroes or ones
 202    broadcast addresses. As such, attempting to audit a site's degree of
 203    compliance may only be done with knowledge of the internal subnet
 204    architecture of the site.  It can be assumed, however, any host that
 205    originates an IP packet necessarily will have a valid host address,
 206    and must therefore have an IN-ADDR mapping.
 207
 208 4.2 Application Recommendations
 209
 210
 211    Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
 212    of IN-ADDR, sometimes in conjunction with a lookup of the name
 213    resulting from the PTR record provides no real security, can lead to
 214    erroneous results and generally just increases load on DNS servers.
 215    Further, in cases where address block holders fail to properly
 216    configure IN-ADDR, users of those blocks are penalized.
 217
 218 5. Security Considerations
 219
 220    This document has no negative impact on security. While it could be
 221    argued that lack of PTR record capabilities provides a degree of
 222    anonymity, this is really not valid. Trace routes, whois lookups and
 223    other sources will still provide methods for discovering identity.
 224
 225
 226
 227 Senie                                                           [Page 4]
 228 \f
 229 Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
 230
 231
 232    By recommending applications avoid using IN-ADDR as a security
 233    mechanism this document points out that this practice, despite its
 234    use by many applications, is an ineffective form of security.
 235    Applications should use better mechanisms of authentication.
 236
 237 6. IANA Considerations
 238
 239    There are no IANA considerations for this document.
 240
 241 7. References
 242
 243 7.1 Normative References
 244
 245    [RFC883] P.V. Mockapetris, "Domain names: Implementation
 246    specification," RFC883, November 1983.
 247
 248    [RFC1035] P.V. Mockapetris, "Domain Names: Implementation
 249    Specification," RFC 1035, November 1987.
 250
 251    [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
 252    an Address Assignment and Aggregation Strategy," RFC 1519, September
 253    1993.
 254
 255    [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
 256    RFC 2026, BCP 9, October 1996.
 257
 258    [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
 259    Requirement Levels", RFC 2119, BCP 14, March 1997.
 260
 261    [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
 262    Guidelines", RFC2050, BCP 12, Novebmer 1996.
 263
 264    [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
 265    RFC 2317, March 1998.
 266
 267    [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
 268    2001.
 269
 270 7.2 Informative References
 271
 272    [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
 273    unknown, http://www.arin.net/regserv/initial-isp.html
 274
 275    [APNIC] "Policies For IPv4 Address Space Management in the Asia
 276    Pacific Region," APNIC-086, 13 January 2003.
 277
 278    [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
 279    Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
 280
 281
 282
 283 Senie                                                           [Page 5]
 284 \f
 285 Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
 286
 287
 288    2004. http://www.ripe.net//ripe/docs/rev-del.html
 289
 290
 291
 292 8. Acknowledgements
 293
 294    Thanks to Peter Koch and Gary Miller for their input, and to many
 295    people who encouraged me to write this document.
 296
 297 9. Author's Address
 298
 299    Daniel Senie
 300    Amaranth Networks Inc.
 301    324 Still River Road
 302    Bolton, MA 01740
 303
 304    Phone: (978) 779-5100
 305
 306    EMail: dts@senie.com
 307
 308 10.  Full Copyright Statement
 309
 310       Copyright (C) The Internet Society (2005).
 311
 312       This document is subject to the rights, licenses and restrictions
 313       contained in BCP 78, and except as set forth therein, the authors
 314       retain all their rights.
 315
 316       This document and the information contained herein are provided
 317       on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 318       REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
 319       THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
 320       EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
 321       THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
 322       ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
 323       PARTICULAR PURPOSE.
 324
 325 Intellectual Property
 326
 327       The IETF takes no position regarding the validity or scope of any
 328       Intellectual Property Rights or other rights that might be claimed
 329       to pertain to the implementation or use of the technology
 330       described in this document or the extent to which any license
 331       under such rights might or might not be available; nor does it
 332       represent that it has made any independent effort to identify any
 333       such rights.  Information on the procedures with respect to
 334       rights in RFC documents can be found in BCP 78 and BCP 79.
 335
 336
 337
 338
 339 Senie                                                           [Page 6]
 340 \f
 341 Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
 342
 343
 344       Copies of IPR disclosures made to the IETF Secretariat and any
 345       assurances of licenses to be made available, or the result of an
 346       attempt made to obtain a general license or permission for the use
 347       of such proprietary rights by implementers or users of this
 348       specification can be obtained from the IETF on-line IPR repository
 349       at http://www.ietf.org/ipr.
 350
 351       The IETF invites any interested party to bring to its attention
 352       any copyrights, patents or patent applications, or other
 353       proprietary rights that may cover technology that may be required
 354       to implement this standard.  Please address the information to the
 355       IETF at ietf-ipr@ietf.org.
 356
 357       Internet-Drafts are working documents of the
 358       Internet Engineering Task Force (IETF), its areas, and its
 359       working groups. Note that other groups may also distribute
 360       working documents as Internet-Drafts.
 361
 362       Internet-Drafts are draft documents valid for a maximum of
 363       six months and may be updated, replaced, or obsoleted by
 364       other documents at any time. It is inappropriate to use
 365       Internet-Drafts as reference material or to cite them other
 366       than as "work in progress."
 367
 368       The list of current Internet-Drafts can be accessed at
 369       http://www.ietf.org/1id-abstracts.html
 370
 371       The list of Internet-Draft Shadow Directories can be
 372       accessed at http://www.ietf.org/shadow.html
 373
 374 Acknowledgement
 375
 376       Funding for the RFC Editor function is currently provided by the
 377       Internet Society.
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395 Senie                                                           [Page 7]
 396 \f