Indeed IP6 and its large address space does bring additional challenges.
Some of the admin efficiency's that are doable in IP4 will no longer be
efficient or workable in IP6.
I had assumed you guys were running a more dynamic setup and a less
static file oriented bind arrangement and maybe generating/injecting
ptr's off the back of A and AAAA records. Under such a scripted dynamic
scheme, zones are not pre-populated and it becomes doable to have an
aliases list (db, file etc) to modify a pointer for specific addresses
and let the rest default to whatever you choose.
http://www.zytrax.com/books/dns/ch2/index.html#dyn-update
Pre-populating full ranges is a chew even for IP4. But I guess doable at
scale (with a bit of scripty) and depending on turnover not too
intensive to maintain.
Similarly creating fully pre-populated IP6 zones per customer just on
the off chance they are needed is crazy talk.
Going from a more static setup to a dynamic one, without killing
anything, is a major job, far too major for something as trivial as
aliasing/changing a reverse pointer for the odd customer. Useful as this
is for limited email serving.
It has been a long time since I looked into bind's dynamic
capabilities, for an educational ISP, in a previous life.
If "Get Carter" did sysadmin, I would be saying at this point that I am
a big guy and out of shape, but this is no longer my full time
occupation. LOL
Thanks for sorting out the default reverse lookups of the allocated
IP6's though, much appreciated.
Cheers
Kirbs
On 11/01/2019 15:09, Andy Smith wrote:
> Hello,
>
> 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.
>>
>> https://tools.bitfolk.com/redmine/issues/46
> 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:
>
> $ host ruminant.bitfolk.com
> ruminant.bitfolk.com has address 85.119.82.121
> ruminant.bitfolk.com has IPv6 address 2001:ba8:1f1:f004::2
>
> An automatic reverse DNS scheme might choose to return the reverse
> host name as something like:
>
> 2001-ba8-1f1-f004-0-0-0-2.autov6rev.bitfolk.com
>
> and would also then make sure that
> 2001-ba8-1f1-f004-0-0-0-2.autov6rev.bitfolk.com had an A record for
> 2001:ba8:1f1:f004::2.
>
> 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
> addresses¹.
>
> 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
> essentially does.
>
> 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
> went with.
>
> 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:
>
> https://tools.bitfolk.com/redmine/issues/176
>
> 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
> watcher.
>
> 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
> DNS.
>
> 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:
>
> https://tools.bitfolk.com/wiki/IPv6#Reverse_DNS
>
> That boils down to:
>
> - apt install bind9
>
> - write zone content somewhere like
> /var/lib/bind/4.0.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa
>
> - 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@??? 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.
>
> That's it.
>
> 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
> actually works.
>
> Cheers,
> Andy
>
> ¹ 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. :)
>
>
> _______________________________________________
> users mailing list
> users@???
> https://lists.bitfolk.com/mailman/listinfo/users
--
admins@???
www.sheffieldhackspace.org.uk
