Trying to figure out something in logfiles. Filtering down this report just to sf-lug.com, balug.org, and savingthedolph.in DNS stuff, as "retry limit exceeded" seems to be a recurring theme and I'd like to figure out why (and fix).
----- Forwarded message from logcheck system account logcheck@linuxmafia.com -----
Date: Sun, 02 Jun 2024 15:02:01 -0700 From: logcheck system account logcheck@linuxmafia.com To: root@linuxmafia.com Subject: linuxmafia.com 2024-06-02 15:02 System Events
System Events =-=-=-=-=-=-= Jun 2 14:22:31 linuxmafia named[1093]: client 96.86.170.229#35399: received notify for zone 'balug.org' Jun 2 14:24:01 linuxmafia named[1093]: zone balug.org/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0) Jun 2 14:24:01 linuxmafia named[1093]: zone balug.org/IN: Transfer started. Jun 2 14:24:01 linuxmafia named[1093]: transfer of 'balug.org/IN' from 96.86.170.229#5353: connected using 96.95.217.99#36846 Jun 2 14:24:01 linuxmafia named[1093]: zone balug.org/IN: transferred serial 1717363350 Jun 2 14:24:01 linuxmafia named[1093]: transfer of 'balug.org/IN' from 96.86.170.229#5353: Transfer completed: 1 messages, 8 records, 871 bytes, 0.080 secs (10887 bytes/sec) Jun 2 14:28:07 linuxmafia named[1093]: zone sf-lug.org/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0) Jun 2 14:28:07 linuxmafia named[1093]: zone sf-lug.org/IN: Transfer started. Jun 2 14:28:07 linuxmafia named[1093]: transfer of 'sf-lug.org/IN' from 96.86.170.229#5353: connected using 96.95.217.99#40709 Jun 2 14:28:07 linuxmafia named[1093]: transfer of 'sf-lug.org/IN' from 96.86.170.229#5353: Transfer completed: 0 messages, 1 records, 0 bytes, 0.058 secs (0 bytes/sec) Jun 2 14:52:03 linuxmafia named[1093]: zone savingthedolph.in/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0) Jun 2 14:52:03 linuxmafia named[1093]: zone savingthedolph.in/IN: Transfer started. Jun 2 14:52:03 linuxmafia named[1093]: transfer of 'savingthedolph.in/IN' from 96.86.170.229#5353: connected using 96.95.217.99#35512 Jun 2 14:52:03 linuxmafia named[1093]: transfer of 'savingthedolph.in/IN' from 96.86.170.229#5353: Transfer completed: 0 messages, 1 records, 0 bytes, 0.052 secs (0 bytes/sec) Jun 2 14:58:05 linuxmafia named[1093]: zone sflug.com/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0) Jun 2 14:58:05 linuxmafia named[1093]: zone sflug.com/IN: Transfer started. Jun 2 14:58:05 linuxmafia named[1093]: transfer of 'sflug.com/IN' from 96.86.170.229#5353: connected using 96.95.217.99#47957 Jun 2 14:58:05 linuxmafia named[1093]: transfer of 'sflug.com/IN' from 96.86.170.229#5353: Transfer completed: 0 messages, 1 records, 0 bytes, 0.052 secs (0 bytes/sec)
----- End forwarded message -----
At tne command line (on my nameserver):
$ dig @96.86.170.229 sf-lug.com axfr | wc -l 36 $ dig @96.86.170.229 balug.org | wc -l 18 $ dig @96.86.170.229 savingthedolph.in | wc -l 19 $
I'm going to be lazy (and need to go out for an errand), so will just say, WTF?
Quoting Rick Moen (rick@linuxmafia.com):
Trying to figure out something in logfiles. Filtering down this report just to sf-lug.com, balug.org, and savingthedolph.in DNS stuff, as "retry limit exceeded" seems to be a recurring theme and I'd like to figure out why (and fix).
It may be utterly coincidental that all of those are sockets to port 5353 (rather than 53) on 96.86.170.229 . Or not. I remember that said configuration on both of our ends was a workaround for the fsckery imposed on my uplink by Comcast Business, quite a while ago. Thoughts?
Lots of searching on "refresh: retry limit for master exceeded" suggest that error is often caused by firewalling that blocks UDP packets.
I _think_ the +notcp flag on dig forces UDP, albeit that would be the default for simple queries anyway.
$ dig @96.86.170.229 balug.org +notcp | wc -l 18 $ dig @96.86.170.229 balug.org | wc -l 18 $
But, oh hey, lookie here, when we query 5353:
$ dig -p 5353 @96.86.170.229 balug.org ;; connection timed out; no servers could be reached $
Yeah, that would be a problem.
Right, commenting out all these in /etc/bind/named.conf.local :
96.86.170.229 port 5353; // workaround
Checking my work.
$ grep 5353 /etc/bind/named.conf.local //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround //96.86.170.229 port 5353; // workaround $
Implementing:
linuxmafia:/etc/bind# rndc reconfig linuxmafia:/etc/bind
+Al Uh oh ... the TLDR: looks like most likely it's a Comcast Business issue on my end. Anyway, I'll see if this apparently relatively new disservice that they've enabled that I never requested nor wanted, is anything I've got relatively simple access to disable that crud. And if that's not the case, looks like it'll be time for me to open a support ticket with 'em.
Yeah, ... originally implemented port 5353 as workaround for Comcast Business DNS fckery that they call SecurityEdge. Disabled the work-around when it was working again, ... then Comcast Business broke it again. Then renabled the port 5353 workaround again.
I then said, some while back, <~=2023-09-27:
Quoting Michael Paoli (michael.paoli@cal.berkeley.edu):
As for the 10 LUG (etc. and reated) zones where that port 5353 workaround was (re)implemented, probably leave that workaround in place 'till Comcast Business makes it 6+ or 12+ months without screwing that up again ... then likely take it out after that ... but I feel no rush on that, and in the meantime, if Comcast Business screws up again in same or highly similar manner on that, at least those 10 zones still currently have that workaround in place.
But ... I ought put the clean-up on my calendar for a year hence relative to last it was confirmed fixed. So, let's see ... last resolved around ... http://linuxmafia.com/pipermail/sf-lug/2023q3/015928.html
And, it appears at least for the moment, the issue is "resolved" by 2023-09-24 10:56AM US/Pacific PST8PDT -07:00.
So, now noted on my calendar for 2024-09-24: $ grep -F -i 2024-09-24 ~/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. $ In the meantime, yeah, it will probably log some of those spurious entries, as, with or without notify, when it checks (and especially right after getting notify), it will check the master(s) it's configured for, and if they're current it wil so note/log. And, since with both default port of 53 and alternative work-around of 5353, it'll check both, and once caught up (even if it just caught up on the other), the other port will then end up with it noting/logging that it's already current - it really has no way of knowing that the two different ports are the same server, nor should it need or care to know. As far as the client is concerned, they are or may be entirely separate (and presumably redundant) masters. Any multi-master setup, even without the additional port 5353 might similarly note/log such messages, e.g. receives notify, checks, and finds it's current. Sometimes other actions, such as restart of server, may also trigger such notify messages (and likewise logging on client side), notably if the client is already current.
Anyway, since Comcast Business gave us that problem and all that grief not once, but twice, I'll still inclined to wait out the whole year's time without such issue recurrence before removing the port 5353 work-around. And that may not make all such messages/logging go away, but would certainly reduce such occurrences.
As for the retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0) Not sure what's up with that, did try, from linuxmafia.com. as client, AXFR with server ports of both 53 and 5353, and saw no issues
Let me try wee bit again ... $ hostname && ip -4 a s | fgrep inet | fgrep -v 127.0.0.1 linuxmafia.com inet 96.95.217.99/29 brd 96.95.217.103 scope global eth2 $ (domains='balug.org. savingthedolph.in. sf-lug.org. sflug.com.'; digopts='+nomultiline'; NSIP=96.86.170.229; for domain in $domains; do for NSport in 53 5353; do echo dig -p "$NSport" $digopts @"$NSIP" +noall +answer "$domain" AXFR | wc -l; dig -p "$NSport" $digopts @"$NSIP" +noall +answer "$domain" AXFR | wc -l; done; done; for domain in $domains; do for NSport in 53 5353; do echo dig -p "$NSport" $digopts @"$NSIP" +noall +answer "$domain" SOA; dig -p "$NSport" $digopts @"$NSIP" +noall +answer "$domain" SOA; echo dig -p "$NSport" $digopts +tcp @"$NSIP" +noall +answer "$domain" SOA; dig -p "$NSport" $digopts +tcp @"$NSIP" +noall +answer "$domain" SOA; done; done) dig -p 53 +nomultiline @96.86.170.229 +noall +answer balug.org. AXFR | wc -l 1024 dig -p 5353 +nomultiline @96.86.170.229 +noall +answer balug.org. AXFR | wc -l 1024 dig -p 53 +nomultiline @96.86.170.229 +noall +answer savingthedolph.in. AXFR | wc -l 65 dig -p 5353 +nomultiline @96.86.170.229 +noall +answer savingthedolph.in. AXFR | wc -l 65 dig -p 53 +nomultiline @96.86.170.229 +noall +answer sf-lug.org. AXFR | wc -l 58 dig -p 5353 +nomultiline @96.86.170.229 +noall +answer sf-lug.org. AXFR | wc -l 58 dig -p 53 +nomultiline @96.86.170.229 +noall +answer sflug.com. AXFR | wc -l 30 dig -p 5353 +nomultiline @96.86.170.229 +noall +answer sflug.com. AXFR | wc -l 30 dig -p 53 +nomultiline @96.86.170.229 +noall +answer balug.org. SOA balug.org. 3600 IN SOA ns0.balug.org. hostmaster.balug.org. 1717387084 10800 3600 3600000 86400 dig -p 53 +nomultiline +tcp @96.86.170.229 +noall +answer balug.org. SOA balug.org. 3600 IN SOA ns0.balug.org. hostmaster.balug.org. 1717387084 10800 3600 3600000 86400 dig -p 5353 +nomultiline @96.86.170.229 +noall +answer balug.org. SOA ;; connection timed out; no servers could be reached dig -p 5353 +nomultiline +tcp @96.86.170.229 +noall +answer balug.org. SOA balug.org. 3600 IN SOA ns0.balug.org. hostmaster.balug.org. 1717387084 10800 3600 3600000 86400 dig -p 53 +nomultiline @96.86.170.229 +noall +answer savingthedolph.in. SOA savingthedolph.in. 3600 IN SOA ns0.savingthedolph.in. Michael.Paoli.cal.berkeley.edu. 1717069309 3600 1200 3600000 3600 dig -p 53 +nomultiline +tcp @96.86.170.229 +noall +answer savingthedolph.in. SOA savingthedolph.in. 3600 IN SOA ns0.savingthedolph.in. Michael.Paoli.cal.berkeley.edu. 1717069309 3600 1200 3600000 3600 dig -p 5353 +nomultiline @96.86.170.229 +noall +answer savingthedolph.in. SOA ;; connection timed out; no servers could be reached dig -p 5353 +nomultiline +tcp @96.86.170.229 +noall +answer savingthedolph.in. SOA savingthedolph.in. 3600 IN SOA ns0.savingthedolph.in. Michael.Paoli.cal.berkeley.edu. 1717069309 3600 1200 3600000 3600 dig -p 53 +nomultiline @96.86.170.229 +noall +answer sf-lug.org. SOA sf-lug.org. 3600 IN SOA ns0.sf-lug.org. jim.well.com. 1717297074 10800 3600 3600000 86400 dig -p 53 +nomultiline +tcp @96.86.170.229 +noall +answer sf-lug.org. SOA sf-lug.org. 3600 IN SOA ns0.sf-lug.org. jim.well.com. 1717297074 10800 3600 3600000 86400 dig -p 5353 +nomultiline @96.86.170.229 +noall +answer sf-lug.org. SOA ;; connection timed out; no servers could be reached dig -p 5353 +nomultiline +tcp @96.86.170.229 +noall +answer sf-lug.org. SOA sf-lug.org. 3600 IN SOA ns0.sf-lug.org. jim.well.com. 1717297074 10800 3600 3600000 86400 dig -p 53 +nomultiline @96.86.170.229 +noall +answer sflug.com. SOA sflug.com. 172800 IN SOA ns1.sf-lug.org. jim.well.com. 1716775812 10800 3600 3600000 86400 dig -p 53 +nomultiline +tcp @96.86.170.229 +noall +answer sflug.com. SOA sflug.com. 172800 IN SOA ns1.sf-lug.org. jim.well.com. 1716775812 10800 3600 3600000 86400 dig -p 5353 +nomultiline @96.86.170.229 +noall +answer sflug.com. SOA ;; connection timed out; no servers could be reached dig -p 5353 +nomultiline +tcp @96.86.170.229 +noall +answer sflug.com. SOA sflug.com. 172800 IN SOA ns1.sf-lug.org. jim.well.com. 1716775812 10800 3600 3600000 86400 $
Yeah, ... there's something up with UDP to port 5353 from linuxmafia.com to 96.86.170.229. Uhm, likewise if I try from guido. But works fine if I, e.g. try locally on my subnet.
And from guido:
# traceroute -nUp 53 -m 15 96.86.170.229 traceroute to 96.86.170.229 (96.86.170.229), 15 hops max, 60 byte packets 1 96.95.217.102 1.567 ms 1.714 ms 2.000 ms 2 10.61.209.67 10.034 ms 17.091 ms 17.308 ms 3 96.216.9.141 15.642 ms 16.185 ms 16.438 ms 4 68.85.154.113 15.559 ms 15.263 ms 68.85.154.117 17.271 ms 5 96.108.99.245 21.485 ms 96.108.99.249 23.446 ms 23.462 ms 6 68.86.143.89 21.394 ms 20.951 ms 68.86.143.93 20.611 ms 7 162.151.87.226 21.823 ms 162.151.86.58 18.559 ms 162.151.87.226 13.063 ms 8 162.151.78.186 17.808 ms 17.503 ms 162.151.79.134 19.191 ms 9 68.85.191.206 19.451 ms 68.85.103.154 19.450 ms 68.85.191.206 18.210 ms 10 73.189.65.18 25.648 ms 30.850 ms 30.607 ms 11 96.86.170.229 38.275 ms 38.315 ms 36.705 ms # traceroute -nUp 5353 -m 15 96.86.170.229 traceroute to 96.86.170.229 (96.86.170.229), 15 hops max, 60 byte packets 1 96.95.217.102 1.510 ms 1.671 ms 1.922 ms 2 10.61.209.67 10.667 ms 10.61.209.66 16.563 ms 10.61.209.67 17.305 ms 3 96.216.9.141 16.927 ms 96.216.9.137 16.745 ms 16.855 ms 4 * 68.85.154.113 17.025 ms 17.141 ms 5 96.108.99.245 20.670 ms 96.108.99.249 51.907 ms 96.108.99.245 31.021 ms 6 68.86.143.89 19.265 ms 18.382 ms 68.86.143.93 16.142 ms 7 162.151.87.226 18.098 ms 162.151.86.58 12.378 ms 12.306 ms 8 162.151.78.186 11.393 ms 11.518 ms 16.363 ms 9 68.85.191.206 16.545 ms 16.623 ms 17.228 ms 10 73.189.65.18 32.347 ms 24.524 ms 30.043 ms 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * # Bloody damn hell ... looks like most likely it's a Comcast Business issue on my end. I've got nothin' firewalling that, and should work fine.
On Sun, Jun 2, 2024 at 3:18 PM Rick Moen rick@linuxmafia.com wrote:
Trying to figure out something in logfiles. Filtering down this report just to sf-lug.com, balug.org, and savingthedolph.in DNS stuff, as "retry limit exceeded" seems to be a recurring theme and I'd like to figure out why (and fix).
----- Forwarded message from logcheck system account logcheck@linuxmafia.com -----
Date: Sun, 02 Jun 2024 15:02:01 -0700 From: logcheck system account logcheck@linuxmafia.com To: root@linuxmafia.com Subject: linuxmafia.com 2024-06-02 15:02 System Events
System Events
Jun 2 14:22:31 linuxmafia named[1093]: client 96.86.170.229#35399: received notify for zone 'balug.org' Jun 2 14:24:01 linuxmafia named[1093]: zone balug.org/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0) Jun 2 14:24:01 linuxmafia named[1093]: zone balug.org/IN: Transfer started. Jun 2 14:24:01 linuxmafia named[1093]: transfer of 'balug.org/IN' from 96.86.170.229#5353: connected using 96.95.217.99#36846 Jun 2 14:24:01 linuxmafia named[1093]: zone balug.org/IN: transferred serial 1717363350 Jun 2 14:24:01 linuxmafia named[1093]: transfer of 'balug.org/IN' from 96.86.170.229#5353: Transfer completed: 1 messages, 8 records, 871 bytes, 0.080 secs (10887 bytes/sec) Jun 2 14:28:07 linuxmafia named[1093]: zone sf-lug.org/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0) Jun 2 14:28:07 linuxmafia named[1093]: zone sf-lug.org/IN: Transfer started. Jun 2 14:28:07 linuxmafia named[1093]: transfer of 'sf-lug.org/IN' from 96.86.170.229#5353: connected using 96.95.217.99#40709 Jun 2 14:28:07 linuxmafia named[1093]: transfer of 'sf-lug.org/IN' from 96.86.170.229#5353: Transfer completed: 0 messages, 1 records, 0 bytes, 0.058 secs (0 bytes/sec) Jun 2 14:52:03 linuxmafia named[1093]: zone savingthedolph.in/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0) Jun 2 14:52:03 linuxmafia named[1093]: zone savingthedolph.in/IN: Transfer started. Jun 2 14:52:03 linuxmafia named[1093]: transfer of 'savingthedolph.in/IN' from 96.86.170.229#5353: connected using 96.95.217.99#35512 Jun 2 14:52:03 linuxmafia named[1093]: transfer of 'savingthedolph.in/IN' from 96.86.170.229#5353: Transfer completed: 0 messages, 1 records, 0 bytes, 0.052 secs (0 bytes/sec) Jun 2 14:58:05 linuxmafia named[1093]: zone sflug.com/IN: refresh: retry limit for master 96.86.170.229#5353 exceeded (source 0.0.0.0#0) Jun 2 14:58:05 linuxmafia named[1093]: zone sflug.com/IN: Transfer started. Jun 2 14:58:05 linuxmafia named[1093]: transfer of 'sflug.com/IN' from 96.86.170.229#5353: connected using 96.95.217.99#47957 Jun 2 14:58:05 linuxmafia named[1093]: transfer of 'sflug.com/IN' from 96.86.170.229#5353: Transfer completed: 0 messages, 1 records, 0 bytes, 0.052 secs (0 bytes/sec)
----- End forwarded message -----
At tne command line (on my nameserver):
$ dig @96.86.170.229 sf-lug.com axfr | wc -l 36 $ dig @96.86.170.229 balug.org | wc -l 18 $ dig @96.86.170.229 savingthedolph.in | wc -l 19 $
I'm going to be lazy (and need to go out for an errand), so will just say, WTF?
Rick,
I've opened case with Comcast Business, Ticket #: CR145359298 I tried their on-line chat, that basically walked me through some basic checks, then to a not available at this time, call, or ... so, called ... got someone nice enough ... not incompetent but no expert, and yeah, "of course" quite limited in what they could do ... did eventually get it escalated to create the ticket ... as about the only option 1st tier had left would be to dispatch hardware tech ... which would probably be total waste of everyone's time, as was working perfectly fine before, no changes in hardware, and works fine on UDP port 53, but not 5353 (and works on TCP). Also, did dig a little further ... traceroute ... packets actually are in fact making it to the server ... but not back to client, so, ... not really sure where the issue would be - could be anywhere between "my" Comcast "router", and "yours". At first I was thinking most likely at/around my end based upon the tracroute data, but checking server and seeing it gets packets and responds ... could be getting lost/blocked anywhere between - and without ability to capture along hops along the way on network, dear knows where. I'd guess most likely at/near one of the two ends, but who knows, some security/firewall (dis)services push that filtering further away from the endpoints, even if they're (generally) driven by customers (whether that's penultimate ISP end-user customer) or smaller to fair sized businesses or ISPs pushing the filtering further away from the endpoints to aid in more efficient filtering (less undesired traffic - when it's not desired, better handling of DDoS, etc.).
So, e.g., on server I see: 07:14:36.728454 IP 96.95.217.98.55659 > 96.86.170.229.5353: 16449 op8 [b2&3=0x4243] [17991a] [17477q] [18505n] [19019au][|domain] 07:14:36.728465 IP 96.95.217.98.57523 > 96.86.170.229.5353: 16449 op8 [b2&3=0x4243] [17991a] [17477q] [18505n] [19019au][|domain] 07:14:36.729032 IP 96.86.170.229.5353 > 96.95.217.98.48836: 16449 op8 FormErr- [0q] 0/0/0 (12) 07:14:36.729165 IP 96.86.170.229.5353 > 96.95.217.98.55659: 16449 op8 FormErr- [0q] 0/0/0 (12) 07:14:36.729272 IP 96.86.170.229.5353 > 96.95.217.98.57523: 16449 op8 FormErr- [0q] 0/0/0 (12)
Curious if Al and/or others have same issue with 96.86.170.229.5353 UDP (which would make it more probable issue is on/towards my end), or if it might be more specific to the linuxmafia.com / guido side of things - in which it might be closer to that (Comcast Business) end of things.
On Sun, Jun 2, 2024 at 10:34 PM Michael Paoli via BALUG-Admin balug-admin@lists.balug.org wrote:
+Al Uh oh ... the TLDR: looks like most likely it's a Comcast Business issue on my end. Anyway, I'll see if this apparently relatively new disservice that they've enabled that I never requested nor wanted, is anything I've got relatively simple access to disable that crud. And if that's not the case, looks like it'll be time for me to open a support ticket with 'em.
And from guido:
# traceroute -nUp 53 -m 15 96.86.170.229 traceroute to 96.86.170.229 (96.86.170.229), 15 hops max, 60 byte packets 1 96.95.217.102 1.567 ms 1.714 ms 2.000 ms 2 10.61.209.67 10.034 ms 17.091 ms 17.308 ms 3 96.216.9.141 15.642 ms 16.185 ms 16.438 ms 4 68.85.154.113 15.559 ms 15.263 ms 68.85.154.117 17.271 ms 5 96.108.99.245 21.485 ms 96.108.99.249 23.446 ms 23.462 ms 6 68.86.143.89 21.394 ms 20.951 ms 68.86.143.93 20.611 ms 7 162.151.87.226 21.823 ms 162.151.86.58 18.559 ms 162.151.87.226 13.063 ms 8 162.151.78.186 17.808 ms 17.503 ms 162.151.79.134 19.191 ms 9 68.85.191.206 19.451 ms 68.85.103.154 19.450 ms 68.85.191.206 18.210 ms 10 73.189.65.18 25.648 ms 30.850 ms 30.607 ms 11 96.86.170.229 38.275 ms 38.315 ms 36.705 ms # traceroute -nUp 5353 -m 15 96.86.170.229 traceroute to 96.86.170.229 (96.86.170.229), 15 hops max, 60 byte packets 1 96.95.217.102 1.510 ms 1.671 ms 1.922 ms 2 10.61.209.67 10.667 ms 10.61.209.66 16.563 ms 10.61.209.67 17.305 ms 3 96.216.9.141 16.927 ms 96.216.9.137 16.745 ms 16.855 ms 4 * 68.85.154.113 17.025 ms 17.141 ms 5 96.108.99.245 20.670 ms 96.108.99.249 51.907 ms 96.108.99.245 31.021 ms 6 68.86.143.89 19.265 ms 18.382 ms 68.86.143.93 16.142 ms 7 162.151.87.226 18.098 ms 162.151.86.58 12.378 ms 12.306 ms 8 162.151.78.186 11.393 ms 11.518 ms 16.363 ms 9 68.85.191.206 16.545 ms 16.623 ms 17.228 ms 10 73.189.65.18 32.347 ms 24.524 ms 30.043 ms 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * # Bloody damn hell ... looks like most likely it's a Comcast Business issue on my end. I've got nothin' firewalling that, and should work fine.
Rick,
I found non-Comcast Business client I could test from and ...: $ curl -s https://ipv4.balug.org/myip && dig -p 5353 +nomultiline @96.86.170.229 +noall +answer sflug.com. SOA 54.149.53.111 sflug.com. 172800 IN SOA ns1.sf-lug.org. jim.well.com. 1716775812 10800 3600 3600000 86400 $ sudo traceroute -f 13 -nUp 5353 96.86.170.229 traceroute to 96.86.170.229 (96.86.170.229), 30 hops max, 60 byte packets 13 96.110.41.78 22.205 ms 68.85.191.206 23.194 ms 96.110.41.74 21.052 ms 14 162.151.86.58 23.357 ms 162.151.78.186 22.058 ms 162.151.86.58 22.490 ms 15 162.151.78.186 22.559 ms 96.86.170.229 35.853 ms 40.269 ms $
Works fine from there. So, alas, looks like issue on/towards your Comcast Business side/end of things. So ... feel free to follow-up with Comcast Business at your convenience. Might also want to have them cross-reference: Ticket #: CR145359298 If that's useful. They don't seem to (thus far) give me a way to update that on-line, but when they call, I'll let 'em know to call off the dogs on this side of it - and looks like issue on/towards your Comcast Business side of things.
On Mon, Jun 3, 2024 at 12:20 AM Michael Paoli michael.paoli@berkeley.edu wrote:
Rick,
I've opened case with Comcast Business, Ticket #: CR145359298 I tried their on-line chat, that basically walked me through some basic checks, then to a not available at this time, call, or ... so, called ... got someone nice enough ... not incompetent but no expert, and yeah, "of course" quite limited in what they could do ... did eventually get it escalated to create the ticket ... as about the only option 1st tier had left would be to dispatch hardware tech ... which would probably be total waste of everyone's time, as was working perfectly fine before, no changes in hardware, and works fine on UDP port 53, but not 5353 (and works on TCP). Also, did dig a little further ... traceroute ... packets actually are in fact making it to the server ... but not back to client, so, ... not really sure where the issue would be - could be anywhere between "my" Comcast "router", and "yours". At first I was thinking most likely at/around my end based upon the tracroute data, but checking server and seeing it gets packets and responds ... could be getting lost/blocked anywhere between - and without ability to capture along hops along the way on network, dear knows where. I'd guess most likely at/near one of the two ends, but who knows, some security/firewall (dis)services push that filtering further away from the endpoints, even if they're (generally) driven by customers (whether that's penultimate ISP end-user customer) or smaller to fair sized businesses or ISPs pushing the filtering further away from the endpoints to aid in more efficient filtering (less undesired traffic - when it's not desired, better handling of DDoS, etc.).
So, e.g., on server I see: 07:14:36.728454 IP 96.95.217.98.55659 > 96.86.170.229.5353: 16449 op8 [b2&3=0x4243] [17991a] [17477q] [18505n] [19019au][|domain] 07:14:36.728465 IP 96.95.217.98.57523 > 96.86.170.229.5353: 16449 op8 [b2&3=0x4243] [17991a] [17477q] [18505n] [19019au][|domain] 07:14:36.729032 IP 96.86.170.229.5353 > 96.95.217.98.48836: 16449 op8 FormErr- [0q] 0/0/0 (12) 07:14:36.729165 IP 96.86.170.229.5353 > 96.95.217.98.55659: 16449 op8 FormErr- [0q] 0/0/0 (12) 07:14:36.729272 IP 96.86.170.229.5353 > 96.95.217.98.57523: 16449 op8 FormErr- [0q] 0/0/0 (12)
Curious if Al and/or others have same issue with 96.86.170.229.5353 UDP (which would make it more probable issue is on/towards my end), or if it might be more specific to the linuxmafia.com / guido side of things - in which it might be closer to that (Comcast Business) end of things.
On Sun, Jun 2, 2024 at 10:34 PM Michael Paoli via BALUG-Admin balug-admin@lists.balug.org wrote:
+Al Uh oh ... the TLDR: looks like most likely it's a Comcast Business issue on my end. Anyway, I'll see if this apparently relatively new disservice that they've enabled that I never requested nor wanted, is anything I've got relatively simple access to disable that crud. And if that's not the case, looks like it'll be time for me to open a support ticket with 'em.
And from guido:
# traceroute -nUp 53 -m 15 96.86.170.229 traceroute to 96.86.170.229 (96.86.170.229), 15 hops max, 60 byte packets 1 96.95.217.102 1.567 ms 1.714 ms 2.000 ms 2 10.61.209.67 10.034 ms 17.091 ms 17.308 ms 3 96.216.9.141 15.642 ms 16.185 ms 16.438 ms 4 68.85.154.113 15.559 ms 15.263 ms 68.85.154.117 17.271 ms 5 96.108.99.245 21.485 ms 96.108.99.249 23.446 ms 23.462 ms 6 68.86.143.89 21.394 ms 20.951 ms 68.86.143.93 20.611 ms 7 162.151.87.226 21.823 ms 162.151.86.58 18.559 ms 162.151.87.226 13.063 ms 8 162.151.78.186 17.808 ms 17.503 ms 162.151.79.134 19.191 ms 9 68.85.191.206 19.451 ms 68.85.103.154 19.450 ms 68.85.191.206 18.210 ms 10 73.189.65.18 25.648 ms 30.850 ms 30.607 ms 11 96.86.170.229 38.275 ms 38.315 ms 36.705 ms # traceroute -nUp 5353 -m 15 96.86.170.229 traceroute to 96.86.170.229 (96.86.170.229), 15 hops max, 60 byte packets 1 96.95.217.102 1.510 ms 1.671 ms 1.922 ms 2 10.61.209.67 10.667 ms 10.61.209.66 16.563 ms 10.61.209.67 17.305 ms 3 96.216.9.141 16.927 ms 96.216.9.137 16.745 ms 16.855 ms 4 * 68.85.154.113 17.025 ms 17.141 ms 5 96.108.99.245 20.670 ms 96.108.99.249 51.907 ms 96.108.99.245 31.021 ms 6 68.86.143.89 19.265 ms 18.382 ms 68.86.143.93 16.142 ms 7 162.151.87.226 18.098 ms 162.151.86.58 12.378 ms 12.306 ms 8 162.151.78.186 11.393 ms 11.518 ms 16.363 ms 9 68.85.191.206 16.545 ms 16.623 ms 17.228 ms 10 73.189.65.18 32.347 ms 24.524 ms 30.043 ms 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * # Bloody damn hell ... looks like most likely it's a Comcast Business issue on my end. I've got nothin' firewalling that, and should work fine.