[BALUG-Admin] Comcast & 5353 UDP

[Al]

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.