RFC 8501

Reverse DNS in IPv6 for Internet Service Providers

📅 published November 2018, from ietf

Reverse DNS in IPv6 for Internet Service Providers 🎀

Internet Engineering Task Force (IETF) 🌸 This doc is RFC 8501, and it's Informational, so it's published for info, not as a standard. ✨

  • Authors: L. Howard, Retevia 💅
  • Date: November 2018 🍓
  • ISSN: 2070-1721 🦋
  • Obsoletes/Updates: The title block doesn't list anything it obsoletes or updates, so it's just vibing on its own 💜

Abstract

okay so in IPv4, ISPs usually give their customers IN-ADDR.ARPA info by prefilling the zone with one PTR record for every single address 😭 That works in IPv4, but it does NOT scale in IPv6 💀 This doc looks at different approaches and things ISPs should think about when managing the IP6.ARPA zone 🧚

Status of This Memo

This doc is not an Internet Standards Track spec 🙈 It's published for informational purposes, bestie.

This doc is a product of the Internet Engineering Task Force (IETF) 🎀 It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶 Not everything the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 if you want the deets 💅

Info about the current status of this doc, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc8501 ✨

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date 📜 Please actually read these, because they're about your rights and restrictions for this doc 🙈 Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says 💜

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 ✨

okay so [RFC1912] recommended that "every Internet-reachable host should have a name" 🫶 It also 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" 😭 Is needing a PTR record that matches actually a good best practice? Honestly it's debatable 🤔 But some network services (see Section 4) still rely on PTR lookups, and some check the source address of incoming connections and verify that the PTR and A records match before they'll provide service 💅

Individual Internet users on the residential or consumer scale, including small and home businesses, are constantly connecting to the Internet or moving around on it 🌈 For big ISPs that serve residential users, keeping individual PTR records is just impractical 💀

So ISP admins should think about whether customer PTR records are needed 🎀 If they are, they should check out methods for responding to reverse DNS queries in IPv6 ✨

1.1. Reverse DNS in IPv4

ISPs that give access to lots of residential users usually assign one or a few IPv4 addresses to each of those users, then fill an IN-ADDR.ARPA zone with one PTR record for every IPv4 address 🍓 Some ISPs also set up forward zones with matching A records so lookups line up 🫶 For example, say an ISP called Example.com aggregated 192.0.2.0/24 at a network hub in one region. The reverse zone might look like this:

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 like this 🧚

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

Lots of ISPs generate PTR records for every IP address used for customers, and lots of them create the matching A record too 💖

1.2. Reverse DNS Considerations in IPv6

Here's a sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56:789a 🦋

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 often delegate an IPv6 prefix to their customers 🌸 Since 2^^80 possible addresses could be configured in a single /48 zone alone, writing a zone with every possible address in it is impractical, even with automation 😭 If you could write 1000 entries per second, the zone still wouldn't be complete after 38 trillion years 💀

Also, it's often impossible to associate hostnames with addresses 🙈 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 also that the administrator should "Make sure your PTR and A records match." 🎀 This section covers how to follow that advice for AAAA and PTR records 💅

2. Alternatives in IPv6

There are several options for providing reverse DNS in IPv6 🌈 All of these options also exist for IPv4, but the scaling problem is way less severe in IPv4 😌 Each option should be evaluated for its scaling ability, its compliance with existing standards and best practices, and its availability in common systems 🫶

2.1. Negative Response

Some ISP DNS admins may choose to give only an NXDOMAIN response to PTR queries for subscriber addresses 🙈 In some ways this is the most accurate response, since no name info is known about the host ✨ However, a negative response to PTR queries doesn't meet the expectation in [RFC1912] that entries match 😭 Users of services that depend on a successful lookup will have a rough experience. For example, some web services and Secure Shell (SSH) connections wait for a DNS response, even an NXDOMAIN, before responding 💀 So for the best user experience, it's important to return a response instead of timing out with no answer 🍓 On the flip side, external mail servers are likely to reject connections, which might be a win in the fight against spam 🫶

When evaluating this option, DNS admins should consider the uses for reverse DNS records and how many services affect 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] 🌈

