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

[Al]

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 
<https://www.speedguide.net/port.php?port=5353>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.balug.org/pipermail/balug-admin/attachments/20240604/e383062e/attachment-0001.htm>