doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc6303.txt b/doc/rfc/rfc6303.txt
new file mode 100644
index 0000000..b56eab9
--- /dev/null
+++ b/doc/rfc/rfc6303.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        M. Andrews
+Request for Comments: 6303                                           ISC
+BCP: 163                                                       July 2011
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+                        Locally Served DNS Zones
+
+Abstract
+
+   Experience with the Domain Name System (DNS) has shown that there are
+   a number of DNS zones that all iterative resolvers and recursive
+   nameservers should automatically serve, unless configured otherwise.
+   RFC 4193 specifies that this should occur for D.F.IP6.ARPA.  This
+   document extends the practice to cover the IN-ADDR.ARPA zones for RFC
+   1918 address space and other well-known zones with similar
+   characteristics.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6303.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Andrews                   Best Current Practice                 [Page 1]
+
+RFC 6303                Locally Served DNS Zones               July 2011
+
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Reserved Words .............................................3
+   2. Effects on Sites Using RFC 1918 Addresses .......................3
+   3. Changes to Iterative Resolver Behaviour .........................4
+   4. Lists Of Zones Covered ..........................................5
+      4.1. RFC 1918 Zones .............................................5
+      4.2. RFC 5735 and RFC 5737 Zones ................................5
+      4.3. Local IPv6 Unicast Addresses ...............................6
+      4.4. IPv6 Locally Assigned Local Addresses ......................6
+      4.5. IPv6 Link-Local Addresses ..................................7
+      4.6. IPv6 Example Prefix ........................................7
+   5. Zones That Are Out of Scope .....................................7
+   6. IANA Considerations .............................................8
+   7. Security Considerations .........................................8
+   8. Acknowledgements ................................................9
+   9. References ......................................................9
+      9.1. Normative References .......................................9
+      9.2. Informative References ....................................10
+
+1.  Introduction
+
+   Experience with the Domain Name System (DNS, [RFC1034] and [RFC1035])
+   has shown that there are a number of DNS zones that all iterative
+   resolvers and recursive nameservers SHOULD automatically serve,
+   unless intentionally configured otherwise.  These zones include, but
+   are not limited to, the IN-ADDR.ARPA zones for the address space
+   allocated by [RFC1918] and the IP6.ARPA zones for locally assigned
+   unique local IPv6 addresses defined in [RFC4193].
+
+
+
+
+
+
+
+
+
+Andrews                   Best Current Practice                 [Page 2]
+
+RFC 6303                Locally Served DNS Zones               July 2011
+
+
+   This recommendation is made because data has shown that significant
+   leakage of queries for these namespaces is occurring, despite
+   instructions to restrict them, and because it has therefore become
+   necessary to deploy sacrificial nameservers to protect the immediate
+   parent nameservers for these zones from excessive, unintentional
+   query load [AS112] [RFC6304] [RFC6305].  There is every expectation
+   that the query load will continue to increase unless steps are taken
+   as outlined here.
+
+   Additionally, queries from clients behind badly configured firewalls
+   that allow outgoing queries for these namespaces, but drop the
+   responses, put a significant load on the root servers (forward zones
+   but not reverse zones are configured).  They also cause operational
+   load for the root server operators, as they have to reply to
+   enquiries about why the root servers are "attacking" these clients.
+   Changing the default configuration will address all these issues for
+   the zones listed in Section 4.
+
+   [RFC4193] recommends that queries for D.F.IP6.ARPA be handled
+   locally.  This document extends the recommendation to cover the
+   IN-ADDR.ARPA zones for [RFC1918] and other well-known IN-ADDR.ARPA
+   and IP6.ARPA zones for which queries should not appear on the public
+   Internet.
+
+   It is hoped that by doing this the number of sacrificial servers
+   [AS112] will not have to be increased, and may in time be reduced.
+
+   This recommendation should also help DNS responsiveness for sites
+   that are using [RFC1918] addresses but do not follow the last
+   paragraph in Section 3 of [RFC1918].
+
+1.1.  Reserved Words
+
+   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].
+
+2.  Effects on Sites Using RFC 1918 Addresses
+
+   For most sites using [RFC1918] addresses, the changes here will have
+   little or no detrimental effect.  If the site does not already have
+   the reverse tree populated, the only effect will be that the name
+   error responses will be generated locally rather than remotely.
+
+   For sites that do have the reverse tree populated, most will either
+   have a local copy of the zones or will be forwarding the queries to
+   servers that have local copies of the zone.  Therefore, this
+   recommendation will not be relevant.
+
+
+
+Andrews                   Best Current Practice                 [Page 3]
+
+RFC 6303                Locally Served DNS Zones               July 2011
+
+
+   The most significant impact will be felt at sites that make use of
+   delegations for [RFC1918] addresses and have populated these zones.
+   These sites will need to override the default configuration expressed
+   in this document to allow resolution to continue.  Typically, such
+   sites will be fully disconnected from the Internet and have their own
+   root servers for their own non-Internet DNS tree.
+
+3.  Changes to Iterative Resolver Behaviour
+
+   Unless configured otherwise, an iterative resolver will now return
+   authoritatively (AA=1) name errors (RCODE=3) for queries within the
+   zones in Section 4, with the obvious exception of queries for the
+   zone name itself where SOA, NS, and "no data" responses will be
+   returned as appropriate to the query type.  One common way to do this
+   all at once is to serve empty (SOA and NS only) zones.
+
+   An implementation of this recommendation MUST provide a mechanism to
+   disable this new behaviour, and SHOULD allow this decision on a zone-
+   by-zone basis.
+
+   If using empty zones one SHOULD NOT use the same NS and SOA records
+   as used on the public Internet servers, as that will make it harder
+   to detect the origin of the responses and thus any leakage to the
+   public Internet servers.  It is RECOMMENDED that the NS record
+   defaults to the name of the zone and the SOA MNAME defaults to the
+   name of the only NS RR's (Resource Record's) target.  The SOA RNAME
+   SHOULD default to "nobody.invalid."  [RFC2606].  Implementations
+   SHOULD provide a mechanism to set these values.  No address records
+   need to be provided for the nameserver.
+
+   Below is an example of a generic empty zone in master file format.
+   It will produce a negative cache Time to Live (TTL) of 3 hours.
+
+   @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
+   @ 10800 IN NS @
+
+   The SOA RR is needed to support negative caching [RFC2308] of name
+   error responses and to point clients to the primary master for DNS
+   dynamic updates.
+
+   SOA values of particular importance are the MNAME, the SOA RR's TTL,
+   and the negTTL value.  Both TTL values SHOULD match.  The rest of the
+   SOA timer values MAY be chosen arbitrarily since they are not
+   intended to control any zone transfer activity.
+
+   The NS RR is needed as some UPDATE [RFC2136] clients use NS queries
+   to discover the zone to be updated.  Having no address records for
+   the nameserver is expected to abort UPDATE processing in the client.
+
+
+
+Andrews                   Best Current Practice                 [Page 4]
+
+RFC 6303                Locally Served DNS Zones               July 2011
+
+
+4.  Lists Of Zones Covered
+
+   The following subsections are the initial contents of the IANA
+   registry as described in the IANA Considerations section.  Following
+   the caveat in that section, the list contains only reverse zones
+   corresponding to permanently assigned address space.  The zone name
+   is the entity to be registered.
+
+4.1.  RFC 1918 Zones
+
+   The following zones correspond to the IPv4 address space reserved in
+   [RFC1918].
+
+                         +----------------------+
+                         | Zone                 |
+                         +----------------------+
+                         | 10.IN-ADDR.ARPA      |
+                         | 16.172.IN-ADDR.ARPA  |
+                         | 17.172.IN-ADDR.ARPA  |
+                         | 18.172.IN-ADDR.ARPA  |
+                         | 19.172.IN-ADDR.ARPA  |
+                         | 20.172.IN-ADDR.ARPA  |
+                         | 21.172.IN-ADDR.ARPA  |
+                         | 22.172.IN-ADDR.ARPA  |
+                         | 23.172.IN-ADDR.ARPA  |
+                         | 24.172.IN-ADDR.ARPA  |
+                         | 25.172.IN-ADDR.ARPA  |
+                         | 26.172.IN-ADDR.ARPA  |
+                         | 27.172.IN-ADDR.ARPA  |
+                         | 28.172.IN-ADDR.ARPA  |
+                         | 29.172.IN-ADDR.ARPA  |
+                         | 30.172.IN-ADDR.ARPA  |
+                         | 31.172.IN-ADDR.ARPA  |
+                         | 168.192.IN-ADDR.ARPA |
+                         +----------------------+
+
+4.2.  RFC 5735 and RFC 5737 Zones
+
+   The following zones correspond to those address ranges from [RFC5735]
+   and [RFC5737] that are not expected to appear as source or
+   destination addresses on the public Internet; as such, there are no
+   globally unique names associated with the addresses in these ranges.
+
+
+
+
+
+
+
+
+
+Andrews                   Best Current Practice                 [Page 5]
+
+RFC 6303                Locally Served DNS Zones               July 2011
+
+
+   The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not an
+   attempt to discourage any practice to provide a PTR RR for
+   1.0.0.127.IN-ADDR.ARPA locally.  In fact, a meaningful reverse
+   mapping should exist, but the exact setup is out of the scope of this
+   document.  Similar logic applies to the reverse mapping for ::1
+   (Section 4.3).  The recommendations made here simply assume that no
+   other coverage for these domains exists.
+
+         +------------------------------+-----------------------+
+         | Zone                         | Description           |
+         +------------------------------+-----------------------+
+         | 0.IN-ADDR.ARPA               | IPv4 "THIS" NETWORK   |
+         | 127.IN-ADDR.ARPA             | IPv4 Loopback NETWORK |
+         | 254.169.IN-ADDR.ARPA         | IPv4 LINK LOCAL       |
+         | 2.0.192.IN-ADDR.ARPA         | IPv4 TEST-NET-1       |
+         | 100.51.198.IN-ADDR.ARPA      | IPv4 TEST-NET-2       |
+         | 113.0.203.IN-ADDR.ARPA       | IPv4 TEST-NET-3       |
+         | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST        |
+         +------------------------------+-----------------------+
+
+4.3.  Local IPv6 Unicast Addresses
+
+   The reverse mappings ([RFC3596], Section 2.5 ("IP6.ARPA Domain")) for
+   the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC4291],
+   Sections 2.4, 2.5.2, and 2.5.3) are covered by these two zones:
+
+               +-------------------------------------------+
+               | Zone                                      |
+               +-------------------------------------------+
+               | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
+               |     0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA      |
+               | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
+               |     0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA      |
+               +-------------------------------------------+
+
+   Note: Line breaks and escapes ('\') have been inserted above for
+   readability and to adhere to line width constraints.  They are not
+   parts of the zone names.
+
+4.4.  IPv6 Locally Assigned Local Addresses
+
+   Section 4.4 of [RFC4193] already required special treatment of:
+
+                             +--------------+
+                             | Zone         |
+                             +--------------+
+                             | D.F.IP6.ARPA |
+                             +--------------+
+
+
+
+Andrews                   Best Current Practice                 [Page 6]
+
+RFC 6303                Locally Served DNS Zones               July 2011
+
+
+4.5.  IPv6 Link-Local Addresses
+
+   IPv6 Link-Local Addresses as described in [RFC4291], Section 2.5.6
+   are covered by four distinct reverse DNS zones:
+
+                            +----------------+
+                            | Zone           |
+                            +----------------+
+                            | 8.E.F.IP6.ARPA |
+                            | 9.E.F.IP6.ARPA |
+                            | A.E.F.IP6.ARPA |
+                            | B.E.F.IP6.ARPA |
+                            +----------------+
+
+4.6.  IPv6 Example Prefix
+
+   IPv6 example prefix [RFC3849].
+
+                       +--------------------------+
+                       | Zone                     |
+                       +--------------------------+
+                       | 8.B.D.0.1.0.0.2.IP6.ARPA |
+                       +--------------------------+
+
+   Note: 8.B.D.0.1.0.0.2.IP6.ARPA is not being used as an example here.
+
+5.  Zones That Are Out of Scope
+
+   IPv6 site-local addresses (deprecated, see [RFC4291] Sections 2.4 and
+   2.5.7), and IPv6 non-locally assigned local addresses ([RFC4193]) are
+   not covered here.
+
+   It is expected that IPv6 site-local addresses will be self correcting
+   as IPv6 implementations remove support for site-local addresses.
+   However, sacrificial servers for the zones C.E.F.IP6.ARPA through
+   F.E.F.IP6.ARPA may still need to be deployed in the short term if the
+   traffic becomes excessive.
+
+   For IPv6 non-locally assigned local addresses (L = 0) [RFC4193],
+   there has been no decision made about whether the Regional Internet
+   Registries (RIRs) will provide delegations in this space or not.  If
+   they don't, then C.F.IP6.ARPA will need to be added to the list in
+   Section 4.4.  If they do, then registries will need to take steps to
+   ensure that nameservers are provided for these addresses.
+
+
+
+
+
+
+
+Andrews                   Best Current Practice                 [Page 7]
+
+RFC 6303                Locally Served DNS Zones               July 2011
+
+
+   IP6.INT was once used to provide reverse mapping for IPv6.  IP6.INT
+   was deprecated in [RFC4159] and the delegation removed from the INT
+   zone in June 2006.  While it is possible that legacy software
+   continues to send queries for names under the IP6.INT domain, this
+   document does not specify that IP6.INT be considered a local zone.
+
+   This document has also deliberately ignored names immediately under
+   the root domain.  While there is a subset of queries to the root
+   nameservers that could be addressed using the techniques described
+   here (e.g., .local, .workgroup, and IPv4 addresses), there is also a
+   vast amount of traffic that requires a different strategy (e.g.,
+   lookups for unqualified hostnames, IPv6 addresses).
+
+6.  IANA Considerations
+
+   IANA has established a registry of zones that require this default
+   behaviour.  The initial contents of this registry are defined in
+   Section 4.  Implementors are encouraged to periodically check this
+   registry and adjust their implementations to reflect changes therein.
+
+   This registry can be amended through "IETF Review" as per [RFC5226].
+   As part of this review process, it should be noted that once a zone
+   is added it is effectively added permanently; once an address range
+   starts being configured as a local zone in systems on the Internet,
+   it will be impossible to reverse those changes.
+
+   IANA should coordinate with the RIRs to ensure that, as DNS Security
+   (DNSSEC) is deployed in the reverse tree, delegations for these zones
+   are made in the manner described in Section 7.
+
+7.  Security Considerations
+
+   During the initial deployment phase, particularly where [RFC1918]
+   addresses are in use, there may be some clients that unexpectedly
+   receive a name error rather than a PTR record.  This may cause some
+   service disruption until their recursive nameserver(s) have been
+   re-configured.
+
+   As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
+   namespaces, the zones listed above will need to be delegated as
+   insecure delegations, or be within insecure zones.  This will allow
+   DNSSEC validation to succeed for queries in these spaces despite not
+   being answered from the delegated servers.
+
+   It is recommended that sites actively using these namespaces secure
+   them using DNSSEC [RFC4035] by publishing and using DNSSEC trust
+   anchors.  This will protect the clients from accidental import of
+   unsigned responses from the Internet.
+
+
+
+Andrews                   Best Current Practice                 [Page 8]
+
+RFC 6303                Locally Served DNS Zones               July 2011
+
+
+8.  Acknowledgements
+
+   This work was supported by the US National Science Foundation
+   (research grant SCI-0427144) and DNS-OARC.
+
+9.  References
+
+9.1.  Normative 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.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+              and E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2606]  Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
+              Names", BCP 32, RFC 2606, June 1999.
+
+   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+              "DNS Extensions to Support IP Version 6", RFC 3596,
+              October 2003.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC4159]  Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
+              August 2005.
+
+   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+              Addresses", RFC 4193, October 2005.
+
+
+
+
+
+
+Andrews                   Best Current Practice                 [Page 9]
+
+RFC 6303                Locally Served DNS Zones               July 2011
+
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+9.2.  Informative References
+
+   [AS112]    "AS112 Project", <http://www.as112.net/>.
+
+   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
+              Reserved for Documentation", RFC 3849, July 2004.
+
+   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
+              BCP 153, RFC 5735, January 2010.
+
+   [RFC5737]  Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
+              Reserved for Documentation", RFC 5737, January 2010.
+
+   [RFC6304]  Abley, J. and W. Maton, "AS112 Nameserver Operations",
+              RFC 6304, July 2011.
+
+   [RFC6305]  Abley, J. and W. Maton, "I'm Being Attacked by
+              PRISONER.IANA.ORG!", RFC 6305, July 2011.
+
+Author's Address
+
+   Mark P. Andrews
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   US
+
+   EMail: marka@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews                   Best Current Practice                [Page 10]
+