FYI, did send this out:
---------- Forwarded message ---------
From: Michael Paoli <michael.paoli(a)berkeley.edu>
Date: Mon, Jul 15, 2024 at 11:54 PM
Subject: Mailman 3 listadmin testing (and potential hosting) available
To: Grant Bowman <grantbow(a)gmail.com>, Grant Bowman
<grantbow(a)dvlug.org>, Aaron <acohen36(a)gmail.com>, Tom
<tomrlopes(a)gmail.com>, Ian <droid1836(a)gmail.com>, Rick Moen
<rick(a)linuxmafia.com>, Al <aw009(a)sunnyside.com>
Various SF Bay Area [L]UG(s) [potential] list admin folk(s),
May potentially be some additional folks (if interested, contact me).
Thought I'd invite, for possible testing, etc. some folks that are
list admins of various SF Bay Area [L]UG(s), or might be potentially
very seriously interested in that.
Most notably, have Mailman 3 fairly well set up (at least metastable)
on the BALUG VM (still have more Mailman 2 --> Mailman 3 migration
steps to fully test out and validate before I do all those migrations
for the production lists, including related infrastructure of automation
and information, etc.).
In those regards, if folks are interested in a test list on there for
potentially testing for [L]UG use and list administration thereof,
just let me know. Note that there are test list(s) there currently
(notably balug-test3(a)lists.balug.org which is on Mailman 3 and will
eventually become and be merged into balug-test(a)lists.balug.org
when that gets migrated to Mailman 3), but I was thinking more
significantly and distinct from that, list(s) where I could grant folks
full listadmin access and control. E.g.:
sf-lug-test(a)lists.balug.org
dvlug-test(a)lists.balug.org
berkeleylug-test(a)lists.balug.org
etc.
Could even do different (sub)domains, e.g.:
@lists.dvlug.org
@lists.sf-lug.org
etc., though subdomains would require some fair bit of additional
work/coordination to set that all up properly (DNS, SPF, TLS, ...)
so @lists.balug.org would be the simpler easier place to start and is
already available.
Anyway, if interested, let me know (and notably list name).
If you merely want to test list, can use the existing
balug-test3(a)lists.balug.org e.g.
send email to: balug-test3-subscribe(a)lists.balug.org to subscribe
or see:
https://lists.balug.org/mailman3/postorius/lists/balug-test3.lists.balug.or…
And yes, for at least many (SF [L]UG lists), I'd be willing to host on
the BALUG VM (and in general they could have their own subdomain,
in fact for actual general production use that would be exceedingly
recommended, e.g. something like, say for SF-LUG:
sf-lug(a)lists.sf-lug.org
sf-lug-test(a)lists.sf-lug.org)
But even if one mostly wants to reasonably well test out Mailman 3 and
list administration thereof, the BALUG VM may be a useful place to be
able to reasonably well do that (want to test drive Mailman 3 and see if
it might make suitable list infrastructure for your [L]UG?).
> From: Michael Paoli <michael.paoli(a)berkeley.edu>
> Date: Sat, Jun 29, 2024 at 1:52 PM
> Subject: Re: dvlug list
> To: Grant Bowman <grantbow(a)gmail.com>
> Cc: Diablo Valley Linux Users Group (DVLUG) <dvlug(a)linuxmafia.com>,
> Diablo Valley Linux Users Group (DVLUG) <list(a)dvlug.org>
>
> Grant,
...
> Oh, ... I'll also hang it out there for your consideration, if you
> may be interested ... if you may possibly want to have subdomain with
> DVLUG list(s) on <whatever>@lists.dvlug.org., I could potentially
> host that if you so wanted that ... but maybe ask me again in a
> couple weeks or so ... I'm still doing migration off of mailman
> version 2 (could do mailman 2 in the meantime if you really wanted
> that), so still have more testing, etc. to do, and want to wait a bit
> 'till that's all done and the dust well settled before I consider
> that migration to be a full success (in case I find any latent issues
> that may not be immediately apparent). I'd also think Rick might
> even be willing to do same (notably subdomain part for list) on the
> existing linuxmafia.com host. In any case, food for thought. Could
> also potentially migrate so all the old (most notably archives) would
> still also be present under lists.dvlug.org (similar to how things
> are for BALUG under lists.balug.org). Anyway, just a thought, and
> thought I'd hang the offer out there if you may be interested (and
> would also have the capability to access and back up full archives,
> also member subscription list). And, yeah just to think about it
> more generally, if you use a subdomain (e.g. lists.dvlug.org) for
> list(s), rather than the main domain (dvlug.org), that does leave
> things much more flexible for how one may want to handle list(s),
> most notably it can be hosted or the like, exceedingly independent of
> whatever else may be going on for hosting or whatever on
> [www.]dvlug.org (e.g. web site, etc.).
More of same, involving back-to-back NOTIFY traffic about mpaoli.net,
allegedly originating from master nameserver 96.86.170.226 . Michael, I
greatly doubt your nameserver is doing this. mpaoli.net's zonefile is
pretty unchanging. I suspect Comcast middleman fsckery. Thoughts?
----- Forwarded message from logcheck system account <logcheck(a)linuxmafia.com> -----
Date: Tue, 04 Jun 2024 02:02:01 -0700
From: logcheck system account <logcheck(a)linuxmafia.com>
To: root(a)linuxmafia.com
Subject: linuxmafia.com 2024-06-04 02:02 System Events
System Events
=-=-=-=-=-=-=
Jun 4 01:47:15 linuxmafia named[15622]: zone mpaoli.net/IN: Transfer started.
Jun 4 01:47:15 linuxmafia named[15622]: transfer of 'mpaoli.net/IN' from 96.86.170.226#53: connected using 96.95.217.99#52012
Jun 4 01:47:15 linuxmafia named[15622]: zone mpaoli.net/IN: transferred serial 1717468800
Jun 4 01:47:15 linuxmafia named[15622]: transfer of 'mpaoli.net/IN' from 96.86.170.226#53: Transfer completed: 1 messages, 6 records, 546 bytes, 0.064 secs (8531 bytes/sec)
Jun 4 02:00:09 linuxmafia named[15622]: zone mpaoli.net/IN: Transfer started.
Jun 4 02:00:09 linuxmafia named[15622]: transfer of 'mpaoli.net/IN' from 96.86.170.226#53: connected using 96.95.217.99#57758
Jun 4 02:00:09 linuxmafia named[15622]: zone mpaoli.net/IN: transferred serial 1717491608
Jun 4 02:00:09 linuxmafia named[15622]: transfer of 'mpaoli.net/IN' from 96.86.170.226#53: Transfer completed: 1 messages, 15 records, 1266 bytes, 0.072 secs (17583 bytes/sec)
----- End forwarded message -----
Ah ... sounds good.
So ... I'm guessing soon...ish, you'll have
2603:3024:180d:f100:50:242:105:34 (nsx.sunnyside.com.)
operational again (no extreme rush) ... or at least nsx.sunnyside.com.
regaining an operational AAAA that also works for DNS.
I noticed earlier it wasn't working ... then subsequently
you apparently dropped the AAAA record for it
(perfectly fine thing to do while it's not working!)
... I did try the IP directly - still no DNS response,
but I note also that that AAAA record hasn't been
restored yet either ... or any AAAA record for that domain.
$ eval dig @ns0.sunnysidex.com. +noall +answer +norecurse
nsx.sunnyside.com.\ A{,AAA}
nsx.sunnyside.com. 600 IN A 50.242.105.52
$
https://dnsviz.net/d/balug.org/Zl6vNw/responses/https://dnsviz.net/d/balug.org/ZmGAnw/responses/https://dnsviz.net/d/balug.org/ZmHuow/responses/
> 19 tickets closed almost immediately without comment
Let's see, if we have a ticketing system, and highly
incentivized folks to close tickets quickly, we get ...
lots of tickets closed quickly ... doesn't mean anything
gets fixed. And yes, have seen this before ... alas, even
in some departments/areas at some employers I've
worked at.
"Be careful what you measure." (And how one uses it).
Same employer, a much more astute manager with a
much better functioning department ... how did they
do it? They surveyed the customers, and used that
as a large measure of determining how well the technicians were
doing at getting issues solved ... not how quickly
the techs closed tickets. Alas, that highly well
performing department stuck out like a sore
thumb ... so ... eventually management "fixed"
that issue ... by subsuming that department into
the other, thus ensuring there wouldn't be such
a good standout to embarrass the rest.
Anyway, glad your Comcast issue finally got resolved.
< From: Michael Paoli <michael.paoli(a)berkeley.edu>
< Date: Tue, Jun 4, 2024 at 4:21\xe2\x80\xafPM
< Subject: Re: [BALUG-Admin] (forw) linuxmafia.com 2024-06-04 02:02
System Events
< To: Rick Moen <rick(a)linuxmafia.com>
< Cc: BALUG-Admin <balug-admin(a)lists.balug.org>, Al <aw009(a)sunnyside.com>
<
< And thirdly - relatively minor issue. Al's got
< (at least last I checked, yesterday or so) issues with
< 2603:3024:180d:f100:50:242:105:34 (nsx.sunnyside.com.)
< not responding.
On Thu, Jun 6, 2024 at 7:45 AM Al <aw009(a)sunnyside.com> wrote:
>
> The manager that took one of my tickets and refused to let it be closed has helped me to finally get my case resolved.
> I have tested access from AWS successfully, and the modem does in fact seem to have my /56 back in it instead of what
> looked very much like a dynamic /64.
> It's also amazing that anyone talked to me at all. I had 19 tickets closed almost immediately without comment.
>
>
> -------- Forwarded Message --------
> Subject: Comcast Service Ticket CR144883981
> Date: Thu, 6 Jun 2024 14:12:18 +0000
> From:
> To: awcomcast(a)sunnyside.com <awcomcast(a)sunnyside.com>
>
>
> Good morning,
>
>
>
> I am reaching out to you in regards to ticket CR144883981. This was in regards to reclaiming your original IPv6 prefix. I worked with our device support, and we were able to reclaim 2603:3024:180d:f100 for you. As of this morning, the IPv6 has been restored onto your modem.
>
>
>
>
>
> Thank you for using Comcast,
>
>
>
> Shana Rich
>
> Tech 4, CSSA (ABS)
>
> Complex & Strategic Service Assurance
>
> Avail Hours Mon-Fri, 8:00am – 4:30pm MST
>
> Comcast Business Services
----- Forwarded message from Al <awbalug(a)sunnyside.com> -----
Date: Tue, 4 Jun 2024 16:29:04 -0700
From: Al <awbalug(a)sunnyside.com>
To: Rick Moen <rick(a)linuxmafia.com>
Subject: Re: [BALUG-Admin] Comcast Business apparently blocking 5353 UDP Re:
linuxmafia.com "retry limit exceeded"
Rick, you're at the right place - that gear icon and right side panel
on business.comcast.com is just the right thing.
And I think the situation as you're outlining it is right to me. So
the answer to your question, broadly, is yes I think you have it
right.
If you end up at securityedge.comcast.com, IMHO you've gone too far.
My sense is that all that stuff is disabled back at the right side
panel...
Once SE (security edge) is disabled I think everything is. That
said, you're being smart about it - if symptoms persist, drill down
and look into individual
settings for various elements of SE and just make sure they're all off
- in case Comcast can't quite sort out how to actually disable stuff.
AFAIK however your nets (yours and Michaels) are unrestricted.
My tests from here are that access to both 96.86.170.229 and
96.95.217.99 on port 53 is not blocked (and not just those /32s but
the entire subnet in each case).
I am looking back over email from the last few days trying to sort out
where 73.189.65.18 crept into the conversation.
As I mentioned I have been unable to focus sufficiently on this the
last few days, and missed where that came from.
I also haven't looked closely enough at the discussion to see if what
I am trying to reproduce isn't exactly where you're having trouble.
I'll go back over the notes and see if I can pay more attention to the
details and whether I can actually add any insight to the discussion.
Al
----- End forwarded message -----
To clarify, I noticed "73.189.65.18" as the source of NOTIFYs for
Michael's domains, which can legitimately come _only_ from Michael's
authoritative nameserver, IP 96.86.170.229.
And 73.189.65.18 is Comcast's _own_ IP, not Michael's.
:r! dig -x 73.189.65.18 +short
c-73-189-65-18.hsd1.ca.comcast.net.
So, something is rotten, there. I'm immediately inclined to suspect
that Comcast is playing man-in-the-middle games with DNS traffic.
Which, if true, suggest Comcast acting like a rogue state security
agency or one operating on behalf of a totalitarian state. Not a good
look.
FYI, there's new root hints file as of 2024-05-28:
https://www.internic.net/domain/named.root
see also:
https://www.iana.org/domains/root/files
Also, Debian stable isn't quite caught up to that yet (though
I expect it will likely be with upcoming stable update).
And yes, "newer" (/non-ancient) BIND versions
are "smart" enough to catch this, notice, and complain
(the bit in the logs was what first caught my attention on it).
times UTC / GMT0:
# cat /etc/debian_version; sed -ne '3,4p;4q'
/etc/bind/named.conf.default-zones && dpkg -S
/usr/share/dns/root.hints && dpkg -l dns-root-data | grep '^ii '; diff
-U0 /usr/share/dns/root.hints <(su - test -c 'curl -s
https://www.internic.net/domain/named.root')
12.5
type hint;
file "/usr/share/dns/root.hints";
dns-root-data: /usr/share/dns/root.hints
ii dns-root-data 2023010101 all DNS root data including
root zone and DNSSEC key
--- /usr/share/dns/root.hints 2023-01-11 07:22:00.000000000 +0000
+++ /dev/fd/63 2024-06-05 05:57:26.860941086 +0000
@@ -12,2 +12,2 @@
-; last update: January 01, 2023
-; related version of root zone: 2023010101
+; last update: May 28, 2024
+; related version of root zone: 2024052801
@@ -24,2 +24,2 @@
-B.ROOT-SERVERS.NET. 3600000 A 199.9.14.201
-B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:200::b
+B.ROOT-SERVERS.NET. 3600000 A 170.247.170.2
+B.ROOT-SERVERS.NET. 3600000 AAAA 2801:1b8:10::b
#
May 12 20:45:20 tigger named[3452]: checkhints: b.root-servers.net/A
(170.247.170.2) missing from hints
May 12 20:45:20 tigger named[3452]: checkhints: b.root-servers.net/A
(199.9.14.201) extra record in hints
May 12 20:45:20 tigger named[3452]: checkhints:
b.root-servers.net/AAAA (2801:1b8:10::b) missing from hints
May 12 20:45:20 tigger named[3452]: checkhints:
b.root-servers.net/AAAA (2001:500:200::b) extra record in hints
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)