Quoting Al Whaley (aw009(a)sunnyside.com):
> That security edge feature is no longer optional on Comcast business
> accounts. However you can log into your Comcast business website
> portal as yourself and look at your options and very quickly turn
> security edge off.
Guys, I've moved this back to balug-admin, because I like the record
that keeps, and we're not talking about anything that dannot be public.
Is that alright?
Good idea about that accursed SecurityEdge "feature". I've now disabled
that blasted thing in the Comcast Business account to the extent they
permit, I think?
Initial login takes me to
https://business.comcast.com/account/dashboard/accounts/689906011127102015C…
where I see Subscribed Services described as "Business Internet
Essential 150 Mbps / 25 Mbps" and below that "SecurityEdgeTM", which is
a link, following which goes to https://securityedge.comcast.com/#home ,
showing tab Dashboard, which has nothing adjustable, but move on to tab
Settings, page https://securityedge.comcast.com/#settings/profiles .
Here, "Web Filters" had a predefined "protection level" of "Light", but
one can select "None", which I did.
Scrolling down the page, everything settable is Off, except that section
Internet Security has "Malware & Phishing Protection" set to "On", which
slide control is greyed out (unchangeable). Subtitle is "Keeps user
from compromising the network or their personal data if they
accidentally or intentionally access infected web [sic] pages or click
on phishing emails." Select Save at the page bottom to implement.
Slide control "Web Filters" at the top of the page now shows Off.
The other tabs, "Block & Allow Lists", "Block Page Construction",
"Domain Lookup", and "Scheduled Reports" don't appear to have anything
useful for my purposes.
Orange banner at the very top of the page now says: "Web Filter
Protection is now off. To safeguarg your network, Malware, Phishing,
and Botnet Protection remains on. Learn More [link]."
Following link goes to
https://securityedge.comcast.com/#help/turning-web-filters-on-and-off ,
which is a long documentation page including justifying preventing
turning that part off:
Malware, phishing and botnet traffic is generated by malicious
software. Protection against this traffic is critical. This is why we do
not recommend disabling the Malware and Phishing setting for any user
profile. The setting remains enabled even if you turn off Web Filters.
Also notable:
To turn Web Filters on or off, log in to Comcast Business SecurityEdge.
On the top right of any page, click the Web Filters toggle switch: from
On to Off to deactivate the Protection Level, Block & Allow Lists and
Off-Hours Internet Schedule, or from Off to On to activate them. The
^^^
change is applied immediately.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Noting that final sentence, I now attempt another smoke test, to see if
the problem is gone:
$ dig -p 5353 @96.86.170.229 balug.org
;; connection timed out; no servers could be reached
$
Nope.
Noting Al's wording "look at your options and very quickly turn
security edge off", I try to see if there's another entry point into the
account to do so. What about "My Account" over on the far side of the
navbar for
https://business.comcast.com/account/account-details/689906011127102015Comc…
?
I see:
SUBSCRIBED SERVICES:
Business Internet
- SecurityEdge
Clicking "Business Internt" takes me to
https://business.comcast.com/connectivity/internetdashboard/ , Where
Item
SECURITYEDGEtm
Cybersecurity
is shown as "Disabled".
At some point, I tried toggling the "Web Filters" toggle from the Off to
the On position, and then back to Off. This resulted in my losing
connectivity to my server for a few minutes, getting Network Unreachable
on my ssh reconnection. I infer that the "modem" device was resetting.
I continute to get...
$ dig -p 5353 @96.86.170.229 balug.org
;; connection timed out; no servers could be reached
$
Al, Michael, am I missing a trick, here?
--
Cheers, "Mastodon: owned by nobody and/or everybody!
Rick Moen Seize the memes of production!" -- jwz
rick(a)linuxmafia.com https://www.jwz.org/blog/2023/11/mastoversary/
McQ! (4x80)
Probably redundant to an earlier forward of mine, making this same
point, but, I note:
$ dig -x 73.189.65.18 +short
c-73-189-65-18.hsd1.ca.comcast.net.
$
----- Forwarded message from logcheck system account <logcheck(a)linuxmafia.com> -----
Date: Mon, 03 Jun 2024 15:02:02 -0700
From: logcheck system account <logcheck(a)linuxmafia.com>
To: root(a)linuxmafia.com
Subject: linuxmafia.com 2024-06-03 15:02 System Events
System Events
=-=-=-=-=-=-=
Jun 3 14:48:39 linuxmafia named[15622]: client 73.189.65.18#16833: received notify for zone 'mpaoli.net'
Jun 3 14:48:39 linuxmafia named[15622]: zone mpaoli.net/IN: refused notify from non-master: 73.189.65.18#16833
Jun 3 14:48:44 linuxmafia named[15622]: client 73.189.65.18#16833: received notify for zone 'mpaoli.net'
Jun 3 14:48:44 linuxmafia named[15622]: zone mpaoli.net/IN: refused notify from non-master: 73.189.65.18#16833
----- End forwarded message -----
Pursuant to my earlier point. More.
----- Forwarded message from logcheck system account <logcheck(a)linuxmafia.com> -----
Date: Mon, 03 Jun 2024 23:02:01 -0700
From: logcheck system account <logcheck(a)linuxmafia.com>
To: root(a)linuxmafia.com
Subject: linuxmafia.com 2024-06-03 23:02 System Events
System Events
=-=-=-=-=-=-=
Jun 3 22:51:33 linuxmafia named[15622]: client 96.86.170.229#16069: received notify for zone 'balug.org'
Jun 3 22:51:33 linuxmafia named[15622]: zone balug.org/IN: Transfer started.
Jun 3 22:51:33 linuxmafia named[15622]: transfer of 'balug.org/IN' from 96.86.170.229#53: connected using 96.95.217.99#45488
Jun 3 22:51:34 linuxmafia named[15622]: zone balug.org/IN: transferred serial 1717480293
Jun 3 22:51:34 linuxmafia named[15622]: transfer of 'balug.org/IN' from 96.86.170.229#53: Transfer completed: 1 messages, 12 records, 1564 bytes, 0.095 secs (16463 bytes/sec)
Jun 3 22:51:34 linuxmafia named[15622]: client 96.86.170.229#16069: received notify for zone 'balug.org'
Jun 3 22:51:34 linuxmafia named[15622]: zone balug.org/IN: notify from 96.86.170.229#16069: zone is up to date
Jun 3 23:00:26 linuxmafia named[15622]: client 96.86.170.229#35064: received notify for zone 'berkeleylug.com'
Jun 3 23:00:26 linuxmafia named[15622]: zone berkeleylug.com/IN: Transfer started.
Jun 3 23:00:26 linuxmafia named[15622]: transfer of 'berkeleylug.com/IN' from 96.86.170.229#53: connected using 96.95.217.99#48645
Jun 3 23:00:26 linuxmafia named[15622]: zone berkeleylug.com/IN: transferred serial 1717480825
Jun 3 23:00:26 linuxmafia named[15622]: transfer of 'berkeleylug.com/IN' from 96.86.170.229#53: Transfer completed: 1 messages, 8 records, 915 bytes, 0.078 secs (11730 bytes/sec)
----- End forwarded message -----
----- Forwarded message from Michael Paoli <michael.paoli(a)berkeley.edu> -----
Date: Tue, 4 Jun 2024 07:41:23 -0700
From: Michael Paoli <michael.paoli(a)berkeley.edu>
To: Rick Moen <rick(a)linuxmafia.com>
Cc: Al <aw009(a)sunnyside.com>
Subject: Fwd: [EXTERNAL] Re: Comcast ticket#CR145359298
X-Spam-Status: No, score=-2.7 required=4.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,T_SCC_BODY_TEXT_LINE
autolearn=ham version=3.3.1
---------- Forwarded message ---------
From: Oquin, Summer <Summer_Oquin(a)comcast.com>
Date: Tue, Jun 4, 2024 at 7:06 AM
Subject: RE: [EXTERNAL] Re: Comcast ticket#CR145359298
To: Michael Paoli <michael.paoli(a)berkeley.edu>
Hello Michael,
Thank you for clarifying this information I will get it noted on both
accounts and yes if that customer can reach out to us at 800-391-3000
to fully authenticate, we can absolutely take a further look at that
account and escalate a ticket if needed.
Thank you,
Summer
-----Original Message-----
From: Michael Paoli <michael.paoli(a)berkeley.edu>
Sent: Monday, June 3, 2024 6:39 PM
To: Oquin, Summer <Summer_Oquin(a)comcast.com>
Cc: Rick Moen <rick(a)linuxmafia.com>
Subject: [EXTERNAL] Re: Comcast ticket#CR145359298
Hi, thanks for getting back to me on:
Comcast ticket#CR145359298
So, bad news, good news:
Bad news: All appearances and evidence are it is a Comcast Business
issue, Good news: issue not on this account, but on another - on the
client end.
So, please add the following note on the ticket:
CR145359298 - issue appears to be on/towards other end, different
Comcast Business account, address:
1105 ALTSCHUL AVE UNIT HMOFC MENLO PARK CA 94025 issue, client IP:
96.95.217.98/29
communication fails with UDP to server: 96.86.170.229 UDP port 5353
Also observed:
Server receives and responds.
Response packets never make it to client (96.95.217.98).
If target port is changed to 53 or protocol changed to TCP, then
client successfully receives reply packets.
Also able to communicate from other Internet clients to
server: 96.86.170.229 UDP port 5353
Once that note has been added, please feel free to close out
CR145359298 at your convenience.
I expect the other Comcast Business customer (whom I've CCed) will be
contacting Comcast Business support and/or you to work to resolve the
matter.
Thanks!
On Mon, Jun 3, 2024 at 3:02 PM Oquin, Summer <Summer_Oquin(a)comcast.com> wrote:
>
> Hello Michael,
>
> I received your ticket regarding the connectivity issues you were
> experiencing at the business location of 1816 CARLETON ST APT D-HMOFC
>
> BERKELEY CA 94703 and currently I am not seeing anything that would be interfering with your internet connection. I have confirmed there is no dual route with your gateway static 96.86.170.230 and that you do have two devices currently connected on your usable statics 96.86.170.226 and 96.86.170.229. Please let me know if you are still experiencing any issues and what they are by replying to this email directly or by calling me using the number below, and I would be happy to further investigate.
>
>
>
>
>
> Thank you,
>
> Summer
>
> Advanced Tech 4 (ABS)
>
> Comcast Business
>
> Office hours: Mon-Fri 8:00am-4:30pm MST
>
> Direct line: 303-391-3208
>
>
>
> Comcast Business SmartOffice Licenses:
> AL: 001785, 001789; AR: 2536; AZ: ROC 307346, BTR 18286-0; CA: CSLB
> 1028256, ACO 7677; CT: ELC 0189754-C5; DE: SSPS 13-225; FL:
> EF20001118; GA: LVU406354; IL: PACA 127-001555; LA: F2257; MA: 1499A1,
> 7067C, SS-002525; MD: 23PLU-SS23595; ME: LM50017039; MI: 3601206519;
> MN: TS674413; MS: 15030170; NC: 770576-CSA; NJ: Burglar Alarm Business
> Lic. # 34BF00052000; NM: 379095; NY: licensed by the N.Y.S. Department
> of State 12000317423; OR: CCB 199939; SC: BAC-13662; TN: ACL 2006, ACL
> 2002; TX: B18966; UT: 8788186-6501; VA: 2705151177, DCJS 11-15181; VT:
> ES-02366; WA: COMCABS846NU; WASHINGTON, DC: ECS 904217, BBL
> 602517000001; WV: WV051524. Valid 6/1/23. See
> www.business.comcast.com/smartoffice for current list Thank you for
> choosing Comcast Business we are always available 24/7 at
> 1-800-391-3000
>
> THIS EMAIL BOX IS NOT MONITORED
>
>
----- End forwarded message -----
Apologies, Al, but I wasn't able to see that image (because of
inherent limitations on mailing lists). Would you mind just hosting the
image and posting its URL?
Or, I suppose, you could e-mail it to me.
---------- Forwarded message ----------
From: Al <awbalug(a)sunnyside.com>
To: balug-admin(a)lists.balug.org
Cc:
Bcc:
Date: Tue, 4 Jun 2024 07:34:43 -0700
Subject: Re: [BALUG-Admin] Comcast Business apparently blocking 5353 UDP
Re: linuxmafia.com "retry limit exceeded" CR145359298
Look for the arrow in this image, lower left:
---------- END Forwarded message ---------
Just noting more weirdness for the record.
Michael, I haven't yet opened a ticket with Comcast Business. I want to
have a coherent account of what I'm talking about, and simple criteria
to show success conditions. I _strongly fear_ that the root cause will
turn out to be SECURITYEDGEtm, that Comcast will refuse to disable it,
and that they'll say it's now an integral part of the "BUSINESS INTERNET
ESSENTIAL" customer agreement [sic], and that they no longer offer an
alternative plan that omits it and still provides static IPs.
And if _that_ is the case, I'm really not sure what Chez Moen's backup
plan is. (Also, I'm getting a bit exhausted by diagnosing and coping
with technology companies suddenly turning evil and customer-hostile.
First, my domain registrar, and now this! Again!)
So, the weirdness below: Is it really credible that Michael's
nameserver 96.86.170.229 is suddenly sending NOTIFYs for
savingthedolph.in and sf-lug.org? Why? There haven't been zonefile
changes, have there?
I'm starting to think that Comcast's middleman infrastructure is
artificially generating those, forging 96.86.170.229 as alleged source.
I'm not sure why. It could be either a gaffe in implementation _or_
a kludge to ensure that their infrastructure has current cached data
at the expense of the real auth. nameservers.
On another note, 198.144.194.12 is Aaron T. Porter's ns.primate.net,
which is not primary but rather a secondary for sf-lug.org. I have
a faint recollection _either_ that "secondary sends out NOTIFY even
though it shouldn't" is common _or_ that I've seen this with Aaron's
nameservers before and never gotten resolution. Probably I should
just make logcheck ignore those from 198.144.194.12 in its roles as
secondary.
----- Forwarded message from logcheck system account <logcheck(a)linuxmafia.com> -----
Date: Tue, 04 Jun 2024 12:02:01 -0700
From: logcheck system account <logcheck(a)linuxmafia.com>
To: root(a)linuxmafia.com
Subject: linuxmafia.com 2024-06-04 12:02 System Events
System Events
=-=-=-=-=-=-=
Jun 4 11:35:18 linuxmafia named[15622]: client 96.86.170.229#49840: received notify for zone 'savingthedolph.in'
Jun 4 11:35:18 linuxmafia named[15622]: zone savingthedolph.in/IN: Transfer started.
Jun 4 11:35:19 linuxmafia named[15622]: transfer of 'savingthedolph.in/IN' from 96.86.170.229#53: connected using 96.95.217.99#35905
Jun 4 11:35:19 linuxmafia named[15622]: zone savingthedolph.in/IN: transferred serial 1717526118
Jun 4 11:35:19 linuxmafia named[15622]: transfer of 'savingthedolph.in/IN' from 96.86.170.229#53: Transfer completed: 1 messages, 8 records, 1082 bytes, 0.097 secs (11154 bytes/sec)
Jun 4 11:40:48 linuxmafia named[15622]: client 96.86.170.229#7259: received notify for zone 'sf-lug.org'
Jun 4 11:40:48 linuxmafia named[15622]: zone sf-lug.org/IN: Transfer started.
Jun 4 11:40:48 linuxmafia named[15622]: transfer of 'sf-lug.org/IN' from 96.86.170.229#53: connected using 96.95.217.99#59792
Jun 4 11:40:48 linuxmafia named[15622]: zone sf-lug.org/IN: transferred serial 1717526448
Jun 4 11:40:48 linuxmafia named[15622]: transfer of 'sf-lug.org/IN' from 96.86.170.229#53: Transfer completed: 1 messages, 10 records, 1208 bytes, 0.089 secs (13573 bytes/sec)
Jun 4 11:42:49 linuxmafia named[15622]: client 198.144.194.12#50384: received notify for zone 'sf-lug.org'
Jun 4 11:42:49 linuxmafia named[15622]: zone sf-lug.org/IN: refused notify from non-master: 198.144.194.12#50384
----- End forwarded message -----
OK, those fsckers are _definitely_ screwing with my DNS, again.
See that "73.189.65.18" IP? Well...
$ dig -x 73.189.65.18 +short
c-73-189-65-18.hsd1.ca.comcast.net.
$
I'm betting this also somehow accounts for my mameserver mysteriously
getting NOTIFYs for domain mpaoli.net every 90 seconds.
----- Forwarded message from logcheck system account <logcheck(a)linuxmafia.com> -----
Date: Mon, 03 Jun 2024 15:02:02 -0700
From: logcheck system account <logcheck(a)linuxmafia.com>
To: root(a)linuxmafia.com
Subject: linuxmafia.com 2024-06-03 15:02 System Events
System Events
=-=-=-=-=-=-=
Jun 3 14:48:39 linuxmafia named[15622]: client 73.189.65.18#16833: received notify for zone 'mpaoli.net'
Jun 3 14:48:39 linuxmafia named[15622]: zone mpaoli.net/IN: refused notify from non-master: 73.189.65.18#16833
Jun 3 14:48:44 linuxmafia named[15622]: client 73.189.65.18#16833: received notify for zone 'mpaoli.net'
Jun 3 14:48:44 linuxmafia named[15622]: zone mpaoli.net/IN: refused notify from non-master: 73.189.65.18#16833
----- End forwarded message -----
So,
I did finally hear back from Comcast Business - they were supposed to call,
they didn't, but rather emailed me,
and I responded (tail end trimmed a bit,
Rick, the one I CCed you has the tech's direct phone # and hours, etc.):
---------- Forwarded message ---------
From: Michael Paoli <michael.paoli(a)berkeley.edu>
Date: Mon, Jun 3, 2024 at 6:38 PM
Subject: Re: Comcast ticket#CR145359298
To: Oquin, Summer <Summer_Oquin(a)comcast.com>
Cc: Rick Moen <rick(a)linuxmafia.com>
Hi, thanks for getting back to me on:
Comcast ticket#CR145359298
So, bad news, good news:
Bad news: All appearances and evidence are it is a Comcast Business issue,
Good news: issue not on this account, but on another - on the client end.
So, please add the following note on the ticket:
CR145359298 - issue appears to be on/towards other end,
different Comcast Business account, address:
1105 ALTSCHUL AVE UNIT HMOFC MENLO PARK CA 94025
issue, client IP:
96.95.217.98/29
communication fails with UDP to server: 96.86.170.229 UDP port 5353
Also observed:
Server receives and responds.
Response packets never make it to client (96.95.217.98).
If target port is changed to 53 or protocol changed to TCP,
then client successfully receives reply packets.
Also able to communicate from other Internet clients to
server: 96.86.170.229 UDP port 5353
Once that note has been added, please feel free to close out
CR145359298 at your convenience.
I expect the other Comcast Business customer (whom I've CCed)
will be contacting Comcast Business support and/or you to work to
resolve the matter.
Thanks!
On Mon, Jun 3, 2024 at 3:02 PM Oquin, Summer <Summer_Oquin(a)comcast.com> wrote:
>
> Hello Michael,
>
> I received your ticket regarding the connectivity issues you were experiencing at the business location of 1816 CARLETON ST APT D-HMOFC
>
> BERKELEY CA 94703 and currently I am not seeing anything that would be interfering with your internet connection. I have confirmed there is no dual route with your gateway static 96.86.170.230 and that you do have two devices currently connected on your usable statics 96.86.170.226 and 96.86.170.229. Please let me know if you are still experiencing any issues and what they are by replying to this email directly or by calling me using the number below, and I would be happy to further investigate.
>
>
>
>
>
> Thank you,
>
> Summer
>
> Advanced Tech 4 (ABS)
>
> Comcast Business
>
> Office hours: Mon-Fri 8:00am-4:30pm MST
---------- END Forwarded message ---------
On Mon, Jun 3, 2024 at 7:21 AM Michael Paoli <michael.paoli(a)berkeley.edu> wrote:
>
> SecurityEdge still seems to be optional,
> and not present (yay!) on my Comcast Business account.
> I checked there, looking for it, per their documentation, on where
> it would/should be - and found it not at all present here (yay!).
>
> Also, still waiting to hear back from Comcast Business support, but when I do,
> at this point, this is essentially what I've got for 'em:
> CR145359298 - issue appears to be on/towards other end,
> different Comcast Business account, address:
> 1105 ALTSCHUL AVE UNIT HMOFC MENLO PARK CA 94025
> issue, client IP:
> 96.95.217.98/29
> communication fails with UDP to server: 96.86.170.229 UDP port 5353
> Also observed:
> Server receives and responds.
> Response packets never make it to client (96.95.217.98).
> If target port is changed to 53 or protocol changed to TCP,
> then client successfully receives reply packets.
> Also able to communicate from other Internet clients to
> server: 96.86.170.229 UDP port 5353
>
> On Mon, Jun 3, 2024 at 7:07 AM Al <aw009(a)sunnyside.com> wrote:
> >
> > That security edge feature is no longer optional on Comcast business accounts. However you can log into your Comcast business website portal as yourself and look at your options and very quickly turn security edge off.
> >
> > On June 3, 2024 01:24:23 Michael Paoli via BALUG-Admin <balug-admin(a)lists.balug.org> wrote:
> >
> >> Rick,
> >>
> >> I found non-Comcast Business client I could test from and ...:
> >> $ curl -s https://ipv4.balug.org/myip && dig -p 5353 +nomultiline
> >> @96.86.170.229 +noall +answer sflug.com. SOA
> >> 54.149.53.111
> >> sflug.com. 172800 IN SOA ns1.sf-lug.org. jim.well.com. 1716775812
> >> 10800 3600 3600000 86400
> >> $ sudo traceroute -f 13 -nUp 5353 96.86.170.229
> >> traceroute to 96.86.170.229 (96.86.170.229), 30 hops max, 60 byte packets
> >> 13 96.110.41.78 22.205 ms 68.85.191.206 23.194 ms 96.110.41.74 21.052 ms
> >> 14 162.151.86.58 23.357 ms 162.151.78.186 22.058 ms 162.151.86.58 22.490 ms
> >> 15 162.151.78.186 22.559 ms 96.86.170.229 35.853 ms 40.269 ms
> >> $
> >>
> >> Works fine from there. So, alas, looks like issue on/towards your
> >> Comcast Business side/end of things.
> >> So ... feel free to follow-up with Comcast Business at your convenience.
> >> Might also want to have them cross-reference:
> >> Ticket #: CR145359298
> >> If that's useful. They don't seem to (thus far) give me a way to
> >> update that on-line,
> >> but when they call, I'll let 'em know to call off the dogs on this side
> >> of it - and looks like issue on/towards your Comcast Business side of things.
> >>
> >> On Mon, Jun 3, 2024 at 12:20 AM Michael Paoli
> >> <michael.paoli(a)berkeley.edu> wrote:
> >>>
> >>>
> >>> Rick,
> >>>
> >>> I've opened case with Comcast Business,
> >>> Ticket #: CR145359298
> >>> I tried their on-line chat, that basically walked me through some basic
> >>> checks, then to a not available at this time, call, or ... so, called ...
> >>> got someone nice enough ... not incompetent but no expert, and yeah,
> >>> "of course" quite limited in what they could do ...
> >>> did eventually get it escalated to create the ticket ... as about the
> >>> only option
> >>> 1st tier had left would be to dispatch hardware tech ... which would probably be
> >>> total waste of everyone's time, as was working perfectly fine before, no changes
> >>> in hardware, and works fine on UDP port 53, but not 5353 (and works on TCP).
> >>> Also, did dig a little further ... traceroute ...
> >>> packets actually are in fact making it to the server ... but not back to client,
> >>> so, ... not really sure where the issue would be - could be anywhere between
> >>> "my" Comcast "router", and "yours".
> >>> At first I was thinking most likely at/around my end based upon the
> >>> tracroute data,
> >>> but checking server and seeing it gets packets and responds ...
> >>> could be getting lost/blocked anywhere between - and without ability to
> >>> capture along hops along the way on network, dear knows where. I'd guess
> >>> most likely at/near one of the two ends, but who knows, some security/firewall
> >>> (dis)services push that filtering further away from the endpoints,
> >>> even if they're
> >>> (generally) driven by customers (whether that's penultimate ISP
> >>> end-user customer)
> >>> or smaller to fair sized businesses or ISPs pushing the filtering
> >>> further away from the
> >>> endpoints to aid in more efficient filtering (less undesired traffic -
> >>> when it's not desired,
> >>> better handling of DDoS, etc.).
> >>>
> >>> So, e.g., on server I see:
> >>> 07:14:36.728454 IP 96.95.217.98.55659 > 96.86.170.229.5353: 16449 op8
> >>> [b2&3=0x4243] [17991a] [17477q] [18505n] [19019au][|domain]
> >>> 07:14:36.728465 IP 96.95.217.98.57523 > 96.86.170.229.5353: 16449 op8
> >>> [b2&3=0x4243] [17991a] [17477q] [18505n] [19019au][|domain]
> >>> 07:14:36.729032 IP 96.86.170.229.5353 > 96.95.217.98.48836: 16449 op8
> >>> FormErr- [0q] 0/0/0 (12)
> >>> 07:14:36.729165 IP 96.86.170.229.5353 > 96.95.217.98.55659: 16449 op8
> >>> FormErr- [0q] 0/0/0 (12)
> >>> 07:14:36.729272 IP 96.86.170.229.5353 > 96.95.217.98.57523: 16449 op8
> >>> FormErr- [0q] 0/0/0 (12)
> >>>
> >>> Curious if Al and/or others have same issue with 96.86.170.229.5353
> >>> UDP (which would make
> >>> it more probable issue is on/towards my end), or if it might be more
> >>> specific to the
> >>> linuxmafia.com / guido side of things - in which it might be closer to
> >>> that (Comcast Business) end of things.
> >>>
> >>> On Sun, Jun 2, 2024 at 10:34 PM Michael Paoli via BALUG-Admin
> >>> <balug-admin(a)lists.balug.org> wrote:
> >>>>
> >>>>
> >>>> +Al
> >>>> Uh oh ...
> >>>> the TLDR:
> >>>> looks like most likely it's a Comcast Business issue on my end.
> >>>> Anyway, I'll see if this apparently relatively new disservice that
> >>>> they've enabled that I never requested nor wanted, is anything I've got
> >>>> relatively simple access to disable that crud. And if that's not the case,
> >>>> looks like it'll be time for me to open a support ticket with 'em.
> >>>
> >>>
> >>>> And from guido:
> >>>>
> >>>> # traceroute -nUp 53 -m 15 96.86.170.229
> >>>> traceroute to 96.86.170.229 (96.86.170.229), 15 hops max, 60 byte packets
> >>>> 1 96.95.217.102 1.567 ms 1.714 ms 2.000 ms
> >>>> 2 10.61.209.67 10.034 ms 17.091 ms 17.308 ms
> >>>> 3 96.216.9.141 15.642 ms 16.185 ms 16.438 ms
> >>>> 4 68.85.154.113 15.559 ms 15.263 ms 68.85.154.117 17.271 ms
> >>>> 5 96.108.99.245 21.485 ms 96.108.99.249 23.446 ms 23.462 ms
> >>>> 6 68.86.143.89 21.394 ms 20.951 ms 68.86.143.93 20.611 ms
> >>>> 7 162.151.87.226 21.823 ms 162.151.86.58 18.559 ms 162.151.87.226 13.063 ms
> >>>> 8 162.151.78.186 17.808 ms 17.503 ms 162.151.79.134 19.191 ms
> >>>> 9 68.85.191.206 19.451 ms 68.85.103.154 19.450 ms 68.85.191.206 18.210 ms
> >>>> 10 73.189.65.18 25.648 ms 30.850 ms 30.607 ms
> >>>> 11 96.86.170.229 38.275 ms 38.315 ms 36.705 ms
> >>>> # traceroute -nUp 5353 -m 15 96.86.170.229
> >>>> traceroute to 96.86.170.229 (96.86.170.229), 15 hops max, 60 byte packets
> >>>> 1 96.95.217.102 1.510 ms 1.671 ms 1.922 ms
> >>>> 2 10.61.209.67 10.667 ms 10.61.209.66 16.563 ms 10.61.209.67 17.305 ms
> >>>> 3 96.216.9.141 16.927 ms 96.216.9.137 16.745 ms 16.855 ms
> >>>> 4 * 68.85.154.113 17.025 ms 17.141 ms
> >>>> 5 96.108.99.245 20.670 ms 96.108.99.249 51.907 ms 96.108.99.245 31.021 ms
> >>>> 6 68.86.143.89 19.265 ms 18.382 ms 68.86.143.93 16.142 ms
> >>>> 7 162.151.87.226 18.098 ms 162.151.86.58 12.378 ms 12.306 ms
> >>>> 8 162.151.78.186 11.393 ms 11.518 ms 16.363 ms
> >>>> 9 68.85.191.206 16.545 ms 16.623 ms 17.228 ms
> >>>> 10 73.189.65.18 32.347 ms 24.524 ms 30.043 ms
> >>>> 11 * * *
> >>>> 12 * * *
> >>>> 13 * * *
> >>>> 14 * * *
> >>>> 15 * * *
> >>>> #
> >>>> Bloody damn hell ...
> >>>> looks like most likely it's a Comcast Business issue on my end.
> >>>> I've got nothin' firewalling that, and should work fine.
Trying to figure out something in logfiles. Filtering down this
report just to sf-lug.com, balug.org, and savingthedolph.in DNS stuff,
as "retry limit exceeded" seems to be a recurring theme and I'd like to
figure out why (and fix).
----- Forwarded message from logcheck system account <logcheck(a)linuxmafia.com> -----
Date: Sun, 02 Jun 2024 15:02:01 -0700
From: logcheck system account <logcheck(a)linuxmafia.com>
To: root(a)linuxmafia.com
Subject: linuxmafia.com 2024-06-02 15:02 System Events
System Events
=-=-=-=-=-=-=
Jun 2 14:22:31 linuxmafia named[1093]: client 96.86.170.229#35399: received notify for zone 'balug.org'
Jun 2 14:24:01 linuxmafia named[1093]: zone balug.org/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0)
Jun 2 14:24:01 linuxmafia named[1093]: zone balug.org/IN: Transfer started.
Jun 2 14:24:01 linuxmafia named[1093]: transfer of 'balug.org/IN' from 96.86.170.229#5353: connected using 96.95.217.99#36846
Jun 2 14:24:01 linuxmafia named[1093]: zone balug.org/IN: transferred serial 1717363350
Jun 2 14:24:01 linuxmafia named[1093]: transfer of 'balug.org/IN' from 96.86.170.229#5353: Transfer completed: 1 messages, 8 records, 871 bytes, 0.080 secs (10887 bytes/sec)
Jun 2 14:28:07 linuxmafia named[1093]: zone sf-lug.org/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0)
Jun 2 14:28:07 linuxmafia named[1093]: zone sf-lug.org/IN: Transfer started.
Jun 2 14:28:07 linuxmafia named[1093]: transfer of 'sf-lug.org/IN' from 96.86.170.229#5353: connected using 96.95.217.99#40709
Jun 2 14:28:07 linuxmafia named[1093]: transfer of 'sf-lug.org/IN' from 96.86.170.229#5353: Transfer completed: 0 messages, 1 records, 0 bytes, 0.058 secs (0 bytes/sec)
Jun 2 14:52:03 linuxmafia named[1093]: zone savingthedolph.in/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0)
Jun 2 14:52:03 linuxmafia named[1093]: zone savingthedolph.in/IN: Transfer started.
Jun 2 14:52:03 linuxmafia named[1093]: transfer of 'savingthedolph.in/IN' from 96.86.170.229#5353: connected using 96.95.217.99#35512
Jun 2 14:52:03 linuxmafia named[1093]: transfer of 'savingthedolph.in/IN' from 96.86.170.229#5353: Transfer completed: 0 messages, 1 records, 0 bytes, 0.052 secs (0 bytes/sec)
Jun 2 14:58:05 linuxmafia named[1093]: zone sflug.com/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0)
Jun 2 14:58:05 linuxmafia named[1093]: zone sflug.com/IN: Transfer started.
Jun 2 14:58:05 linuxmafia named[1093]: transfer of 'sflug.com/IN' from 96.86.170.229#5353: connected using 96.95.217.99#47957
Jun 2 14:58:05 linuxmafia named[1093]: transfer of 'sflug.com/IN' from 96.86.170.229#5353: Transfer completed: 0 messages, 1 records, 0 bytes, 0.052 secs (0 bytes/sec)
----- End forwarded message -----
At tne command line (on my nameserver):
$ dig @96.86.170.229 sf-lug.com axfr | wc -l
36
$ dig @96.86.170.229 balug.org | wc -l
18
$ dig @96.86.170.229 savingthedolph.in | wc -l
19
$
I'm going to be lazy (and need to go out for an errand),
so will just say, WTF?
*chef's kiss*
Timo Reitnauer of Wellington, NZ was, indeed, the co-founder of the
original, NZ-based firm. The 2019 buyout caused layoff of the entire
existing staff, and I'm pretty sure Timo has no involvement in the
CentralNic-puppeteered firm based on London.
Still, amusing.
https://www.linkedin.com/posts/timo-reitnauer-237a5b1ab_im-keen-to-try-some…
----- Forwarded message from iwantmyname <help.support.iwantmyname.com(a)getveromail.com> -----
Date: Mon, 03 Jun 2024 05:07:13 +0000
From: iwantmyname <help.support.iwantmyname.com(a)getveromail.com>
To: rick(a)linuxmafia.com
Subject: Need any help with your iwantmyname account?
Reply-To: help(a)support.iwantmyname.com
Hey there,
I noticed that you don't have any domains in your iwantmyname account yet so I wanted to quickly check in to see how you're getting along.
Do you need a hand in buying a new domain name or transferring one from your previous registrar? Just hit the reply button and let me know how I can help you get started.
Cheers,
Timo Reitnauer
Co-Founder
https://iwantmyname.com
----- End forwarded message -----