Reverse DNS in IPv6 for Internet Service Providers
RFC 8501

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07

Internet Engineering Task Force (IETF)                         L. Howard
Request for Comments: 8501                                       Retevia
Category: Informational                                    November 2018
ISSN: 2070-1721

           Reverse DNS in IPv6 for Internet Service Providers

Abstract

   In IPv4, Internet Service Providers (ISPs) commonly provide
   IN-ADDR.ARPA information for their customers by prepopulating the
   zone with one PTR record for every available address.  This practice
   does not scale in IPv6.  This document analyzes different approaches
   and considerations for ISPs in managing the IP6.ARPA zone.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   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).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8501.

Copyright Notice

   Copyright (c) 2018 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
   (https://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.

Howard                        Informational                     [Page 1]
RFC 8501              Reverse DNS in IPv6 for ISPs         November 2018

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Reverse DNS in IPv4 . . . . . . . . . . . . . . . . . . .   3
     1.2.  Reverse DNS Considerations in IPv6  . . . . . . . . . . .   4
   2.  Alternatives in IPv6  . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Negative Response . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Wildcard Match  . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . .   5
       2.3.1.  Dynamic DNS from Individual Hosts . . . . . . . . . .   6
       2.3.2.  Dynamic DNS through Residential Gateways  . . . . . .   7
       2.3.3.  Automatic DNS Delegations . . . . . . . . . . . . . .   7
       2.3.4.  Generate Dynamic Records  . . . . . . . . . . . . . .   8
       2.3.5.  Populate from DHCP Server . . . . . . . . . . . . . .   8
       2.3.6.  Populate from RADIUS Server . . . . . . . . . . . . .   8
     2.4.  Delegate DNS  . . . . . . . . . . . . . . . . . . . . . .   9
     2.5.  Dynamically Generate PTR When Queried ("On the Fly")  . .   9
   3.  Manual User Updates . . . . . . . . . . . . . . . . . . . . .  10
   4.  Considerations and Recommendations  . . . . . . . . . . . . .  10
   5.  Security and Privacy Considerations . . . . . . . . . . . . .  11
     5.1.  Using Reverse DNS for Security  . . . . . . . . . . . . .  11
     5.2.  DNS Security with Dynamic DNS . . . . . . . . . . . . . .  11
     5.3.  Considerations for Other Uses of the DNS  . . . . . . . .  12
     5.4.  Privacy Considerations  . . . . . . . . . . . . . . . . .  12
     5.5.  User Creativity . . . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   [RFC1912] recommended that "every Internet-reachable host should have
   a name" and says "Failure to have matching PTR and A records can
   cause loss of Internet services similar to not being registered in
   the DNS at all".  While the need for a PTR record and for it to match
   is debatable as a best practice, some network services (see
   Section 4) still do rely on PTR lookups, and some check the source
   address of incoming connections and verify that the PTR and A records
   match before providing service.

   Individual Internet users on the residential or consumer scale,
   including small and home businesses, are constantly connecting to or