Rick,
If you could please, and would be willing, could you cover DNS slave services for BALUG, notably these zones: e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa balug.org master(s) (all for each of the above): 198.144.194.238 2001:470:1f04:19e::2 Do note, however, that at present time, balug.org is NOT (yet) Internet delegated to those IPs - I don't expect that to happen until we extricate ourselves from DreamHost.com - however in the meantime it is maintained quite highly alike to the balug.org. DNS data on DreamHost.com - I check periodically, and only differences I'm aware of are SOA MNAME, RNAME, and often the REFRESH (I don't know where they get their REFRESH number from - it seems to vary some fair bit, with no particular discernible pattern) and I tend to keep the serial # one ahead of DreamHost.com (at least most of the time when I check/notice it). If you'd prefer, for balug.org, could also just set up as "warm standby" - verify (to-be) slaves can do AXFR pull, and put most of the configuration in place, but just don't actually activate it until DNS is fully and properly Internet delegated (or we're free from DreamHost.com and about to so delegate).
I'm presuming you could do/offer this on both ns1.linuxmafia.com. and also ns1.svlug.org.? That would be great, if you're able to.
I'm also presuming the various IP information and out-of-band communication information is still the same as when we set up slaves for sf-lug.org (plus any relevant updates received since then).
Just let me know, thanks (can also email just me directly for any bits that ought not get publicly archived, etc.).
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
If you could please, and would be willing, could you cover DNS slave services for BALUG, notably these zones: e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa balug.org master(s) (all for each of the above): 198.144.194.238 2001:470:1f04:19e::2 Do note, however, that at present time, balug.org is NOT (yet) Internet delegated to those IPs - I don't expect that to happen until we extricate ourselves from DreamHost.com - however in the meantime it is maintained quite highly alike to the balug.org. DNS data on DreamHost.com - I check periodically, and only differences I'm aware of are SOA MNAME, RNAME, and often the REFRESH (I don't know where they get their REFRESH number from - it seems to vary some fair bit, with no particular discernible pattern) and I tend to keep the serial # one ahead of DreamHost.com (at least most of the time when I check/notice it). If you'd prefer, for balug.org, could also just set up as "warm standby" - verify (to-be) slaves can do AXFR pull, and put most of the configuration in place, but just don't actually activate it until DNS is fully and properly Internet delegated (or we're free from DreamHost.com and about to so delegate).
I'm presuming you could do/offer this on both ns1.linuxmafia.com. and also ns1.svlug.org.? That would be great, if you're able to.
I'm also presuming the various IP information and out-of-band communication information is still the same as when we set up slaves for sf-lug.org (plus any relevant updates received since then).
Yes and yes.
Please be advised that I'm in Sydney, NSW, Australia through tonight (it being 10:28 PM, here), and will be taking an extremely looooong flight tomorrow (Saturday the 20th), arriving back very exhausted, jet-lagged, and with incredibly huge amounts of unread e-mail and backlogged tasks when I arrive home late Saturday. So, I may not be able to carry out any promised actions for a few days after that.
Will advise.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Rick,
If you could please, and would be willing, could you cover DNS slave services for BALUG, notably these zones: e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa balug.org master(s) (all for each of the above): 198.144.194.238 2001:470:1f04:19e::2
Functioning on linuxmafia.com:
[rick@linuxmafia] /tmp $ dig -t soa @ns1.linuxmafia.com e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa +short ns1.balug.org. postmaster.balug.org. 1455810227 10800 3600 1209600 3600 [rick@linuxmafia] /tmp $ dig -t soa @ns1.linuxmafia.com balug.org +short ns1.balug.org. hostmaster.balug.org. 2016021902 20881 1800 1814400 14400 [rick@linuxmafia] /tmp $
Functioning on ns1.svlug.org:
root@gruyere:/etc/nsd3 # dig -t soa @ns1.svlug.org balug.org +short ns1.balug.org. hostmaster.balug.org. 2016021902 20881 1800 1814400 14400 root@gruyere:/etc/nsd3 # dig -t soa @ns1.svlug.org e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa +short ns1.balug.org. postmaster.balug.org. 1455810227 10800 3600 1209600 3600 root@gruyere:/etc/nsd3 #
Rick,
Looks excellent, thanks!
Also checked propagation with SERIAL bump.
e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa - fully and properly delegated
balug.org - slaves check out fine, full and final Internet delegation pending BALUG extrication/exodus from DreamHost.com
$ dig -t NS e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa +trace 2>&1 |
fgrep -e ' IN NS ' -e ';; Received ' | tail -n 11
;; Received 391 bytes from 63.243.194.2#53(v.arin.net) in 18 ms e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS ns1.balug.org. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS ns0.mpaoli.net. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS ns1.linuxmafia.com. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 4900 IN NS ns1.svlug.org. ;; Received 180 bytes from 216.218.131.2#53(ns2.he.net) in 20 ms e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN NS ns1.svlug.org. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN NS ns0.mpaoli.net. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN NS ns1.balug.org. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN NS ns1.linuxmafia.com. ;; Received 256 bytes from 198.144.195.186#53(ns1.linuxmafia.com) in 71 ms $ (for ns in $(dig -t NS e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. \
+short); do for ip in $(dig +short "$ns" A "$ns" AAAA); do echo $(dig \ @"$ip" -t SOA e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. +short \ +norecurse) "[$ip $ns]"; done; done)
ns1.balug.org. postmaster.balug.org. 1456011000 10800 3600 1209600 3600 [198.144.195.186 ns1.linuxmafia.com.] ns1.balug.org. postmaster.balug.org. 1456011000 10800 3600 1209600 3600 [198.144.194.238 ns1.balug.org.] ns1.balug.org. postmaster.balug.org. 1456011000 10800 3600 1209600 3600 [2001:470:1f04:19e::2 ns1.balug.org.] ns1.balug.org. postmaster.balug.org. 1456011000 10800 3600 1209600 3600 [64.62.190.98 ns1.svlug.org.] ns1.balug.org. postmaster.balug.org. 1456011000 10800 3600 1209600 3600 [198.144.194.235 ns0.mpaoli.net.] ns1.balug.org. postmaster.balug.org. 1456011000 10800 3600 1209600 3600 [2001:470:66:76f::2 ns0.mpaoli.net.] $ (for ns in ns1.balug.org. ns1.linuxmafia.org. ns1.svlug.org.; do for \
ip in $(dig +short "$ns" A "$ns" AAAA); do echo $(dig @"$ip" -t SOA \ balug.org. +short +norecurse) "[$ip $ns]"; done; done)
ns1.balug.org. postmaster.balug.org. 2016022000 20881 1800 1814400 14400 [198.144.194.238 ns1.balug.org.] ns1.balug.org. postmaster.balug.org. 2016022000 20881 1800 1814400 14400 [2001:470:1f04:19e::2 ns1.balug.org.] ns1.balug.org. postmaster.balug.org. 2016022000 20881 1800 1814400 14400 [64.62.190.98 ns1.svlug.org.] $
From: "Rick Moen" rick@linuxmafia.com Subject: Re: DNS slaves for BALUG? :-) Date: Sat, 20 Feb 2016 12:59:25 -0800
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Rick,
If you could please, and would be willing, could you cover DNS slave services for BALUG, notably these zones: e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa balug.org master(s) (all for each of the above): 198.144.194.238 2001:470:1f04:19e::2
Functioning on linuxmafia.com:
[rick@linuxmafia] /tmp $ dig -t soa @ns1.linuxmafia.com e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa +short ns1.balug.org. postmaster.balug.org. 1455810227 10800 3600 1209600 3600 [rick@linuxmafia] /tmp $ dig -t soa @ns1.linuxmafia.com balug.org +short ns1.balug.org. hostmaster.balug.org. 2016021902 20881 1800 1814400 14400 [rick@linuxmafia] /tmp $
Functioning on ns1.svlug.org:
root@gruyere:/etc/nsd3 # dig -t soa @ns1.svlug.org balug.org +short ns1.balug.org. hostmaster.balug.org. 2016021902 20881 1800 1814400 14400 root@gruyere:/etc/nsd3 # dig -t soa @ns1.svlug.org e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa +short ns1.balug.org. postmaster.balug.org. 1455810227 10800 3600 1209600 3600 root@gruyere:/etc/nsd3 #
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
If you could please, and would be willing, could you cover DNS slave services for BALUG, notably these zones: e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa balug.org master(s) (all for each of the above): 198.144.194.238 2001:470:1f04:19e::2
FYI, ns1.linuxmafia.com is repeatedly logging this:
Feb 20 17:50:45 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled
I'm unsure why the AXFR/IXFR to the IPv6 address fails, and currently lack the time and patience to pursue that matter. For now, I'm going to disable that master IP on my BIND9 conffile.
I wrote:
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
If you could please, and would be willing, could you cover DNS slave services for BALUG, notably these zones: e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa balug.org master(s) (all for each of the above): 198.144.194.238 2001:470:1f04:19e::2
FYI, ns1.linuxmafia.com is repeatedly logging this:
Feb 20 17:50:45 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled
I'm unsure why the AXFR/IXFR to the IPv6 address fails, and currently lack the time and patience to pursue that matter. For now, I'm going to disable that master IP on my BIND9 conffile.
Before I do that, Michael, would you like to any some checking on the _master_ nameserver end? The most probable explanation is some deficiency in IPv6 support on ns1.linuxmafia.com, and that would be my default assumption.
FYI, both zones are affected:
linuxmafia:/etc/bind# zgrep 'failure trying master' /var/log/* /var/log/daemon.log:Feb 20 12:55:59 linuxmafia named[17291]: zone balug.org/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/daemon.log:Feb 20 13:39:16 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/daemon.log:Feb 20 17:50:45 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/syslog:Feb 20 12:55:59 linuxmafia named[17291]: zone balug.org/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/syslog:Feb 20 13:39:16 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/syslog:Feb 20 17:50:45 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled linuxmafia:/etc/bind#
No problem, I'll take a look, and let you know what I find.
Quite likely it's lack of IPv6 or some other IPv6 issue on slave end(s), but I'll do some further checking to see if I can isolate it to that (at least for ns1.linuxmafia.com. - I'm presuming same/similar for ns1.svlug.org.), and see whether or not zone can be pulled via IPv6 - and beyond the IPv6 addresses where I've done so on my home networks (all of which happen to be via same ISP for IPv6 - so would be good to check from some other(s) - I think I may have a location or two (or three or more?) that I may be able to check that from).
Thanks, I'll let you know.
From: "Rick Moen" rick@linuxmafia.com Subject: Re: [BALUG-Admin] DNS slaves for BALUG? :-) Date: Sat, 20 Feb 2016 18:33:09 -0800
I wrote:
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
If you could please, and would be willing, could you cover DNS slave services for BALUG, notably these zones: e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa balug.org master(s) (all for each of the above): 198.144.194.238 2001:470:1f04:19e::2
FYI, ns1.linuxmafia.com is repeatedly logging this:
Feb 20 17:50:45 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled
I'm unsure why the AXFR/IXFR to the IPv6 address fails, and currently lack the time and patience to pursue that matter. For now, I'm going to disable that master IP on my BIND9 conffile.
Before I do that, Michael, would you like to any some checking on the _master_ nameserver end? The most probable explanation is some deficiency in IPv6 support on ns1.linuxmafia.com, and that would be my default assumption.
FYI, both zones are affected:
linuxmafia:/etc/bind# zgrep 'failure trying master' /var/log/* /var/log/daemon.log:Feb 20 12:55:59 linuxmafia named[17291]: zone balug.org/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/daemon.log:Feb 20 13:39:16 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/daemon.log:Feb 20 17:50:45 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/syslog:Feb 20 12:55:59 linuxmafia named[17291]: zone balug.org/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/syslog:Feb 20 13:39:16 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/syslog:Feb 20 17:50:45 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled linuxmafia:/etc/bind#
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
No problem, I'll take a look, and let you know what I find.
Quite likely it's lack of IPv6 or some other IPv6 issue on slave end(s)....
Quite so.
I have a very vague recollection of (possibly) having deliberately disabled IPv6 in the system network stack -- on the excellent grounds that I'm making no use of it, and network functions you're not using should be disabled as part of a comprehensive security policy.
FWIW, I cannot find where I did that (if I did that). I find nothing in /etc/sysctl.conf (there being nothing in /etc/sysctl.d/ , and nothing in /etc/modprobe.d/aliases.conf .
Actually, /etc/modprobe.d/aliases.conf.dpkg-old has 'alias net-pf-10 off' , but /etc/modprobe.d/aliases.conf does not.
If it turns out that this is an IPv6 issue on slave end, then I'd suggest leaving it until my linuxmafia.com rebuild.
I'm frankly, really not sold on the utility of IPv6 for the linuxmafia.com host at this time. There are no relevant use-cases for which it's required. Therefore, I might _even_ deliberately disable it on the rebuilt host (whether it is on the current host or not).
That is, I tend to strongly concur with the standard advice that if you aren't using a network service, you should shut it off. IPv6 is a network service (in effect, or an additional flavour of existing services). As http://www.esecurityplanet.com/security-how-to/Linux-Hardening---Quick-Wins-... puts it:
Disable IPv6: Unless you know that you need it, disabling IPv6 is a good idea as it is hard to monitor, making it attractive for hackers, and it's also hard to spot security vulnerabilities in the protocol.
Hmmm, was thinking to perhaps take this else-list (it's more general that "just" BALUG administrivia) ... but I'll probably put a mention/pointer on the "talk" list a bit later, as there's mix of BALUG administrivia stuff ... and also some Linux tech stuff that may be of more general interest, among several of these BALUG-Admin list postings.
Anyway, my comment/reply bits in-line below.
From: "Rick Moen" rick@linuxmafia.com Subject: Re: [BALUG-Admin] DNS slaves for BALUG? :-) ... IPv6 issue somewhere between master and slaves? Date: Sat, 20 Feb 2016 19:59:11 -0800
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Quite likely it's lack of IPv6 or some other IPv6 issue on slave end(s)....
Quite so.
I have a very vague recollection of (possibly) having deliberately disabled IPv6 in the system network stack -- on the excellent grounds that I'm making no use of it, and network functions you're not using should be disabled as part of a comprehensive security policy.
Yes, IPv6 can be quite disabled on Linux operating systems, if one so chooses. In what bit I observed (have a post to put up in response to my earlier posting), doesn't look like IPv6 was disabled on linuxmafia.com - nor is it explicitly enabled. That gives one relatively default, dual stack, have link-local IPv6 (can talk to other IPv6 on same subnet/LAN), but no routable IPv6 - a semi-reasonable default compromise between absolute security and absolute convenience. If even more fully default (and possibly also newer), it might auto-configure for routable IPv6 - if that were offered by resources on the network - but I'm guestimating that wouldn't apply to linuxmafia.com., as it's more generally configured for static IP(s) on physical interfaces - so likely nothing there set/configured to auto-configure ... beyond possibly the non-routable link-local.
Short of totally disabling IPv6, a step that might be more useful - instead totally disable IPv6 on any and all physical interfaces, but leave the IPv6 stack in place. Two specific advantages I think of for that - in addition to giving most of the security benefits of totally disabling IPv6. Fair bit more convenience - much software these days, and especially for Linux, will presume the host is dual-stack - even if it doesn't have any IPv6 Internet routable connectivity (or ditto for IPv4). Much such software will malfunction if installed/used - at least with its default configuration, if the host doesn't even have IPv6 stack enabled - at least until one reconfigures such software to completely and totally not use IPv6 at all. Another advantage of not disabling the IPv6 stack totally - future-testing and development, etc. E.g. one could do purely local testing of IPv6 - including also (if/when applicable) between virtual machine and physical host. That could be advantageous in developing/testing IPv6 before rolling it out "for real" to Internet accessible routable usage of IPv6.
FWIW, I cannot find where I did that (if I did that). I find nothing in /etc/sysctl.conf (there being nothing in /etc/sysctl.d/ , and nothing in /etc/modprobe.d/aliases.conf .
Yes ... I think (if I recall correctly) in newer kernels, IPv6 may no longer be a module? - but I'm not certain about that (reminds me of another point on modules - but for another posting and list/thread). In any case, through the /proc filesystem (or /sys?) and /etc/sysctl.conf or the like, one can, among other things, disable IPv6, including totally and completely, or on per-interface basis. I'm not sure, but there may also be means/options, to have it default to being disabled, yet then allow it to be enabled on a per-interface basis. And keep in mind interfaces may be physical, or virtual (e.g. loopback interface, interfaces between physical and virtual machines, etc.)
Actually, /etc/modprobe.d/aliases.conf.dpkg-old has 'alias net-pf-10 off' , but /etc/modprobe.d/aliases.conf does not.
If it turns out that this is an IPv6 issue on slave end, then I'd suggest leaving it until my linuxmafia.com rebuild.
Yep, probably mostly easier to not muck about with IPv6 on linuxmafia.com until it's more current on the operating system software version updates (e.g. to state that's both well supported on security updates and also will continue to be supported for many months or more to come).
I'm frankly, really not sold on the utility of IPv6 for the linuxmafia.com host at this time. There are no relevant use-cases for which it's required. Therefore, I might _even_ deliberately disable it on the rebuilt host (whether it is on the current host or not).
Context. :-) Yes, I agree, I see no requirement or (pressing?) need for IPv6 on linuxmafia.com. The answer to same question may be at least somewhat different in 6 months, a year, 2 years, 5 years, ... but I see no rush or pressing need to bring IPv6 to linuxmafia.com.
That is, I tend to strongly concur with the standard advice that if you aren't using a network service, you should shut it off. IPv6 is a network service (in effect, or an additional flavour of existing services). As http://www.esecurityplanet.com/security-how-to/Linux-Hardening---Quick-Wins-... puts it:
Disable IPv6: Unless you know that you need it, disabling IPv6 is a good idea as it is hard to monitor, making it attractive for hackers, and it's also hard to spot security vulnerabilities in the protocol.
Well, I think I'd be inclined to temper and update a statement like that. While still quite true about "unneeded network services", A) IPv6 is increasingly in use - "needed" may be just a matter of time B) "hard to monitor" and such - I think many/most of those objections can probably be dispensed with at this time. I don't think monitoring IPv6 is really any harder than doing likewise for IPv4 ... but yes, sure, it is "one more thing" to monitor, etc. "Of course" some day, getting rid of "one more thing" to monitor, may well entail turning off IPv4. ;-> ... but that day is still some fair ways off yet (guestimating maybe about a decade or so?)
Random: already encountering some environments that are mandating IPv6 only - at least for anything at/to/beyond physical interface and possibly also link-local. Of course one is likely also aware, getting Internet routable IPv4 addresses is becoming increasingly difficult/costly. I'll also mention that NAT/SNAT tends to complicate a lot of things (like troubleshooting, and security and related accountability) - with IPv6 one mostly can kiss NAT/SNAT goodbye.
So ... wee bit of reference introduction, then my tests/findings/recommendations/etc., then more of the earlier referenced bits.
From: "Michael Paoli" Michael.Paoli@cal.berkeley.edu Subject: Re: [BALUG-Admin] DNS slaves for BALUG? :-) ... IPv6 issue somewhere between master and slaves? Date: Sat, 20 Feb 2016 18:52:14 -0800
No problem, I'll take a look, and let you know what I find.
Quite likely it's lack of IPv6 or some other IPv6 issue on slave end(s), but I'll do some further checking to see if I can isolate it to that (at least for ns1.linuxmafia.com. - I'm presuming same/similar for ns1.svlug.org.), and see whether or not zone can be pulled via IPv6 - and beyond the IPv6 addresses where I've done so on my home networks (all of which happen to be via same ISP for IPv6 - so would be good to check from some other(s) - I think I may have a location or two (or three or more?) that I may be able to check that from).
Thanks, I'll let you know.
So ... most of the testing details first. Then past that section, recommendations for the very specific slaves in question - based upon those test results. Then there's bit more information/comments after that. And then a wee bit more additional testing.
$ dig +short ns1.linuxmafia.com. A ns1.linuxmafia.com. AAAA 198.144.195.186 $ ssh -ax linuxmafia.com. 'umask 077 && hostname &&
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin:"$PATH" \ && { { >>/dev/null 2>&1 type ip && ip -4 a s; ip -6 a s; ip -6 r s; \ } || { ifconfig -a; netstat -nr; } }'
linuxmafia.com 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN inet 127.0.0.1/8 scope host lo 3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 inet 198.144.195.186/29 brd 198.144.195.191 scope global eth2 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 fe80::220:edff:fe13:ba89/64 scope link valid_lft forever preferred_lft forever fe80::/64 dev eth2 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 $
So ... [ns1.]linuxmafia.com. has an IPv6 stack and IPv6 link-local apparently configured, but no IPv6 route for anything beyond link-local and localhost. Let's see if I can confirm that ...
$ ssh -ax linuxmafia.com. 'umask 077 && hostname && \
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin:"$PATH" \ && ping6 -n -c 5 2001:470:1f04:19e::2'
linuxmafia.com connect: Network is unreachable $
Yes, can't get to 2001:470:1f04:19e::2 from [ns1.]linuxmafia.com. 198.144.195.186 ::1/128 fe80::/64 without some type of route to 2001:470:1f04:19e::2 from that host. the: connect: Network is unreachable probably indicates we're getting an ICMP network unreachable, probably from the host itself, as it has no available route to get to 2001:470:1f04:19e::2 The diagnostic bit(s): failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled would be, I'd guess, the nameserver's software's way of indicating it can't get to there or is otherwise failing - the "(source ::#0)" may be some kind of hint as to source IP that it's trying from or that it's trying that from IPv6, and knows not how to get there, or fails from that source IP, or IPv6 in general. Let me see if I can pull the zone via IPv6 to elsewhere ...
$ ip -6 a s | fgrep inet6; ip -6 r s | fgrep via inet6 ::1/128 scope host inet6 fe80::221a:6ff:fe03:c207/64 scope link inet6 2001:470:66:76f::2/64 scope global inet6 fe80::c690:c2eb/64 scope link inet6 fe80::fc54:ff:fe13:5199/64 scope link default via 2001:470:66:76f::1 dev he-ipv6 metric 1024 $ dig @2001:470:1f04:19e::2 -t AXFR \
e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. +norecurse +noall +nocmd \ +nocomments +answer | grep '^[ ]*[^ ;]'
e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN SOA ns1.balug.org. postmaster.balug.org. 1456011000 10800 3600 1209600 3600 e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN NS ns0.mpaoli.net. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN NS ns1.balug.org. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN NS ns1.svlug.org. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN NS ns1.linuxmafia.com. 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN PTR balug.org. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN SOA ns1.balug.org. postmaster.balug.org. 1456011000 10800 3600 1209600 3600 $
Yes, I'm able to pull the zone (master is specifically configured: allow-transfer { any; }; for at least the [L]UG zone(s) - and that includes e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. but the client IPv6 I pulled from is from same ISP/provider as the server pulled from. Do I have another IPv6 independent of that ISP that I can check from?
$ ssh -ax m-net.arbornet.org. hostname ssh: connect to host m-net.arbornet.org. port 22: No route to host $ Hmmmm... $ (cd ~/tmp && stat -c '%y %n' .m-net.arbornet.org* && cat
.m-net.arbornet.org.lastlogin)
2016-02-10 00:05:03.690977780 -0800 .m-net.arbornet.org.lastlogin michaelp pts/7 Feb 10 03:05 (198.144.194.235) Connection to m-net.arbornet.org. closed. $ I've got a crontab job:
$ crontab -l | fgrep m-net.arbornet.org | grep -v '^#' 5 8 * * * TZ=PST8PDT export TZ; set -e; trap 'trap - 0; exit 0' 0; exec </dev/null >>/dev/null 2>&1; cd tmp; lastlogin=.m-net.arbornet.org.lastlogin lastoutput=.m-net.arbornet.org.lastoutput; set +e; tmp=`find "$lastlogin" -prune ! -mtime +15 -type f -print`; [ x"$tmp" = x"$lastlogin" ] || { </dev/null >"$lastoutput" 2>&1 ssh -a -n -t -t -x -o BatchMode=yes m-net.arbornet.org. 'umask 077 && exec who am I' && mv -f "$lastoutput" "$lastlogin"; } $
that keeps my account there from going away (I think it has to be logged into once every 30 days to not get removed). My crontab job, daily, makes a login attempt if its last successful login was more than 15 days ago. Looks like it worked rather recently ... but not working at the moment.
So, another ISP's IPv6 ... ignore some of the despicable operating system bits below ... but at least with Cygwin it's almost bearable ... testing from a work connection (hey, fair's fair, often use home connections from work to do work to, e.g. test various accessibility from The Internet, etc.) ...
$ IPCONFIG /ALL | fgrep IPv6\ Address | fgrep -v Link-local IPv6 Address. . . . . . . . . . . : 2600:1010:b161:5e74:7c7a:2cff:fe94:2fa1(Preferred) $ dig @2001:470:1f04:19e::2 -t AXFR \
e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. +norecurse +noall +nocmd \ +nocomments +answer | grep '^[ ]*[^ ;]'
/usr/src/ports/bind/bind-9.10.2-2.P2.x86_64/src/bind-9.10.2-P2/lib/isc/unix/socket.c:2867: setsockopt(20, IPV6_RECVTCLASS) failed: Invalid argument e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN SOA ns1.balug.org. postmaster.balug.org. 1456011000 10800 3600 1209600 3600 e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN NS ns0.mpaoli.net. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN NS ns1.balug.org. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN NS ns1.svlug.org. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN NS ns1.linuxmafia.com. 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN PTR balug.org. e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. 7200 IN SOA ns1.balug.org. postmaster.balug.org. 1456011000 10800 3600 1209600 3600 $
Okay, enough of that, ... set *that* operating system aside ... now back to a *real* operating system :-> ... And to look at ISPs to see/show they're different, at least to the extent can check with whois(1), we have ... First the master:
$ 2>&1 whois -H 2001:470:1f04:19e::2 |
egrep -i '^(netname|nethandle|netrange|cidr|organization)'
NetRange: 2001:470:: - 2001:470:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2001:470::/32 NetName: HURRICANE-IPV6 NetHandle: NET6-2001-470-1 Organization: Hurricane Electric, Inc. (HURC) $
Then the first global routable IPv6 I tried from (expecting same ISP in whois):
$ 2>&1 whois -H 2001:470:66:76f::2 |
egrep -i '^(netname|nethandle|netrange|cidr|organization)'
NetRange: 2001:470:: - 2001:470:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2001:470::/32 NetName: HURRICANE-IPV6 NetHandle: NET6-2001-470-1 Organization: Hurricane Electric, Inc. (HURC) $
No surprises there - it's also part of same NetRange / CIDR, as we can see in even the first set of whois data. And last client I tried, I'm hoping/expecting different ISP (is a big telecom company after all) ...
$ 2>&1 whois -H 2600:1010:b161:5e74:7c7a:2cff:fe94:2fa1 |
egrep -i '^(netname|nethandle|netrange|cidr|organization)'
NetRange: 2600:1000:: - 2600:1017:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2600:1010::/29, 2600:1000::/28 NetName: WIRELESSDATANETWORK NetHandle: NET6-2600-1000-1 Organization: Cellco Partnership DBA Verizon Wireless (CLLC) $
And yes, an ISP, that as far as I'm aware, is quite independent of the other ISP shown for the two other IPv6 addresses.
So ... recommendations ... I'm not sure what DNS slave server software is in use but for the masters, if the IPv6 addresses are listed after IPv4 (which may already be the case) and it still complains, my recommendation would be to comment out or otherwise disable the IPv6 master address(es) until such time as the slave hosts have some type of routable Internet IPv6 connectivity.
$ dig +short ns1.svlug.org. A ns1.svlug.org. AAAA 64.62.190.98 $
I'd guess issue is same for ns1.svlug.org. - I don't see any IPv6 addresses there, but I don't have access to the host, as far as I'm aware, so am not in position to test more fully from that slave host. So, if same or quite similar applies to that slave host, then same recommendation would apply.
I'm also guestimating, the DNS slave server software likely checks *all* masters - I'd expect that - probably starts with SOA, and then grabs "highest" (per the DNS RFCs) SOA serial number zone successfully found from master it successfully did SOA query on. It may or may not have some fallback to try AXFR if SOA fails, or if SOA succeeds but AXFR fails, there's probably some retry/failover algorithm it uses among the master(s) configured for that slave for that zone. So, it probably at least *tries* all configured masters, and depending upon the software, and possible configuration and logging levels, it may complain for any it fails to get the data from, or I'd think at least most minimally, if it failed with all masters - but I'm guessing it would more likely complain if it failed with *any* of the masters, as one may generally want to at least minimally have that logged, for possible investigation/action (expected event/maintenance, or known outage, or ... some other issue/problem)?
Miscellaneous comments :-) : IPv6 - random John and Jane Doe consumer might not yet know or care (and may never know, or particularly care), but The Internet is (slowly) going the way of IPv6. IPv4 won't disappear anytime soon. However, with the exhaustion of IPv4 addresses, increasingly clients are not only dual-stack (or have some funky way to still be able to access IPv4), but increasingly there will be clients much prefer IPv6 address and/or do or will only have IPv6 access. IPv6 adoption has also been growing at a relatively fast rate. If I recall correctly, last year IPv6 growth was up something like 10%. I remember even about 4 years ago, looking at DNS traffic of a major provider, AAAA queries were up to nearly 2% of volume of queries, relative to A+AAAA - that was up about 300% compared to only about a year or two earlier. Not sure about similar current stats, but in general, any such clients that are IPv6 only, those would typically be lost traffic/customers, or they may be stuck with some less preferred means of IPv4 access. We're well past the time where at least most all major providers should also be offering IPv6 connectivity (e.g. web sites, etc.). The big players in ISPs space all (or nearly all?) do IPv6, some of the smaller ISPs are still getting there (and even some of the colos aren't fully there yet). But in any case, IPv6 is coming, and one should prepare and get ready for it (but not an extreme rush for everyone - if you're domestic only web site with only domestic users, may not be much of a rush to use IPv6 ... but dang, it certainly is also nice to not be squeezed with very limited number of IPv4 addresses to work with).
Oh, if one doesn't have IPv6 available from one's ISP, there are IPv6 tunnel brokers, so one can use IPv6 over IPv4 - and thus reach the IPv6 Internet. E.g. Hurricane Electric provides such - for free (at least as in beer). They also have a lot of excellent IPv6 training materials (though a bit dated now, it's still mostly quite applicable). Anyway, I do have such IPv6 tunnels from Hurricane Electric (alas, my home ISP isn't yet offering native IPv6 ... I did also notice my work cellular, didn't have IPv6 only a few months or so ago, but a month or two after that, had added IPv6). Anyway, have an IPv6 tunnel for myself. Also have one for BALUG (I did a separate account for BALUG, so it's quite independent of my personal account). From Hurricane Electric: https://ipv6.he.net/certification/ https://tunnelbroker.net/ They also offer some free DNS services ... but they may be slightly funky in how they behave, and also somewhat limited, in at least some regards: https://dns.he.net/ But those do also include IPv6 nameservers.
Also, in the ssh examples above, I didn't include bothering to show use of ssh-add - generally used in advance to decrypt private key(s) and then temporarily (for specified length of time) hold the decrypted private key(s) in RAM - best to never have the keys in the clear written to non-volatile storage (e.g. disk or SSD or similar). The ssh-add program also takes care to not let private keys be written to swap - but I also have my swap encrypted, and likewise most of my drive storage.
And in the above regular expressions where there's character class ([...]) showing whitespace within, the whitespace is generally a space and a tab (my email client doesn't conveniently allow me to literally pass that along - and even if I did, clients displaying such may not preserve such in display, and in any case it wouldn't generally be visually obvious). Some RE contents allow \t for tab, but those I showed above generally don't support that.
And retrying earlier test: $ ssh -ax m-net.arbornet.org. hostname m-net.arbornet.org $
That works now, so trying further with that ...
$ ssh -ax m-net.arbornet.org. 'hostname &&
PATH="/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin:$PATH" \ && { if >>/dev/null 2>&1 type ip; then ip -6 a s; ip -6 r s else ifconfig -a; netstat -nr; fi; }'
m-net.arbornet.org em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> ether 00:50:56:8b:48:cf inet 162.202.67.157 netmask 0xffffffe0 broadcast 162.202.67.159 inet6 fe80::250:56ff:fe8b:48cf%em0 prefixlen 64 scopeid 0x1 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active em1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> ether 00:0c:29:34:2e:d3 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect status: no carrier plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> metric 0 mtu 1500 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=3<RXCSUM,TXCSUM> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> Routing tables
Internet: Destination Gateway Flags Refs Use Netif Expire default 162.202.67.129 UGS 0 4573 em0 127.0.0.1 link#4 UH 0 47170 lo0 162.202.67.128/27 link#1 U 0 127 em0 162.202.67.157 link#1 UHS 0 0 lo0
Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%em0/64 link#1 U em0 fe80::250:56ff:fe8b:48cf%em0 link#1 UHS lo0 fe80::%lo0/64 link#4 U lo0 fe80::1%lo0 link#4 UHS lo0 ff01::%em0/32 fe80::250:56ff:fe8b:48cf%em0 U em0 ff01::%lo0/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%em0/32 fe80::250:56ff:fe8b:48cf%em0 U em0 ff02::%lo0/32 ::1 U lo0 $
I don't think I see anything there that's globally routable IPv6 ff0x::114 Used for experiments ... yeah, I was wondering what ff01::... is/was ... wasn't able to identify that. Well, let's try wee bit:
$ ssh -ax m-net.arbornet.org. 'hostname &&
PATH="/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin:$PATH" \ && >>/dev/null 2>&1 type ping6 && ping6 -n -c 5 2001:470:1f04:19e::2'
m-net.arbornet.org ping6: UDP connect: No route to host $
Yep, it doesn't have a route to get there, so can't test further from there.
From: "Rick Moen" rick@linuxmafia.com Subject: Re: [BALUG-Admin] DNS slaves for BALUG? :-) Date: Sat, 20 Feb 2016 18:33:09 -0800
I wrote:
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
If you could please, and would be willing, could you cover DNS slave services for BALUG, notably these zones: e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa balug.org master(s) (all for each of the above): 198.144.194.238 2001:470:1f04:19e::2
FYI, ns1.linuxmafia.com is repeatedly logging this:
Feb 20 17:50:45 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled
I'm unsure why the AXFR/IXFR to the IPv6 address fails, and currently lack the time and patience to pursue that matter. For now, I'm going to disable that master IP on my BIND9 conffile.
Before I do that, Michael, would you like to any some checking on the _master_ nameserver end? The most probable explanation is some deficiency in IPv6 support on ns1.linuxmafia.com, and that would be my default assumption.
FYI, both zones are affected:
linuxmafia:/etc/bind# zgrep 'failure trying master' /var/log/* /var/log/daemon.log:Feb 20 12:55:59 linuxmafia named[17291]: zone balug.org/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/daemon.log:Feb 20 13:39:16 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/daemon.log:Feb 20 17:50:45 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/syslog:Feb 20 12:55:59 linuxmafia named[17291]: zone balug.org/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/syslog:Feb 20 13:39:16 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled /var/log/syslog:Feb 20 17:50:45 linuxmafia named[17291]: zone e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa/IN: refresh: failure trying master 2001:470:1f04:19e::2#53 (source ::#0): operation canceled linuxmafia:/etc/bind#
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
So ... wee bit of reference introduction, then my tests/findings/recommendations/etc., then more of the earlier referenced bits.
And thanks for that, by the way. I'm buried under lots of stuff that accumulated since I left home for various travels in mid-January (and my cruise left the Port of San Francisco on Jan. 25th). Also, there's the jetlag thing.
So ... [ns1.]linuxmafia.com. has an IPv6 stack and IPv6 link-local apparently configured, but no IPv6 route for anything beyond link-local and localhost.
Yeah, that seems to fit. I have an IPv4 default route to the other side of the Raw Bandwidth aDSL link at IP 198.144.195.186 (my point on their DSLAM) that I set up in March 2001 when Northpoint Communications collapsed, taking down my residential SDSL service with it -- at which point I became a Raw Bandwidth customer and have never screwed with the initial setup. It having been 2001, I didn't even think of establishing an IPv6 route alongside the IPv4 one.
$ ip -6 addr show dev eth2 3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 fe80::220:edff:fe13:ba89/64 scope link valid_lft forever preferred_lft forever $
$ ip -6 route show fe80::/64 dev eth2 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0 $
Having never done this before, I am guessing that I _could_ ask Mike Durkin (the Raw Bandwith owner) what IPv6 address for my gateway corresponds to the 198.144.195.186 IPv4 one. Then, I guess I automate this:
# ip -6 route add default via [IPv6 GW address]
....somewhere in /etc/network/inferfaces, like this:
iface eth2 inet6 static address fe80::220:edff:fe13:ba89 netmask 64 up ip -6 route add default via [IPv6 GW address] down ip -6 route del default via [IPv6 GW address]
...using the value of [IPv6 GW address] Mike Durkin provides.
I'd guess issue is same for ns1.svlug.org.
Yeah, fair bet. Since SVLUG Vice-President Micah Dowty negotiated the free VMware virthost for it and picked the Ubuntu Server image (to my lasting annoynace), nobody's done anything to its default networking.
Miscellaneous comments :-) : IPv6 - random John and Jane Doe consumer might not yet know or care (and may never know, or particularly care), but The Internet is (slowly) going the way of IPv6.
Yeah, familiar with all this.
Oh, if one doesn't have IPv6 available from one's ISP, there are IPv6 tunnel brokers, so one can use IPv6 over IPv4 - and thus reach the IPv6 Internet.
Probably the only practical way.
I've heard horror stories from even very experienced individual Unix users attempting to get IPv6 netblocks allocated to them. The system is basically set up to deny that.