I suspect that lots of IPv6 hosts won't have reverse DNS

November 30, 2016

It's an article of faith that IPv4 hosts should mostly have valid reverse DNS and that good sysadmins (and people in general) should set this up for their hosts. While support for this is not exactly universal, it is reasonably common and many places have it. However, in light of my recent experiences with IPv6 I've come to believe that a significant number of IPv6 hosts will probably not have reverse DNS.

When I was thinking that IPv6 hosts would acquire addresses through DHCP(6), reverse DNS seemed as feasible for them as it does for IPv4 hosts that also use DHCP (although I had questions about what the names would be). It'd be somewhat more annoying to set up (because IPv6 PTR records are longer), but doable and even routine. But Android means that that's not really on, since Android (including Chromebooks) does not support DHCP6 at all; instead, hosts will acquire and use IPv6 SLAAC addresses, which means at least a couple of addresses per host, spread randomly and relatively unpredictably over your IPv6 PTR space. Worse, an increasing number of IPv6 hosts are likely to use temporary addresses for privacy reasons.

Given SLAAC and temporary addresses, it seems that the only particularly feasible reverse DNS for such IPv6 /64s is completely bland generic reverse DNS. At that point, why bother? The reverse DNS is serving almost no meaningful purpose apart from, well, having reverse DNS, and presumably you need special DNS servers that don't try to materialize all of those records in memory, just fill them in from a template when queried. (This has implications for your secondary DNS servers.)

(It's possible that some form of dynamic DNS could sort of fix this, but dynamic DNS is its own additional layer of complexity and I don't know if IPv6 hosts politely tell you what SLAAC IPv6 addresses they have decided to use so that you can add them to DNS on the fly.)

At this point, if someone at my ISP offered to delegate the necessary reverse DNS zone for my IPv6 /64 to me so that I could have proper reverse DNS for it, I would just laugh. Setting up and maintaining even entirely generic IPv6 reverse DNS would be too much of a hassle. I might someday have reverse DNS for a few static IPv6 addresses for things like my home Linux machine, but not for all of those SLAAC and temporary addresses from things on my home wireless network. And I doubt I'm going to be alone here.

(Possibly this is already obvious to anyone who has ever done much with IPv6. As you can tell, I'm just getting my feet wet here, mostly by throwing myself in the water when random new pieces of hardware show up instead of any systematic process of exploration and education.)

PS: In a real IPv6 deployment I'd still do reverse DNS for static IPv6 addresses. I think that this is useful internally, for the obvious reason that meaningful names are easier to recognize than addresses. If you're looking at internal logs, 'connection from <host X>' is obviously easier to follow and use than 'connection from <IPv6 address>', so it's worth some effort to get it.

Sidebar: Why generic reverse DNS is not very useful internally

The purpose of names is to give short, recognizable labels to things. Dynamically generated reverse DNS can sometimes do this, but generally only when it's relatively sparse and you can have names like 'dhcp0-NNN.red.sandbox' or 'unregistered-NNN.red.sandbox'. When you have to densely populate the reverse DNS namespace and generate names like '', the names are not really helping you very much.

All forms of SLAAC addresses are going to be relatively randomly distributed over your IPv6 /64; that's why you have to give SLAAC an entire /64. To make sure every randomly chosen, randomly distributed address has reverse DNS, you must densely populate the reverse DNS namespace, which means that you are not going to wind up with meaningful short labels. The label will just tell you what IPv6 address it has.

You can use generic reverse DNS for IPv6 addresses to tell you what network the IPv6 address is on. In this case the meaningful content of the name is actually the '.red.sandbox' part and you might as well have the hostname be as compact an encoding of the last /64 of the IPv6 address as possible.

Comments on this page:

The "de facto" reference DNS implementation (aka BIND) did not (and still does not) provide an easy way to do reverse dns for ipv6 (ala $GENERATE for ipv4). So for many years we've lived in a world where ipv6 addresses do not have PTR records.

As time went by, some people created solutions for this, like custom daemons written in perl (v6rev.pl), v6rev pipe backend for PowerDNS, synth-record in Knot DNS, but these are not the norm.

But if ISPs started putting these in use, they would actually be doing spammers a favour, by allowing them to use a gazillion of ipv6 addresses to spam.

M3AAWG Policy Issues for Receiving Email in a World with IPv6 Hosts and ESPs like Gmail (Bulk Senders Guidelines) recommend or even require PTR records in ipv6 in order to accept your mail.

So in fact, they assume that nobody will use solutions like v6rev or synth-record, and will only go as far as a handful of PTR records for servers that really need to send email, or otherwise be identified (e.g. a web server, a router etc).

I'm basically at the same point that you were in 2016-11, and I wonder if you ever solved that problem?

How can I get proper DNS entries for my IPv6 machines that use SLAAC?

(Btw, I tried to send you an e-mail, but your mail server said:

550 mail from host not accepted by <cks@utcc....
By cks at 2018-09-05 17:31:53:

We still haven't done anything with IPv6, so all of my thoughts here remain entirely theoretical and I haven't looked back into this area since I wrote this entry. In general I've come to think that machines that just SLAAC themselves onto the network present all sorts of challenges to the established way of doing things in IPv4 + DHCP networks, and sadly I have no idea how to deal with any of the issues.

(We need to deal with IPv6 someday, but for now we always seem to have higher priorities, partly because it's clearly going to be a lot of work, and currently there's little reward for it.)

Written on 30 November 2016.
« Terminals are not enough (sysadmin version)
IPv6, point to point links, and subnet lengths »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Nov 30 22:27:51 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.