Reverse DNS in IPv6 for Internet Service Providers
RFC 8501
Document | Type | RFC - Informational (November 2018; No errata) | |
---|---|---|---|
Author | Lee Howard | ||
Last updated | 2018-11-28 | ||
Replaces | draft-howard-isp-ip6rdns | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Tim Wicinski | ||
Shepherd write-up | Show (last changed 2018-07-18) | ||
IESG | IESG state | RFC 8501 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Warren Kumari | ||
Send notices to | "Tim Wicinski" <tjw.ietf@gmail.com>, "Suzanne Woolf" <suzworldwide@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl>, Tim Wicinski <tjw.ietf@gmail.com> | ||
IANA | IANA review state | IANA OK - No Actions Needed | |
IANA action state | No IANA Actions |
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 orShow full document text