FYI I did eventually manage to set the inverse IP names for my 13 IPs from Comcast Business. And IIRC I think I did eventually manage to do that online (through the worst GUI on the planet), but I'd have to go back and check to see if that is (still) true. They don't delegate lookups like the big boys, but each of the 13 names can be set to whatever I like. (And forget DNSSEC.) example: dig any 52.105.242.50.in-addr.arpa ;; ANSWER SECTION: 52.105.242.50.in-addr.arpa. 60 IN PTR ns2.sunnyside.com.
On IPv6, I haven't attempted to do that yet. Might be worth a shot. I think at the time Comcast was still discovering IPv6, and mostly letting the modem vendors run things. It might be better now, although 5 years is probably much too soon for a change on that.
AT&T actually does it right (and no, I don't mean u-verse). Al
On 12/13/2019 00:08, Michael Paoli wrote:
And things continue to march (be marched) along. Some minor glitches, but no blockers. Minor glitches? Mostly some minor config tweaks needed that I can't directly do, so likely involves some delayed bits along the way (e.g. a registrar that doesn't seem to have a way for customers to update DNS "glue" records for a record they already created earlier with such "glue", and an ISP where changing "reverse" DNS isn't something they can simply delegate to customers nor provide an interface to for customers to change, but involves a manual request and operation (submitted and awaiting completion). Thus far otherwise smooth (some DNS slaves may also be catching up on masters ... but that's not critical ... yet).
Oooh, and fun with multiple IPs on host, multiple ISPs, and routing. :-)
For the interested/curious:
Yummy ;-) ...
Still a work-in-progress, but we can see here (at least in relevant parts), the BALUG virtual machine host ... which also hosts (nearly) all* things BALUG.org, SF-LUG.org(/SF-LUG.com/SFLUG.org/SFLUG.com/SFLUG.net/SF-LUG.net) BerkeleyLUG.com(/BerkeleyLUG.org), *excepting SF-LUG's list & archive (hosted by linuxmafia.com), and various DNS slaves, etc. ...
So, ISP services from one ISP going away ~2019-12-19, added another ISP 2019-12-12. So, at present, e.g. this host, has two Internet addressable IPv4 IPs, at the same time, and routing configuration such that IPv4 packets to The Internet, will use the gateway for the appropriate ISP, based upon source IPv4 address.
Below we see some examples of that.
First there's a pair of traceroute checks, these using TCP to port 53 (DNS), to an IPv4 of Google public DNS servers, DNS not only uses UDP, but necessarily also supports TCP.
In the first of these, I explicitly set the source IP address (as I've not yet configured it to be default source IP).
$ sudo traceroute -nTp 53 -s 96.86.170.229 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 96.86.170.230 1.474 ms 2.911 ms 3.520 ms 2 96.120.88.121 14.617 ms 18.884 ms 20.645 ms 3 68.87.198.45 20.072 ms 19.706 ms 20.017 ms 4 68.86.143.37 19.683 ms 19.965 ms 20.039 ms 5 162.151.78.185 20.156 ms 22.816 ms 27.648 ms 6 162.151.86.57 31.399 ms 37.726 ms 37.409 ms 7 96.112.146.18 37.195 ms 96.112.146.22 31.580 ms 96.112.146.26 26.923 ms 8 209.85.252.251 15.169 ms 72.14.239.43 14.840 ms 72.14.235.1 14.369 ms 9 8.8.8.8 13.882 ms 12.636 ms 16.204 ms $
In the second, I use the old (still default) IPv4 source IP 198.144.194.238 (it would've also behaved the same if I'd explicitly specified it).
We see both work from the host, though they (expectedly) go quite different routes).
$ sudo traceroute -nTp 53 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 198.144.194.233 11.381 ms 12.972 ms 15.115 ms 2 216.131.94.209 17.550 ms 19.727 ms 22.060 ms 3 38.99.44.129 25.030 ms 22.815 ms 25.285 ms 4 154.54.5.233 27.864 ms 29.616 ms 154.54.6.169 31.735 ms 5 * 154.54.43.10 35.475 ms 154.54.43.14 37.156 ms 6 154.54.12.142 46.566 ms 34.548 ms 35.412 ms 7 72.14.198.30 35.582 ms 34.748 ms 35.525 ms 8 108.170.242.225 35.844 ms 34.478 ms 35.360 ms 9 108.170.236.61 34.795 ms 209.85.251.5 34.489 ms 72.14.239.43 34.121 ms 10 8.8.8.8 33.976 ms 32.869 ms 33.344 ms $
And the relevant IPv4s (showing just that portion): $ ip -4 a s 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 198.144.194.238/29 brd 198.144.194.239 scope global eth0 valid_lft forever preferred_lft forever inet 96.86.170.229/29 brd 96.86.170.231 scope global eth0:0 valid_lft forever preferred_lft forever $
And the routes. Note that we make use of a routing table and rule, so that IP traffic from source 96.86.170.229 uses a different default gateway:
$ ip -4 r s default via 198.144.194.233 dev eth0 onlink 96.86.170.224/29 dev eth0 proto kernel scope link src 96.86.170.229 192.168.55.0/24 dev eth0 proto kernel scope link src 192.168.55.3 198.144.194.232/29 dev eth0 proto kernel scope link src 198.144.194.238 $ ip rule list table 134 32765: from 96.86.170.229 lookup 134 $ ip r s table 134 default via 96.86.170.230 dev eth0 $
And here's what the relevant bits look like in the /etc/network/interfaces file:
allow-hotplug eth0 auto eth0 iface eth0 inet static address 198.144.194.238 netmask 255.255.255.248 network 198.144.194.232 broadcast 198.144.194.239 gateway 198.144.194.233
iface eth0:0 inet static address 96.86.170.229 netmask 255.255.255.248 up ip route add table 134 default via 96.86.170.230 up ip rule add from 96.86.170.229 table 134 down ip rule del from 96.86.170.229 table 134 down ip route del table 134 default via 96.86.170.230
In the near future, the relationships of the IPs will essentially flip, making the new the default, and the old - while it still exists - also continue to function (until that ISP drops).
From: "Michael Paoli" Michael.Paoli@cal.berkeley.edu Subject: Re: [BALUG-Admin] IPv4 IP changes coming! Date: Wed, 11 Dec 2019 18:45:11 -0800
Al, yes thanks for the catch.
My bad, labeled incorrectly 8-O That should've read: "new" "old" 96.86.170.224 198.144.194.232 network 96.86.170.225 198.144.194.234 96.86.170.226 198.144.194.235 96.86.170.227 198.144.194.236 96.86.170.228 198.144.194.237 96.86.170.229 198.144.194.238 balug.org./[L]UGs 96.86.170.230 198.144.194.233 gateway 96.86.170.231 198.144.194.239 broadcast
Also note that they're not quite in sequence (as one has gateway at start of "usable" range, and the other has gateway at end of "usable" range).
I'll also be updating: https://www.balug.org/wiki/doku.php?id=system:ip_addresses it's grossly out-of-date. Likewise: http://www.balug.org/dns/ and https://www.balug.org/dns/ ... which I'll probably just have redirect to: https://www.balug.org/wiki/doku.php?id=system:ip_addresses ... at least when I get around to it.
From: Al awbalug@sunnyside.com Subject: Re: [BALUG-Admin] IPv4 IP changes coming! Date: Wed, 11 Dec 2019 09:38:55 -0800
Michael, I think you switched old and new. Since I am set up to slave 5 domains at the 198.144.194.238 address, I suggest just adding 96.86.170.229 to the definition now, and then removing the .238 address when the .229 address is working well. This is in addition to the three IPv6 addresses for various domains.
I don't use any of the other addresses. I'll put that up this morning. If for some reason the 96.xxx addresses have to get changed, it's easy. Al
On 12/11/2019 08:54, Michael Paoli wrote:
It's anticipated/hoped, that the IPv4 changes will go approximately as follows: "old" "new" 96.86.170.224 198.144.194.232 network 96.86.170.225 198.144.194.234 96.86.170.226 198.144.194.235 96.86.170.227 198.144.194.236 96.86.170.228 198.144.194.237 96.86.170.229 198.144.194.238 balug.org./[L]UGs 96.86.170.230 198.144.194.233 gateway 96.86.170.231 198.144.194.239 broadcast The "old" IPv4 IPs will go away >~=2019-12-19, most notably of interest to BALUG/[L]UGs (,SF-LUG, BerkeleyLUG), the IPs noted as: balug.org./[L]UGs Not guaranteed until operational, but expecting likely the "new" IPv4 IPs will start to become operational on or slightly after 2019-12-12, and will be transitioned to and made fully operational as quickly as feasible. It's anticipated there will be some overlap period where both are operational.
Both operational(?) ... for a bit? Yes, at least that's the plan/theory, roughly like this: o new IPs added to hosts o conditional (from) routing added to hosts (from new to use new gateway) o DNS slaves updated on status once masters available on new IPs o new IPs added to DNS (some may go in phases) o "reverse" DNS updates o SMTP "tests" / warm-up o "new" default route; conditional (froms): add "old"; drop "new" (superseded) o DNS notify IPv4 source updated o "old" IPv4s removed from DNS in advance (>=TTLs) of old IPv4 decommissionings
From: "Michael Paoli" Michael.Paoli@cal.berkeley.edu Subject: IPv4 IP changes coming! Date: Wed, 13 Nov 2019 05:05:23 -0800
So, I'll be changing ISP (at least for IPv4) ... that'll mean new IPs for IPv4 ... most notably for these [L]UG domains (and in general subdomains thereof): balug.org sf-lug.org sflug.org sflug.com sflug.net sf-lug.net sf-lug.com berkeleylug.com berkeleylug.org
A bit more generally:
By not later than end of 2019-12-19, these IPv4 IPs (range) will be "going away"/changing: 198.144.194.232/29 198.144.194.232 - 198.144.194.239 198.144.194.232 198.144.194.233 198.144.194.234 198.144.194.235 198.144.194.236 198.144.194.237 198.144.194.238 198.144.194.239
At present, my IPv6 is provided from another ISP (tunneled via IPv4), so I'm expecting the IPv6 IPs will remain the same (at least through this transition anyway).
Anyway, hopefully all these changes will happen rather to quite smoothly ... but a bit early to say. E.g., as I transition ISPs, there may be brief(ish) period between, when temporarily neither is available. We shall see. I'll update relevant contatct(s)/lists as/when relevant and appropriate and I'm reasonably able to do so. Hopefully I can minimize any "user facing" impact ... if I'm reasonably lucky, may be able to do it quite seamlessly, with essentially no impact to "users" ... we shall see.
references/excerpts: http://linuxmafia.com/pipermail/conspire/2019-November/009966.html
BALUG-Admin mailing list BALUG-Admin@lists.balug.org https://lists.balug.org/cgi-bin/mailman/listinfo/balug-admin