[BALUG-Admin] (forw) Re: Comcast Business apparently blocking 5353 UDP Re: linuxmafia.com "retry limit exceeded"

Wed Jun 5 04:05:22 UTC 2024

Al, yep, I think you more-or-less found same.
And ... yeah, "interesting" ... and, alas, not surprising,
you find same issues from your Comcast network, but not your
other network(s) (e.g. AT&T if I'm not mistaken).
Likewise I saw no issue when I tried the other day from AWS.
And 5353 ... shouldn't matter.  In general ISP shouldn't be blocking
ports without customer's knowledge and consent.  They are
after all an Internet Service Provider, so should be providing
service to The Internet, not disservice of semi-randomly blocking
or interfering with such communication flows ... yet with
Comcast [Business] we have/find ... ugh, yeah, that.
Anyway, some months ago, 5353 worked perfectly fine.
That was originally put in place as work-around for
Comcast Business's screwing around with 53  notably
breaking 53 with their SecurityEdge goop.
Once that had been addressed and was working again,
took out 5353 ... until Comcast again broke 53, then put
the 5353 back - this time intending it to be for longer term.
Last I looked and Comcast's track record, I'm inclined to leave
it there at least for a continuous year's time of Comcast not
screwing it (at least 53) up ... hasn't been a year's time yet,
so I've not decommissioned the 5353 workaround.
And no, I'm not willing to reconfigure to a different alternative work-around
port every time Comcast changes and breaks the current workaround port.
Not going there.  This sh*t should work, and Comcast ought not be
fscking around with it and continuing to, and unpredictably at that,
break things.  So, at current they've broken 5353 ... dear knows what
else they've broken that we don't even know about because we haven't
explicitly tested or otherwise noticed.  But ISPs shouldn't be breaking
things like that.  But, alas, ... Comcast ... and Comcast Business, at that.

Anyway, that shouldn't be broken.  So, if you (Al) also want to open support
case with Comcast, please feel free, and can also cross-reference that
Comcast ticket # which I earlier noted and also passed along to Rick.
If you don't have the direct # for the tech on that ticket #, let me know, and I
can (off-list) pass that to you too (but I think that may also be
on-list with at
least one of these list postings?).
Anyway, at persent, I've got that service (also) on 5353, and current plans
are to continue that until at least ...
$ grep -F -e 5353 ~/calendar
2024-09-24 >= 10:56AM US/Pacific PST8PDT -07:00, if Comcast Business
hasn't screwed up DNS with linuxmafia.com for more than a year,
probably time to remove the port 5353 work-arounds.
$
And since that's not a super high availability service (e.g. no
redundancy on ISP or AC power, etc.),
often prudent to be sure it's up first, e.g. check on TCP or port 53 -
as I did in that earlier test script,
it only proceeds to 5353 UDP if the preceding tests with 5353 TCP and
UDP 53 are successful.
And, shown again here for convenience, if one doesn't have it handy:
time dig -p 5353 +tcp +nomultiline @96.86.170.229 +noall +answer
sflug.com. SOA && time dig -p 53 +notcp +ignore +nomultiline
@96.86.170.229 +noall +answer sflug.com. SOA && time dig -p 5353
+notcp +ignore +nomultiline @96.86.170.229 +noall +answer sflug.com.
SOA

On Tue, Jun 4, 2024 at 6:11 PM Al <aw009@sunnyside.com> wrote:
>
> ooooooohhhh, that's weird and yucky.  something rotten in CC BUS land.
> I wonder if Michael looks at his modem internal page whether that 73.x.xxx addr is his modem's upstream WAN address, or maybe the upstream router's IP?
> IIRC Michael already look at the modem config page, so I guess that's already been checked.
> I know if I traceroute to Michael, I don't see 73.anything.
>
> I just set up a  better test and I can dig on 53 or 5353 just fine, EXCEPT when I do it from my Comcast Business IPv4 net.
> That times out.
> So I think that's the same problem you all are describing.
>
> I think 5353 was picked just because it was handy, but it's also the multicast DNS port or something.  I wonder if 5454 or some such would show up unscathed (see via tcpdump).
>
> I wonder if MDNS is part of Comcast's problem.  Or maybe the modem has a virus, since 5353 is widely used by exploits.  For the partial but extensive list see
> Port 5353 (tcp/udp) :: SpeedGuide
>
> On 6/4/2024 17:14, Rick Moen wrote:
>
> ----- Forwarded message from Al <awbalug@sunnyside.com> -----
>
> Date: Tue, 4 Jun 2024 16:29:04 -0700
> From: Al <awbalug@sunnyside.com>
> To: Rick Moen <rick@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.
>
>
>
> _______________________________________________
> BALUG-Admin mailing list
> BALUG-Admin@lists.balug.org
> https://lists.balug.org/cgi-bin/mailman/listinfo/balug-admin
>
>
> _______________________________________________
> BALUG-Admin mailing list
> BALUG-Admin@lists.balug.org
> https://lists.balug.org/cgi-bin/mailman/listinfo/balug-admin