[sf-lug] workaround applied to 10 secondary domains (including all of SF-LUG's) Re: Comcast Business DNS problems - yet again ([ns1.]linuxmafia.com 96.95.217.99 ...)

[Michael Paoli]

Bumped the serial numbers on the noted zones/domains:
# (for d in e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. berkeleylug.com.
sf-lug.com. sflug.com. savingthedolph.in. sf-lug.net. sflug.net.
balug.org. sf-lug.org. sflug.org.; do set -- $(dig @127.0.0.1 +noall
+answer +norecurse "$d" SOA); [ 11 -eq "$#" ] || continue; d="$1";
TTL="$2"; shift; shift; shift; shift; s="$(date +%s)" || continue;
printf '%s\nsend\n' "update add $d $TTL IN SOA $1 $2 $s $4 $5 $6 $7" |
nsupdate -l; done)
#

And, no surprise given current Comcast Business gateway DNS issue
96.95.217.99 (ns1.linuxmafia.com.)
fails to update due to that issue
whereas all the other secondaries successfully updated.

So ... implement work-around again ...
... and all 10 of those secondaries on
96.95.217.99 (ns1.linuxmafia.com.)
and including all of SF-LUG's
now successfully updated.

On Fri, Sep 22, 2023 at 8:49 PM Michael Paoli
<michael.paoli at cal.berkeley.edu> wrote:
>
> Alas, Comcast Business is at it yet again.
> They've again broken DNS, notably
> at their gateway device, between most notably
> [ns1.]linuxmafia.com 96.95.217.99
> and The Internet, when and where
> [ns1.]linuxmafia.com 96.95.217.99
> is client, and any Internet IP addresses beyond that gateway device, are
> server, e.g. when
> [ns1.]linuxmafia.com 96.95.217.99
> functions as secondary and primary is elsewhere on
> The Internet.  The DNS problem is much more pervasive than that, with
> that gateway device, but the above is most notable impact,
> particularly for those beyond that local subnet,
> e.g. The rest of The Internet using
> [ns1.]linuxmafia.com 96.95.217.99
> as authoritative nameserver for many DNS zones.
> Notably it can't get its updates for zones it's secondary for,
> due to Comcast reintroducing apparently same problem they introduced a
> while ago.  And this was after Comcast Business not that long ago
> replaced the device to "fix" the issue ... and now the issue has
> returned yet again.
>
> Anyway, Rick is again working with Comcast Business to get them to fix
> their DNS mess up yet again.
>
> Meantime, I'm going to reimplement some workarounds where feasible,
> notably for zones where I also have DNS admin access to the primary
> servers.  Alas, had that in place until fairly recently, took it out
> after Comcast Business fixed the earlier issue.  Looks like time to
> put it back again.  I and I think this time around I probably leave
> it in place for 90+ days after Comcast Business "fixes" their issue
> ... in case they break it yet again not too long after "fixing" it.
> Or maybe I do up to 6 months or a year.  Not exactly gettin' the warm
> 'n fuzzy feelings from Comcast Business.
>
> And for the curious, on Comcast, might want to see if your DNS actually
> truly works, or if they subvert your DNS traffic too, and don't let you
> actually get that directly from The Internet.  And yes, there may be
> workarounds, oh, ... like run DNS on a different port, or (ugh) do DNS
> over TLS or HTTPS).
>
> Anyway, some technical details on the breakage (and thus far looks to be
> exactly same issue as before):
>
> On Thu, Sep 21, 2023 at 11:05 PM Michael Paoli
> <michael.paoli at cal.berkeley.edu> wrote:
> > Oh dear ...
> > $ hostname && ip -4 a s | fgrep inet | fgrep -v 127.
> > linuxmafia.com
> >     inet 96.95.217.99/29 brd 96.95.217.103 scope global eth2
> > $ hostname && ip -4 a s | fgrep inet | fgrep -v 127.
> > linuxmafia.com
> >     inet 96.95.217.99/29 brd 96.95.217.103 scope global eth2
> > $ (set -x; dig @$(dig +short com. NS | head -n 1) +noall +authority
> > sflug.com. NS)
> > ++ dig +short com. NS
> > ++ head -n 1
> > + dig @b.gtld-servers.net. +noall +authority sflug.com. NS
> > $ nc -vz b.gtld-servers.net. 53
> > b.gtld-servers.net [192.33.14.30] 53 (domain) open
> > $
> > # hostname && ip -4 a s | fgrep inet | fgrep -v 127.
> > linuxmafia.com
> >     inet 96.95.217.99/29 brd 96.95.217.103 scope global eth2
> > # traceroute -nTp 53 192.33.14.30
> > traceroute to 192.33.14.30 (192.33.14.30), 30 hops max, 40 byte packets
> >  1  192.33.14.30  2.795 ms  3.157 ms  3.672 ms
> > #
>
> Note in the above that in reality 192.33.14.30
> is absolutely not 1 hop away.
>
> And in the below, take note that at
> present here's absolutely nothing
> on or currently using 96.86.170.228:
>
> > # traceroute -nTp 53 96.86.170.228
> > traceroute to 96.86.170.228 (96.86.170.228), 30 hops max, 40 byte packets
> >  1  96.86.170.228  1.916 ms  1.615 ms  1.230 ms
> > # dig @96.86.170.228 +short www.google.com. A
> > 142.251.46.228
> > #
>
> > On Thu, Sep 21, 2023 at 10:44 PM Michael Paoli
> > <michael.paoli at cal.berkeley.edu> wrote:
> > >
> > > Okay ... let me have a look and see what's up ....
> > >
> > > On Thu, Sep 21, 2023 at 6:59 PM Rick Moen <rick at linuxmafia.com> wrote:
> > > >
> > > > I was getting a whole lot of weird errors in my logfiles about
> > > > 96.86.170.229 not being authoritative.  Some basic command-line
> > > > checks show I'm not getting AXFR from it.
> > > >
> > > > [rick at linuxmafia]
> > > > ~ $ dig sflug.com ns @a.gtld-servers.net. +short
> > > > ns1.sf-lug.org.
> > > > ns1.linuxmafia.com.
> > > > nsy.sunnysidex.com.
> > > > nsx.sunnyside.com.
> > > > [rick at linuxmafia]
> > > > ~ $ dig sflug.com. soa @ns1.sf-lug.org. +short
> > > > ns1.sf-lug.org. jim.well.com. 1695151540 10800 3600 3600000 86400
> > > > [rick at linuxmafia]
> > > > ~ $ dig sflug.com. axfr @ns1.sf-lug.org. +short
> > > > ; Transfer failed.
> > > > [rick at linuxmafia]
> > > > ~ $ dig ns1.sf-lug.org. +short
> > > > 96.86.170.229
> > > > [rick at linuxmafia]
> > > > ~ $