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 or
Show full document text