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