Just to clarify, the notifies sent to Rick from your .229 were NAT-ed to your modem's WAN address. (Yes, yes, I know, that makes no sense, but it did it anyway. and I merely observe.) My question is, were the notifies going to Rick's port 5353 instead of 53? Or were they coming from your port 5353? Or both? Your answer will weigh heavily on my interpretation of what's going on and my design of an experiment here. Maybe Rick captured his named log that showed the 73.xxx number and he knows the port numbers on both ends. Rick probably sent it in an email, but a lot of messages to comb back through.
On 6/6/2024 18:54, Michael Paoli wrote:
Okay, adjusting Subject: to better track to ... well the subject.
In brief, from at least certain Comcast Business locations (first noticed on Rick's apparently same issue found from Al's), there's issue communicating from said clients to Internet UDP port 5353 at least with server 96.86.170.229. I also, in my earlier testing (but not when I first opened CR145359298 with Comcast business), discovered that server is receiving packets and responding apparently properly with packets. And other clients (e.g. when I tested from AWS, apparently also when you, Al, tested from AT&T) have no such issue. Also no problem if protocol is switched to TCP or port to 53. So, as I'd last reported to Comcast Business (after I'd figured out issue apparently wasn't on my (Comcast) end):
2024-06-03 11:26p-12:02a US/Pacific CR145359298 CR145359298 - issue appears to be on/towards other end, different Comcast Business account, address: 1105 ALTSCHUL AVE UNIT HMOFC MENLO PARK CA 94025 issue, client IP: 96.95.217.98/29 communication fails with UDP to server: 96.86.170.229 UDP port 5353 Also observed: Server receives and responds. Response packets never make it to client (96.95.217.98). If target port is changed to 53 or protocol changed to TCP, then client successfully receives reply packets. Also able to communicate from other Internet clients to server: 96.86.170.229 UDP port 5353
Anyway, that was before you, Al, confirmed you also have same issue from your Comcast Business.
As for testing, this is highly handy - it also tests to be sure the server is up and responsive over TCP and on UDP port 5353, before it even attempts 5353 UDP (in case the server is down or off-line - it isn't a particularly redundant highly available setup (email might mangle it slightly, but should be easy enough to unmangle), and this fresh test from 96.95.217.99 ([ns1.]linuxmafia.com.): $ (for po in '5353 +tcp' '53 +notcp +ignore' '5353 +notcp +ignore'; do set -- $po; time dig -p $* +nomultiline @96.86.170.229 +noall +answer sflug.com. SOA || break; done) sflug.com. 172800 IN SOA ns1.sf-lug.org. jim.well.com. 1716775812 10800 3600 3600000 86400
real 0m0.064s user 0m0.004s sys 0m0.000s sflug.com. 172800 IN SOA ns1.sf-lug.org. jim.well.com. 1716775812 10800 3600 3600000 86400
real 0m0.043s user 0m0.008s sys 0m0.000s ;; connection timed out; no servers could be reached
real 0m15.010s user 0m0.004s sys 0m0.004s $
Oh, and Al, you do still have login account on balug-sf-lug-v2.balug.org. (that's the canonical name for the VM that hosts BALUG.org, etc.), and even have some fair bits of sudo stuff there too ... if you'd like me to add some more sudo stuff so you can do some relevant tcpdump on ports 5353 and/53, just let me know and I can add that for you.
And ... yeah, we've all been guilty of it, certainly, including me, but perhaps bit better if we keep various separate unrelated (or not so related) emails in, well ... mostly separate emails ... and as relevant adjust the Subject: to track ... the (current) subject, that might make it bit easier to follow these things (and especially more easily find 'em later).
And NAT/SNAT shouldn't be relevant to this 5353 stuff and the IPs involved, nor should, e.g. Comcast Business's SecurityEdge (dis-)service be doing any mucking about interfering or breaking traffic, etc. (e.g. as it was earlier found to be doing on port 53 some months or so ago).
Anyway, also quite probable that whatever you (Al) find regarding Comcast Business and UDP port 5353 would also apply to Rick, as I believe you two are both still currently in the same situation on that (so if y'all both create tickets, or one does first and the other later, may want to cross-reference 'em to hopefully move things along more efficiently). And the one I'd opened on my end: CR145359298 so referencing that for starters may also help - but looks like the Comcast Business issue isn't on my end (at least thus far for this one).
On Thu, Jun 6, 2024 at 12:13 PM Al awbalug@sunnyside.com wrote:
Rick, Michael, Now that I've resolved the crazy static-IPv6-have-it-yet-don't snafu, fixed after 20 tickets and 3 weeks of pain and persistence, I'm ready to join your ticket(s) on 5353. First, of course, I want to be certain that I have it right so when I open a ticket (and link it to yours) I am describing the right thing.
I think what I'm hearing is that *outbound* 5353 UDP traffic gets NAT-ed to the modem WAN address and times out because Rick blocks unknown IPs? This seems to be an issue only over the Comcast network, because no one else is doing the crazy stuff with 5353. It only happens on destinations that are on Comcast but that's just an artifact because we have not tried other 5353 sites. Aren't any probably that we know of that are handy?
I assume that understanding may be way off, but that's my opening remark.
I do not get the impression that 5353 is being blocked as an incoming message by Comcast. The assumption I think is that this is some sort of undocumented 'feature' of something some bozo thought was helpful regarding MDNS / Zero Config. No other ISP we know of seems to have had the same brain fail over this 'helpful' behavior AFAIK.
Also need to know which of the two ticket #s I see mentioned I should join.
Once I hear from you guys whether I have this right, and verify the behavior, I'll proceed with tickets.
tnx Al
On 6/4/2024 22:35, Rick Moen wrote:
Quoting Michael Paoli (michael.paoli@berkeley.edu):
Many will, by default, issue NOTIFY from all authoritative nameservers. At first that might seem odd, but, I believe the logic goes about like this: the overhead is low clients that don't care can/will (mostly) ignore authoritative (whether primary or secondary) has no way of knowing how other authoritatives downstream of it are configured, so, e.g. some authoritatives may only get their data via other secondary(/ies), and not direct from master, etc.
Yes, as I was saying, I had a faint recollection that the matter of Aaron T. Porter's ns.primate.net issuing NOTIFY for domains on which it's secondary, not primary, had come up in some of my earlier efforts to puzzle out strange nameserver behaviour. I just couldn't remember exactly how that had unfolded -- other than my obviously having decided to take no action.
Obviously it's at worst harmless, and I can/should just add another "ignore" line to the logcheck configuration so I stop being told about it. I just was taking a moment to try to figure out whether this is deliberate behaviour and why it's there. Your answer will serve splendidly. Although, I'm bothered that the usual information sources don't seem to cover this.
On the third hand, I didn't look _too_ closely, e.g,, maybe it's covered in the Zytrax's "DNS for Rocket Scientists" or the related dead-tree book _Pro DNS and BIND_.
Slightly weird, anyway.