[BALUG-Admin] IPv4 IP changes coming! - comcast business reverse IP
Al
awbalug@sunnyside.com
Fri Dec 13 15:43:29 UTC 2019
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
More information about the BALUG-Admin
mailing list