[BALUG-Admin] Comcast & 5353 UDP (was: NOTIFY should only ever come from)

[Michael Paoli]

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.