Recording every possible address isn't scalable, but it may be possible to record a wildcard entry for each prefix assigned to a customer 🧚 Also keep in mind that "inclusion of wildcard NS RRSets in a zone is discouraged, but not barred". [RFC4592] 👀

This solution generally scales well 💖 But since the response matches any address in the wildcard range (/48, /56, /64, etc.), a forward DNS lookup on the response given won't be able to return the same hostname 😭 So this method fails the expectation in [RFC1912] that forward and reverse will match 💀 DNSSEC [RFC4035] scalability is limited to signing the wildcard zone, which might be satisfactory 🦋

2.3. Dynamic DNS

One way to make sure forward and reverse records match is for hosts to update DNS servers dynamically once interface configuration is complete. That can happen via SLAAC, DHCPv6, or other means, as described in [RFC4472] 🎀 Hosts would need to send both AAAA and PTR updates, and they'd need to know which servers would accept the info 🫶

This option should scale about as well as, or as poorly as, IPv4 dynamic DNS (DDNS) does 🤷‍♀️ Dynamic DNS may not scale well in big ISP networks that have no single master name server, but a single master server is not best practice 🙈 The ISP's DNS system may become a target for Denial-of-Service attacks, including lots of attempted DDNS updates 😱 Accepting updates only from authenticated sources may reduce that risk, but only if the authentication itself doesn't need excessive overhead 💅 No authentication of dynamic DNS updates is inherently provided 🚨 Implementers should therefore consider using TSIG [RFC2845], or at least ingress filtering, so updates are only accepted from customer address space coming from internal network interfaces 🔥 They should also rate limit the number of updates from a customer per second and think about the impacts on scalability ✨ UDP is allowed per [RFC2136], so connection reliability isn't assured. The host should still 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 🌸

Admins may want to consider user creativity if they provide hostnames, as described in Section 5.5, "User Creativity" 🌈

There's no assurance of uniqueness if multiple hosts try to update with the same name (mycomputer.familyname.org) 💀 There's also no standard way to tell a host which server it should send DDNS updates to. The master listed in the SOA is often assumed to be a DDNS server, but that may not scale 😭

2.3.1. Dynamic DNS from Individual Hosts 💖

Okay so, the simplest case is a residential user with ONE host plugged into the ISP, and that's it, bestie 🏠. The typical residential user cannot configure IPv6 addresses or resolving name servers on their hosts (literally who has time for that 💅), so the ISP should provide address information the usual way -- i.e., with their normal mix of Router Advertisements (RAs), DHCP, etc. ✨ The ISP should also hand out a DNS Recursive Name Server and a Domain Search List, as described in [RFC3646] or [RFC8106]. 🎀

Now, to figure out its Fully Qualified Domain Name (FQDN), a host will usually grab a domain from the Domain Search List. This is kind of an overloaded parameter, ngl 🙈. 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) before they turn this option on. For dynamic DNS purposes, the host smooshes its local hostname (e.g., "hostname") together with the domain(s) in the Domain Search List (e.g., "customer.example.com"), giving you "hostname.customer.example.com". Iconic naming, periodt 🌸

Once it learns its address and has a resolving name server, the host must perform an SOA lookup on the IP6.ARPA record it wants to add, so it can find the owner and eventually the server that's authoritative for the zone (the one that might accept dynamic updates 👑). Several recursive lookups may be needed to find the longest prefix that has been delegated. The DNS administrator must designate the Primary Master Server for the longest match required. Once that's found, the host sends dynamic AAAA and PTR updates using the concatenation from above ("hostname.customer.example.com"). Main character energy 🦋

Here's the catch: hosts must be configured to use dynamic DNS before any of this happens. That 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.

Wait, I need to be precise here: that last part is the only place "must" is about the host's behavior, and the original uses plain lowercase wording, so I'm keeping it that way. Vibes intact, facts intact 💜

2.3.2. Dynamic DNS through Residential Gateways 🌈

Residential customers may have a gateway, and that gateway 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, just like we covered above and in [RFC3646] and [RFC8106]. ✨

