summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8501.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8501.txt')
-rw-r--r--doc/rfc/rfc8501.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc8501.txt b/doc/rfc/rfc8501.txt
new file mode 100644
index 0000000..6c52fc6
--- /dev/null
+++ b/doc/rfc/rfc8501.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+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
+ moving around the Internet. For large ISPs who serve residential
+ users, maintenance of individual PTR records is impractical.
+
+
+
+
+Howard Informational [Page 2]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+ Administrators at ISPs should consider whether customer PTR records
+ are needed, and if so, evaluate methods for responding to reverse DNS
+ queries in IPv6.
+
+1.1. Reverse DNS in IPv4
+
+ ISPs that provide access to many residential users typically assign
+ one or a few IPv4 addresses to each of those users and populate an
+ IN-ADDR.ARPA zone with one PTR record for every IPv4 address. Some
+ ISPs also configure forward zones with matching A records so that
+ lookups match. For instance, if an ISP Example.com aggregated
+ 192.0.2.0/24 at a network hub in one region, the reverse zone might
+ look like:
+
+ 1.2.0.192.IN-ADDR.ARPA. IN PTR 1.string.region.example.com.
+
+ 2.2.0.192.IN-ADDR.ARPA. IN PTR 2.string.region.example.com.
+
+ 3.2.0.192.IN-ADDR.ARPA. IN PTR 3.string.region.example.com.
+
+ .
+
+ .
+
+ .
+
+ 254.2.0.192.IN-ADDR.ARPA. IN PTR 254.string.region.example.com.
+
+ The conscientious Example.com might then also have a zone:
+
+ 1.string.region.example.com. IN A 192.0.2.1
+
+ 2.string.region.example.com. IN A 192.0.2.2
+
+ 3.string.region.example.com. IN A 192.0.2.3
+
+ .
+
+ .
+
+ .
+
+ 254.string.region.example.com. IN A 192.0.2.254
+
+ Many ISPs generate PTR records for all IP addresses used for
+ customers, and many create the matching A record.
+
+
+
+
+
+Howard Informational [Page 3]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+1.2. Reverse DNS Considerations in IPv6
+
+ A sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56:789a might be:
+
+ a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2
+ .IP6.ARPA. IN PTR 1.string.region.example.com.
+
+ ISPs will often delegate an IPv6 prefix to their customers. Since
+ 2^^80 possible addresses could be configured in a single /48 zone
+ alone, it is impractical to write a zone with every possible address
+ entered, even with automation. If 1000 entries could be written per
+ second, the zone would still not be complete after 38 trillion years.
+
+ Furthermore, it is often impossible to associate hostnames and
+ addresses, since the 64 bits in the Interface Identifier portion of
+ the address are frequently assigned using Stateless Address
+ Autoconfiguration (SLAAC) [RFC4862] when the host comes online, and
+ they may be short-lived.
+
+ [RFC1912] is an Informational RFC that says "PTR records must point
+ back to a valid A record" and further that the administrator should
+ "Make sure your PTR and A records match." Herein are considerations
+ for how to follow this advice for AAAA and PTR records.
+
+2. Alternatives in IPv6
+
+ Several options exist for providing reverse DNS in IPv6. All of
+ these options also exist for IPv4, but the scaling problem is much
+ less severe in IPv4. Each option should be evaluated for its scaling
+ ability, compliance with existing standards and best practices, and
+ availability in common systems.
+
+2.1. Negative Response
+
+ Some ISP DNS administrators may choose to provide only an NXDOMAIN
+ response to PTR queries for subscriber addresses. In some ways, this
+ is the most accurate response, since no name information is known
+ about the host. However, providing a negative response to PTR
+ queries does not satisfy the expectation in [RFC1912] for entries to
+ match. Users of services that are dependent on a successful lookup
+ will have a poor experience. For instance, some web services and
+ Secure Shell (SSH) connections wait for a DNS response, even
+ NXDOMAIN, before responding. For the best user experience, then, it
+ is important to return a response, rather than time out with no
+ answer. On the other hand, external mail servers are likely to
+ reject connections, which might be an advantage in fighting spam.
+
+
+
+
+
+Howard Informational [Page 4]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+ When evaluating this option, DNS administrators should consider the
+ uses for reverse DNS records and the number of services affecting the
+ number of users.
+
+2.2. Wildcard Match
+
+ The use of wildcards in the DNS is described in [RFC4592], and their
+ use in IPv6 reverse DNS is described in [RFC4472].
+
+ While recording all possible addresses is not scalable, it may be
+ possible to record a wildcard entry for each prefix assigned to a
+ customer. Consider also that "inclusion of wildcard NS RRSets in a
+ zone is discouraged, but not barred". [RFC4592]
+
+ This solution generally scales well. However, since the response
+ will match any address in the wildcard range (/48, /56, /64, etc.), a
+ forward DNS lookup on the response given will not be able to return
+ the same hostname. This method therefore fails the expectation in
+ [RFC1912] that forward and reverse will match. DNSSEC [RFC4035]
+ scalability is limited to signing the wildcard zone, which may be
+ satisfactory.
+
+2.3. Dynamic DNS
+
+ One way to ensure that forward and reverse records match is for hosts
+ to update DNS servers dynamically once interface configuration is
+ complete (whether by SLAAC, DHCPv6, or other means), as described in
+ [RFC4472]. Hosts would need to provide both AAAA and PTR updates and
+ would need to know which servers would accept the information.
+
+ This option should scale as well or as poorly as IPv4 dynamic DNS
+ (DDNS) does. Dynamic DNS may not scale effectively in large ISP
+ networks that have no single master name server, but a single master
+ server is not best practice. The ISP's DNS system may provide a
+ point for Denial-of-Service attacks, including many attempted DDNS
+ updates. Accepting updates only from authenticated sources may
+ mitigate this risk, but only if authentication itself does not
+ require excessive overhead. No authentication of dynamic DNS updates
+ is inherently provided. Implementers should therefore consider use
+ of TSIG [RFC2845], or at least ingress filtering, so that updates are
+ only accepted from customer address space from internal network
+ interfaces. They should also rate limit the number of updates from a
+ customer per second and consider impacts on scalability. UDP is
+ allowed per [RFC2136], so connection reliability is not assured,
+ though the host should expect an ERROR or NOERROR message from the
+ server; TCP provides transmission control, but the updating host
+ would need to be configured to use TCP.
+
+
+
+
+Howard Informational [Page 5]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+ Administrators may want to consider user creativity if they provide
+ hostnames, as described in Section 5.5, "User Creativity".
+
+ There is no assurance of uniqueness if multiple hosts try to update
+ with the same name ("mycomputer.familyname.org"). There is no
+ standard way to indicate to a host what server it should send DDNS
+ updates to; the master listed in the SOA is often assumed to be a
+ DDNS server, but this may not scale.
+
+2.3.1. Dynamic DNS from Individual Hosts
+
+ In the simplest case, a residential user will have a single host
+ connected to the ISP. Since the typical residential user cannot
+ configure IPv6 addresses or resolving name servers on their hosts,
+ the ISP should provide address information conventionally -- i.e.,
+ using their normal combination of Router Advertisements (RAs), DHCP,
+ etc. The ISP should also provide a DNS Recursive Name Server and
+ Domain Search List as described in [RFC3646] or [RFC8106]. In
+ determining its Fully Qualified Domain Name (FQDN), a host will
+ typically use a domain from the Domain Search List. This is an
+ overloading of the parameter; multiple domains could be listed, since
+ hosts may need to search for unqualified names in multiple domains
+ without necessarily being a member of those domains. Administrators
+ should consider whether the Domain Search List actually provides an
+ appropriate DNS suffix(es) when considering use of this option. For
+ the purposes of dynamic DNS, the host would concatenate its local
+ hostname (e.g., "hostname") plus the domain(s) in the Domain Search
+ List (e.g., "customer.example.com"), as in
+ "hostname.customer.example.com".
+
+ Once it learns its address and has a resolving name server, the host
+ must perform an SOA lookup on the IP6.ARPA record to be added in
+ order to find the owner and eventually the server that is
+ authoritative for the zone (which might accept dynamic updates).
+ Several recursive lookups may be required to find the longest prefix
+ that has been delegated. The DNS administrator must designate the
+ Primary Master Server for the longest match required. Once found,
+ the host sends dynamic AAAA and PTR updates using the concatenation
+ defined above ("hostname.customer.example.com").
+
+ In order to use this alternative, hosts must be configured to use
+ dynamic DNS. This is not default behavior for many hosts, which is
+ an inhibitor for a large ISP. This option may be scalable, although
+ registration following an outage may cause significant load, and
+ hosts using privacy extensions [RFC4941] may update records daily.
+ It is up to the host to provide matching forward and reverse records
+ and update them when the address changes.
+
+
+
+
+Howard Informational [Page 6]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+2.3.2. Dynamic DNS through Residential Gateways
+
+ Residential customers may have a gateway, which may provide DHCPv6
+ service to hosts from a delegated prefix. ISPs should provide a DNS
+ Recursive Name Server and Domain Search List to the gateway, as
+ described above and in [RFC3646] and [RFC8106]. There are two
+ options for how the gateway uses this information. The first option
+ is for the gateway to respond to DHCPv6 requests with the same DNS
+ Recursive Name Server and Domain Search List provided by the ISP.
+ The alternate option is for the gateway to relay dynamic DNS updates
+ from hosts to the servers and domain provided by the ISP. Host
+ behavior is unchanged; the host sends the same dynamic updates,
+ either to the ISP's server (as provided by the gateway) or to the
+ gateway for it to forward. The gateway would need to be capable of
+ and configured to use dynamic DNS.
+
+2.3.3. Automatic DNS Delegations
+
+ An ISP may delegate authority for a subdomain, such as
+ "customer12345.town.AW.customer.example.com" or
+ "customer12345.example.com", to the customer's gateway. Each domain
+ thus delegated must be unique within the DNS. The ISP may also then
+ delegate the IP6.ARPA zone for the prefix delegated to the customer,
+ as in (for 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA".
+ Then, the customer could provide updates to their own gateway, with
+ forward and reverse. However, individual hosts connected directly to
+ the ISP rarely have the capability to run DNS for themselves;
+ therefore, an ISP can only delegate to customers with gateways
+ capable of being authoritative name servers. If a device requests a
+ DHCPv6 Prefix Delegation, that may be considered a reasonably
+ reliable indicator that it is a gateway, rather than an individual
+ host. It is not necessarily an indicator that the gateway is capable
+ of providing DNS services and therefore cannot be relied upon as a
+ way to test whether this option is feasible. In fact, this kind of
+ delegation will not work for devices complying with [RFC6092], which
+ includes the requirement, "By DEFAULT, inbound DNS queries received
+ on exterior interfaces MUST NOT be processed by any integrated DNS
+ resolving server".
+
+ If the customer's gateway is the name server, it provides its own
+ information to hosts on the network, as described in [RFC2136], which
+ is often done for enterprise networks.
+
+ An ISP could provide authoritative responses as a secondary server to
+ the customer's master server. For instance, the home gateway name
+ server could be the master server, with the ISP providing the only
+ published NS authoritative servers.
+
+
+
+
+Howard Informational [Page 7]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+ To implement this alternative, users' residential gateways must be
+ capable of acting as authoritative name servers capable of dynamic
+ DNS updates. There is no mechanism for an ISP to dynamically
+ communicate to a user's equipment that a zone has been delegated, so
+ user action would be required. Most users have neither the equipment
+ nor the expertise to run DNS servers, so this option is unavailable
+ to the residential ISP.
+
+2.3.4. Generate Dynamic Records
+
+ An ISP's name server that receives a dynamic forward or reverse DNS
+ update may create a matching entry. Since a host capable of updating
+ one is generally capable of updating the other, this should not be
+ required, but redundant record creation will ensure that a record
+ exists. ISPs implementing this method should check whether a record
+ already exists before accepting or creating updates.
+
+ This method is also dependent on hosts being capable of providing
+ dynamic DNS updates, which is not default behavior for many hosts.
+
+2.3.5. Populate from DHCP Server
+
+ An ISP's DHCPv6 server may populate the forward and reverse zones
+ when the DHCP request is received if the request contains enough
+ information [RFC4704].
+
+ However, this method will only work for a single host address
+ (IA_NA); the ISP's DHCP server would not have enough information to
+ update all records for a prefix delegation. If the zone authority is
+ delegated to a home gateway that used this method, the gateway could
+ update records for residential hosts. To implement this alternative,
+ users' residential gateways would have to support the FQDN DHCP
+ option and would have to either have the zones configured or send
+ DDNS messages to the ISP's name server.
+
+2.3.6. Populate from RADIUS Server
+
+ A user may receive an address or prefix from a RADIUS server
+ [RFC2865], the details of which may be recorded via RADIUS Accounting
+ data [RFC2866]. The ISP may populate the forward and reverse zones
+ from the accounting data if it contains enough information. This
+ solution allows the ISP to populate data concerning allocated
+ prefixes as per Section 2.2 (wildcards) and customer premise
+ equipment (CPE) endpoints. However, as with Section 2.3.5, it does
+ not allow the ISP to populate information concerning individual
+ hosts.
+
+
+
+
+
+Howard Informational [Page 8]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+2.4. Delegate DNS
+
+ For customers who are able to run their own DNS servers, such as
+ commercial customers, often the best option is to delegate the
+ reverse DNS zone to them, as described in [RFC2317] (for IPv4).
+ However, since most residential users have neither the equipment nor
+ the expertise to run DNS servers, this method is unavailable to
+ residential ISPs.
+
+ This is a general case of the specific case described in
+ Section 2.3.3. All of the same considerations still apply.
+
+2.5. Dynamically Generate PTR When Queried ("On the Fly")
+
+ Common practice in IPv4 is to provide PTR records for all addresses,
+ regardless of whether a host is actually using the address. In IPv6,
+ ISPs may generate PTR records for all IPv6 addresses as the records
+ are requested. Several DNS servers are capable of this.
+
+ An ISP using this option should generate a PTR record on demand and
+ cache or prepopulate the forward (AAAA) entry for the duration of the
+ Time to Live of the PTR. Similarly, the ISP would prepopulate the
+ PTR following a AAAA query. To reduce exposure to a Denial-of-
+ Service attack, state or storage should be limited. Alternatively,
+ if an algorithm is used to generate a unique name, it can be employed
+ on the fly in both directions. This option has the advantage of
+ assuring matching forward and reverse entries while being simpler
+ than dynamic DNS. Administrators should consider whether the lack of
+ user-specified hostnames is a drawback. It may be possible to allow
+ user-specified hostnames for some records and generate others on the
+ fly; looking up a record before generating on the fly may slow
+ responses or may not scale well.
+
+ DNSSEC [RFC4035] signing records on the fly may increase load;
+ unsigned records can indicate that these records are less trusted,
+ which might be acceptable.
+
+ Another consideration is that the algorithm used for generating the
+ record must be the same on all servers for a zone. In other words,
+ any server for the zone must produce the same response for a given
+ query. Administrators managing a variety of rules within a zone
+ might find it difficult to keep those rules synchronized on all
+ servers.
+
+
+
+
+
+
+
+
+Howard Informational [Page 9]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+3. Manual User Updates
+
+ It is possible to create a user interface, such as a web page, that
+ would allow end users to enter a hostname to associate with an
+ address. Such an interface would need to be authenticated; only the
+ authorized user could add/change/delete entries. If the ISP changes
+ prefixes assigned to customers, the interface would need to specify
+ only the host bits. The backend would therefore need to be
+ integrated with prefix assignments so that when a new prefix was
+ assigned to a customer, the DNS service would look up user-generated
+ hostnames, delete the old record, and create the new one.
+
+ Considerations about some records being static and others dynamic or
+ dynamically generated (Section 2.5) and the creativity of users
+ (Section 5.5) still apply.
+
+4. Considerations and Recommendations
+
+ There are six common uses for PTR lookups:
+
+ Rejecting mail: A PTR with a certain string may indicate "This host
+ is not a mail server", which may be useful for rejecting probable
+ spam. The absence of a PTR leads to the desired behavior.
+
+ Serving ads: "This host is probably in town.province." An ISP that
+ does not provide PTR records might affect somebody else's geolocation
+ (also see privacy consideration about location).
+
+ Accepting SSH connections: The presence of a PTR may be inferred to
+ mean "This host has an administrator with enough clue to set up
+ forward and reverse DNS". This is a poor inference.
+
+ Log files: Many systems will record the PTR of remote hosts in their
+ log files to make it easier when reading logs later to see what
+ network the remote host uses.
+
+ Traceroute: The ability to identify an interface and name of any
+ intermediate node or router is important for troubleshooting.
+
+ Service discovery: [RFC6763] specifies "DNS-Based Service Discovery",
+ and Section 11 specifically describes how PTRs are used.
+
+ As a general guideline, when address assignment and name are under
+ the same authority, or when a host has a static address and name,
+ AAAA and PTR records should exist and match. For residential users,
+ if these use cases are important to the ISP, the administrator will
+ then need to consider how to provide PTR records.
+
+
+
+
+Howard Informational [Page 10]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+ The best accuracy would be achieved if ISPs delegated authority along
+ with address delegation, but residential users rarely have domain
+ names or authoritative name servers.
+
+ Dynamic DNS updates can provide accurate data, but there is no
+ standard way to indicate to residential devices where to send
+ updates, whether the hosts support DDNS, or whether it scales.
+
+ An ISP has no knowledge of its residential users' hostnames and
+ therefore can either provide a wildcard response or a dynamically
+ generated response. A valid negative response (such as NXDOMAIN) is
+ a valid response if the four cases above are not essential;
+ delegation where no name server exists should be avoided.
+
+5. Security and Privacy Considerations
+
+5.1. Using Reverse DNS for Security
+
+ Some people think the existence of reverse DNS records, or matching
+ forward and reverse DNS records, provides useful information about
+ the hosts with those records. For example, one might infer that the
+ administrator of a network with properly configured DNS records was
+ better informed, and by further inference more responsible, than the
+ administrator of a less thoroughly configured network. For instance,
+ most email providers will not accept incoming connections on port 25
+ unless forward and reverse DNS entries match. If they match, but
+ information higher in the stack (for instance, mail source) is
+ inconsistent, the packet is questionable. However, these records may
+ be easily forged unless DNSSEC or other measures are taken. The
+ string of inferences is questionable and may become unneeded if other
+ means for evaluating trustworthiness (such as positive reputations)
+ become predominant in IPv6.
+
+ Providing location information in PTR records is useful for
+ troubleshooting, law enforcement, and geolocation services, but for
+ the same reasons, it can be considered sensitive information.
+
+5.2. DNS Security with Dynamic DNS
+
+ The security considerations for using dynamic DNS are described in
+ [RFC3007]. DNS Security Extensions are documented in [RFC4033].
+
+ Interactions with DNSSEC are described throughout this document.
+
+
+
+
+
+
+
+
+Howard Informational [Page 11]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+5.3. Considerations for Other Uses of the DNS
+
+ Several methods exist for providing encryption keys in the DNS. Any
+ of the options presented here may interfere with these key
+ techniques.
+
+5.4. Privacy Considerations
+
+ Given the considerations in [RFC8117], hostnames that provide
+ information about a user compromise that user's privacy. Some users
+ may want to identify their hosts using user-specified hostnames, but
+ the default behavior should not be to identify a user, their
+ location, their connectivity, or other information in a PTR record.
+
+5.5. User Creativity
+
+ Though not precisely a security consideration, administrators may
+ want to consider what domain will contain the records and who will
+ provide the names. If subscribers provide hostnames, they may
+ provide inappropriate strings. Consider "ihate.example.com" or
+ "badword.customer.example.com" or
+ "celebrityname.committed.illegal.acts.example.com".
+
+6. IANA Considerations
+
+ This document has no IANA actions.
+
+7. References
+
+7.1. Normative References
+
+ [RFC1912] Barr, D., "Common DNS Operational and Configuration
+ Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996,
+ <https://www.rfc-editor.org/info/rfc1912>.
+
+ [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, DOI 10.17487/RFC2136, April 1997,
+ <https://www.rfc-editor.org/info/rfc2136>.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and
+ B. Wellington, "Secret Key Transaction Authentication for
+ DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
+ <https://www.rfc-editor.org/info/rfc2845>.
+
+
+
+
+
+
+
+Howard Informational [Page 12]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+ [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+ "Remote Authentication Dial In User Service (RADIUS)",
+ RFC 2865, DOI 10.17487/RFC2865, June 2000,
+ <https://www.rfc-editor.org/info/rfc2865>.
+
+ [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
+ DOI 10.17487/RFC2866, June 2000,
+ <https://www.rfc-editor.org/info/rfc2866>.
+
+ [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
+ Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
+ <https://www.rfc-editor.org/info/rfc3007>.
+
+ [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
+ Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
+ DOI 10.17487/RFC3646, December 2003,
+ <https://www.rfc-editor.org/info/rfc3646>.
+
+ [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>.
+
+ [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>.
+
+ [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
+ System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
+ <https://www.rfc-editor.org/info/rfc4592>.
+
+ [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
+ IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
+ Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
+ <https://www.rfc-editor.org/info/rfc4704>.
+
+ [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+ Address Autoconfiguration", RFC 4862,
+ DOI 10.17487/RFC4862, September 2007,
+ <https://www.rfc-editor.org/info/rfc4862>.
+
+ [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
+ Extensions for Stateless Address Autoconfiguration in
+ IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
+ <https://www.rfc-editor.org/info/rfc4941>.
+
+
+
+
+
+Howard Informational [Page 13]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+ [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
+ Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
+ <https://www.rfc-editor.org/info/rfc6763>.
+
+ [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
+ "IPv6 Router Advertisement Options for DNS Configuration",
+ RFC 8106, DOI 10.17487/RFC8106, March 2017,
+ <https://www.rfc-editor.org/info/rfc8106>.
+
+7.2. Informative References
+
+ [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless
+ IN-ADDR.ARPA delegation", BCP 20, RFC 2317,
+ DOI 10.17487/RFC2317, March 1998,
+ <https://www.rfc-editor.org/info/rfc2317>.
+
+ [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
+ Considerations and Issues with IPv6 DNS", RFC 4472,
+ DOI 10.17487/RFC4472, April 2006,
+ <https://www.rfc-editor.org/info/rfc4472>.
+
+ [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
+ Capabilities in Customer Premises Equipment (CPE) for
+ Providing Residential IPv6 Internet Service", RFC 6092,
+ DOI 10.17487/RFC6092, January 2011,
+ <https://www.rfc-editor.org/info/rfc6092>.
+
+ [RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname
+ Practice Considered Harmful", RFC 8117,
+ DOI 10.17487/RFC8117, March 2017,
+ <https://www.rfc-editor.org/info/rfc8117>.
+
+Acknowledgements
+
+ The author would like to thank Alain Durand, JINMEI Tatuya, David
+ Freedman, Andrew Sullivan, Chris Griffiths, Darryl Tanner, Ed Lewis,
+ John Brzozowski, Chris Donley, Wes George, Jason Weil, John Spence,
+ Ted Lemon, Stephan Lagerholm, Steinar Haug, Mark Andrews, Chris
+ Roosenraad, Fernando Gont, John Levine, and many others who discussed
+ and provided suggestions for this document.
+
+
+
+
+
+
+
+
+
+
+
+Howard Informational [Page 14]
+
+RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
+
+
+Author's Address
+
+ Lee Howard
+ Retevia
+ Fairfax, VA 22032
+ United States of America
+
+ Email: lee.howard@retevia.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard Informational [Page 15]
+