On Thu, Jan 10, 2019 at 09:36:40PM +0000, admins wrote:
This I think is the nearest one to my observation.
Whilst it does not
say exactly what I am thinking it may actually be highlighting the
underlying issue as to why the situation is such.
If your goal is to run a mail server then automatic IPv6 reverse DNS
will only help you so much because it would generate some fixed
reverse DNS based only on the v6 address queried. For example, given
$ host ruminant.bitfolk.com
has address 126.96.36.199
has IPv6 address 2001:ba8:1f1:f004::2
An automatic reverse DNS scheme might choose to return the reverse
host name as something like:
and would also then make sure that
had an A record for
This will help you a little bit in that there is at least some
reverse DNS and it matches both ways, but ideally you want it to be
the real host name, i.e. ruminant.bitfolk.com
So for proper operation there is no way in escaping having to do a
real DNS zone.
After some speedy pointers from Andy, I found it easy
enough to change
the IP4 but there is no facility to do the IP6 record. The indicated
discussion on IP6 suggests running a primary DNS elsewhere to do it. But
this feels like overkill for a single pointer modification. Like what
the IP4 was.
"Elsewhere" can also be your VPS. It's really a very simple thing to
do; I could definitely set it up on a fresh Debian install in less
time than it's taken me to write this email. I do appreciate that
for someone who's never done it before it could seem intimidating.
Might be worth considering updating the web page and
capability to do
the same for the IP6 reverse pointer for the VPS as it does for the IP4
one. It does feel a bit inconsistent to be able to do one but not the other.
The thing is, IPv4 and IPv6 are very different for reverse DNS.
More than 98% of customers just have a single IPv4 address. It's
also possible to fully enumerate the IPv4 reverse zones, so I do:
those exist in files somewhere, one file for each /24 of IPv4 space
with a pre-generated PTR record in there.
And this is also really how we are forced to do it since you can't
easily delegate reverse IPv4 on less than a /24's worth of
If someone changes one of their addresses it's just a matter of
going through the correct file and substituting what is already
there with what they have chosen, and so that is what the Panel
But when it comes to IPv6, they can't be fully enumerated since each
customer has a /64, 2⁶⁴-1 (18,446,744,073,709,551,616) of them. It
has to be done another way.
The "other way" that is inherent in the design of DNS is delegation,
and it also happens to be the easiest way for us, so that's what we
I appreciate that what people actually want is what is easiest for
*them*: For us to maintain one IPv6 zone file per customer and add
and remove PTR records from it. Hopefully you can see that is very
different from how we handle IPv4 and would require the Panel also
to be quite different: instead of there being a fixed set of IP
addresses like there are with v4, there would need to be the ability
to add essentially endless numbers of entries.
I'm not saying it's impossible, I'm saying the suggestion that v4
and v6 can be handled consistently doesn't hold.
I don't think there is an existing issue in the tracker for this,
possibly because I've been so critical of it in the past. But there
probably should be, and despite being critical of it I will do it if
it's what people want. So:
Anyone interested in seeing that happen should log in and vote it
up. To be kept updated as to its progress, please add yourself as a
Meanwhile, the method that already exists and works is delegating
the v6 zone to the customer's own server(s). The reason why that is
easier on our side is that there is just one zone file to modify
(for the delegations), and there's only a simple web UI required for
managing the entries, each entry being a delegation, not a PTR.
Ultimately though not having the ip6 reverse lookup
pointer matching the
ip4 is something that in the grand scheme of things is something I will
not loose any sleep over, nor will I be running up a whole DNA service
to fix this one little thing.
If sending email out of a VPS, I would recommend *not* doing it by
IPv6 unless you set your IPv6 reverse DNS. It's usually quite easy
to tell the MTA to use a specific address to send out the email, so
if I wasn't going to set the v6 reverse DNS I'd recommend setting
the MTA to use only the single IPv4 address that has proper reverse
But I would encourage anyone who wants to set their own v6 reverse
DNS to at least give setting up their own DNS server a try. A
customer who already did it wrote instructions in the wiki:
That boils down to:
- apt install bind9
- write zone content somewhere like
- add zone declaration for
"4.0.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa" to /etc/bind/named.conf.local
- sudo systemctl reload bind9.service
- watch the logs
- test with local query:
$ dig -x 2001:ba8:1f1:f004::2 @localhost
- you could delegate the zone now, but you only have one nameserver.
Better would be to contact support(a)bitfolk.com and ask for the
zone to be mirrored on the BitFolk nameservers, so do that
- when that's all working, go to the Panel and delegate the zone to
your VPS and the three BitFolk nameservers, or just the BitFolk
ones if you're wanting to do hidden master.
It seems simpler than a lot of other things you've already done
on your VPS.
But it would be very good to have consistency.
It's also a lot of work, as there isn't consistency in how it
¹ Yes, I know there are tricks to do it, and we support them, but
given how few customers have more than 1 IPv4 address, customers
tend to prefer to just set them directly.
² I expect there is some place I am sending out email from a v6
address with no reverse DNS, but if there is then this is an
oversight that I would like to know about. :)
-- No-nonsense VPS hosting