2016-11-30
I suspect that lots of IPv6 hosts won't have reverse DNS
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 '76.103.17.172.red.sandbox', 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.
Terminals are not enough (sysadmin version)
In a comment on yesterday's entry, Evaryont asked a good question:
Have you thought about the usecase of Chromebooks not as a fully independent machine, but something more akin to a thin-client remote access device? [...]
(The difference between thin clients and Chromebooks is important, but I'll get to that later.)
Let us call such devices 'terminals', because that is what they are. In the old days terminals worked over serial lines (and still might support windows); in the modern day the Chromebook has a browser and a SSH client to handle your remote access needs.
Using terminals sounds attractive for many system administrators (and some developers); after all, we work on servers anyways, often off in some distant datacenter or cloud provider. Periodically someone gives it a good try and for some people it can even work reasonably well. However, my view is that terminals are not enough in the long run because the interface they give you is limited and narrow and cannot match the richness possible with genuine local computing.
(I'll assume that we don't care about working when you have no network connection or the servers are unavailable. If this is an issue then a terminal is not an option in the first place.)
In the concrete, the interface you can deliver through a web browser
doesn't match what you can do with a native client with full GUI
access. Part of this is because of necessary browser limitations, but part of this is because the browser
must work through a web server on the remote end; it can't easily
sit directly interacting with the system and the rest of the things
you're doing in the way that a graphical program working side by
side with the rest of your session can. 'Emacs in a browser' is
perhaps theoretically possible but is clearly much more awkward
under the hood than 'emacs file'. The same is even more true of
what you can do through a text terminal instead of a GUI.
(Remote desktop software doesn't solve this; instead it essentially turns your terminal into a display. What you really want is remote windows and even that is crucially dependent on a fast, low-latency network and a capable display and event protocol.)
More generally, a terminal is always going to make shared context harder and more awkward to create simply because that context is at the other end of things. Even with your terminal having multiple windows, you need a new login session or a new browser window or the like, and they have to be set up and established. I have an entire elaborate environment designed to make this really easy and it is still not as fluid as it is for local things (cf).
You can get a lot done through a terminal. It's not terrible. Much of the time you may not really notice what you're missing. But you are missing things, and every so often you'll run into the limits of what you can readily do by reaching through the narrow, constrained interface to the remote end that the terminal inevitably imposes on you simply by virtue of having a 'remote end'.
(This entry is purely from a work perspective for sysadmin work. For my personal use I have an additional separate set of views.)
PS: In the past I might have argued that terminals are also less customizable than true local computing. However, most people's local computing is getting less and less customizable all the time, so I no longer feel that this is a clearly winning argument in general. Something like my highly customized desktop environment and its special tools is clearly a far outlier today.
Sidebar: Thin clients versus terminals
The difference is simple: thin clients are really remote displays, not terminals. If the protocol is powerful and the connection fast enough, it's basically like being directly connected to the server. The obvious drawback is that it takes that powerful protocol and fast connection (and much more server resources). The less obvious drawback is that it's not at all obvious how to multiplex things so that you can sensibly connect to multiple servers at once.
Modern terminals like Chromebooks solve the multiplexing issue by being 'remote windows' instead of remote displays; each window or browser tab is a separate context and can be going to a different place. In Chromebooks et al, one of the drawbacks is that each browser 'remote window' is significantly less powerful than a full GUI program could be. This isn't a completely intrinsic drawback, as remote X over ssh sort of demonstrates.
(I believe that you can have a spirited discussion over whether any remote windowing protocol, X or otherwise, is up to the sophisticated demands of modern compositing OpenGL/3D interfaces with audio and synchronized double buffering and so on, or whether such remote protocols are intrinsically too slow and incapable of equaling local GUIs even for straightforward programs. I don't know enough about the state of the art to have an opinion.)