There are two options for how the gateway uses this info 🧚. The first option is for the gateway to respond to DHCPv6 requests with the same DNS Recursive Name Server and Domain Search List that the ISP provided. The alternate option is for the gateway to relay dynamic DNS updates from hosts to the servers and domain the ISP provided. Host behavior is unchanged (no drama 🫶): the host sends the same dynamic updates, either to the ISP's server (as provided by the gateway) or to the gateway, which forwards them. 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 delegated this way must be unique within the DNS. The ISP may also delegate the IP6.ARPA zone for the prefix given 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, so an ISP can only delegate to customers with gateways that are capable of being authoritative name servers. If a device requests a DHCPv6 Prefix Delegation, that may be considered a reasonably reliable indicator that it's a gateway rather than an individual host. It is not necessarily an indicator that the gateway can provide DNS services, though, and therefore it 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". Yikes, that's a hard no from the spec 💀

If the customer's gateway is the name server, it provides its own information to hosts on the network, as described in [RFC2136]. This 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. Co-hosting energy 🤝

To implement this alternative, users' residential gateways must be capable of acting as authoritative name servers that can do 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. Sad but true 🥺

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 that can update one is generally capable of updating the other, this should not be required, but redundant record creation will make sure that a record exists. ISPs implementing this method should check whether a record already exists before accepting or creating updates. Double-checking era ✨

This method also depends on hosts being capable of providing dynamic DNS updates, which, once again, 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. Bestie, it's a lot, but it's giving organized 📋

2.3.6. Populate from RADIUS Server 🦋

A user may receive an address or prefix from a RADIUS server [RFC2865], and the details of that 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 lets the ISP populate data about allocated prefixes, as per Section 2.2 (wildcards), and about customer premise equipment (CPE) endpoints. However, just like with Section 2.3.5, it does not let the ISP populate information about individual hosts. Limits, babe 🚧

2.4. Delegate DNS 🌸

For customers who are able to run their own DNS servers, such as commercial customers, the best option is often to delegate the reverse DNS zone to them, as described in [RFC2317] (for IPv4). Since most residential users have neither the equipment nor the expertise to run DNS servers, though, 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, no cap 🧠

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 doing this. It's a whole vibe 🌈

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 an 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, so it's lowkey iconic 👑. 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 it 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: 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. Sync or get cancelled 💀

3. Manual User Updates 🎀

It is possible to create a user interface, such as a web page, that would let end users enter a hostname to associate with an address. Such an interface would need to be authenticated, since 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. Seamless glow-up 🦋

Considerations about some records being static and others dynamic or dynamically generated (Section 2.5), and about the creativity of users (Section 5.5), still apply. ✨

4. Considerations and Recommendations ✨

Okay so there are six common uses for PTR lookups, and each one has its own vibe 🔍

  • 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. No PTR at all gets you the same result 🙅‍♀️
  • 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: Seeing 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, bestie 🙃
  • Log files: Many systems will record the PTR of remote hosts in their log files, so it's easier to read logs later and see what network the remote host uses 📖
  • Traceroute: Being able 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. It's giving planning 📋

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. Real talk, that's the tricky part 😩

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. So many open questions, no cap 🫠

An ISP has no knowledge of its residential users' hostnames, and therefore it 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, because that one's a no from me 🙅‍♀️💅

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. Bestie, don't trust the vibes alone 👀

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. Useful AND sensitive, so it's giving double-edged sword energy ⚔️

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. Keep your eyes peeled for those 👁️

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. So if you're doing key stuff, be careful, okay? 🔑

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. Privacy is literally the main character here 🎀🔒

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 these:

  • ihate.example.com
  • badword.customer.example.com
  • celebrityname.committed.illegal.acts.example.com

People are wildly creative, so plan ahead 💀

6. IANA Considerations 🌸

This document has no IANA actions. Nothing to register, no drama 💖

7. References 📚

7.1. Normative References

7.2. Informative References

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. Iconic squad, thank you all 🌈🫶

Author's Address 🖊️

Lee Howard
Retevia
Fairfax, VA  22032
United States of America

Email: lee.howard@retevia.net
📦 where this page comes from