Special-Use Domain 'home.arpa.'
RFC 8375

#x27;.  At this time, we do
   not have operational experience that would guide us in making this
   decision; implementors are encouraged to consider the context in
   which their software will be deployed when deciding how to resolve
   this question.

7.  Delegation of 'home.arpa.'

   In order to be fully functional, there must be a delegation of
   'home.arpa.' in the '.arpa.' zone [RFC3172].  This delegation MUST
   NOT include a DS record and MUST point to one or more black hole
   servers, for example, 'blackhole-1.iana.org.' and 'blackhole-
   2.iana.org.'.  The reason that this delegation must not be signed is
   that not signing the delegation breaks the DNSSEC chain of trust,
   which prevents a validating stub resolver from rejecting names
   published under 'home.arpa.' on a homenet name server.

8.  IANA Considerations

   IANA has recorded the domain name 'home.arpa.' in the "Special-Use
   Domain Names" registry [SUDN].  IANA, with the approval of the IAB,
   has implemented the delegation requested in Section 7.

   IANA has created a new subregistry within the "Locally-Served DNS
   Zones" registry [LSDZ], titled "Transport-Independent Locally-Served
   DNS Zone Registry", with the same format as the other subregistries.
   IANA has added an entry in this new registry for 'home.arpa.' with
   the description "Homenet Special-Use Domain", listing this document
   as the reference.  The registration procedure for this subregistry
   should be the same as for the others, currently "IETF Review" (see
   Section 4.8 of [RFC8126]).

Pfister & Lemon              Standards Track                    [Page 9]
RFC 8375                       home.arpa.                       May 2018

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3172]  Huston, G., Ed., "Management Guidelines & Operational
              Requirements for the Address and Routing Parameter Area
              Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
              September 2001, <https://www.rfc-editor.org/info/rfc3172>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/info/rfc4035>.

   [RFC6303]  Andrews, M., "Locally Served DNS Zones", BCP 163,
              RFC 6303, DOI 10.17487/RFC6303, July 2011,
              <https://www.rfc-editor.org/info/rfc6303>.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,
              <https://www.rfc-editor.org/info/rfc6761>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [ICANN1]   "New gTLD Collision Risk Mitigation", August 2013,
              <https://www.icann.org/en/system/files/files/
              new-gtld-collision-mitigation-05aug13-en.pdf>.

   [ICANN2]   "New gTLD Collision Occurence Management", October 2013,
              <https://www.icann.org/en/system/files/files/
              resolutions-new-gtld-annex-1-07oct13-en.pdf>.

   [LSDZ]     "Locally-Served DNS Zones", July 2011,
              <https://www.iana.org/assignments/
              locally-served-dns-zones/>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

Pfister & Lemon              Standards Track                   [Page 10]
RFC 8375                       home.arpa.                       May 2018

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

   [RFC7368]  Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
              Weil, "IPv6 Home Networking Architecture Principles",
              RFC 7368, DOI 10.17487/RFC7368, October 2014,
              <https://www.rfc-editor.org/info/rfc7368>.

   [RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
              Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
              2016, <https://www.rfc-editor.org/info/rfc7788>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [SUDN]     "Special-Use Domain Names", July 2012,
              <https://www.iana.org/assignments/
              special-use-domain-names/>.

Pfister & Lemon              Standards Track                   [Page 11]
RFC 8375                       home.arpa.                       May 2018

Acknowledgments

   The authors would like to thank Stuart Cheshire, as well as the
   homenet chairs, Mark Townsley and Ray Bellis, for their prior work on
   '.home'.  We would also like to thank Paul Hoffman for providing
   review and comments on the IANA Considerations section, Andrew
   Sullivan for his review and proposed text, and Suzanne Woolf and Ray
   Bellis for their very detailed review comments and process insights.
   Thanks to Mark Andrews for providing an exhaustive reference list on
   the topic of insecure delegations.  Thanks to Dale Worley for
   catching a rather egregious mistake and for the Gen-Art review, and
   thanks to Daniel Migault for a thorough SecDir review.  Thanks to
   Warren Kumari for catching some additional issues and to Adam Roach
   for some helpful clarifications.

Authors' Addresses

   Pierre Pfister
   Cisco Systems
   Paris
   France

   Email: pierre.pfister@darou.fr

   Ted Lemon
   Nibbhaya Consulting
   P.O. Box 958
   Brattleboro, Vermont  05301-0958
   United States of America

   Email: mellon@fugue.com

Pfister & Lemon              Standards Track                   [Page 12]