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 Alawbalug@sunnyside.com -----
Date: Tue, 4 Jun 2024 16:29:04 -0700 From: Alawbalug@sunnyside.com To: Rick Moenrick@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