Sure. Your decision, of course. But any network application is only going
to work if the underlying network supporting it doesn't do silly things
with its traffic.
On Thu, 22 May 2025 at 15:23, <bi...@clearviz.biz> wrote:
> Thank you for all your assistance. I have made the decision to
> decommission Bind9 and install Unbound in its place. There seem to be a
> lot more configuration options that might help me with the problems I am
> having. Problems I never had with Windows Server 2003.
>
>
> Thanks anyway and take care of yourselves. I'm outta here.
>
> On 2025-05-19 16:46, Greg Choules wrote:
>
> Your router (or your ISP behind it) is losing a lot of traffic. Here is a
> timeline of frames with explanations of each, which would have been so much
> simpler if you hadn't tried to hide your actual addresses and just sent the
> pcap file instead.
>
> frame abs time time delta time Source dest port Q/R QNAME QTYPE QID notes
> 819 0 81.994938 184.184.184.80 184.184.184.10 28665 Q
> sdk.iad-08.braze.com A eaeb client to server
> 820 0.000501 81.995439 0.000501 184.184.184.10 1.1.1.1 48514 Q
> sdk.iad-08.braze.com A e184 server to Cloudflare
> 836 1.201959 83.196897 1.201458 184.184.184.10 8.8.8.8 60448 Q
> sdk.iad-08.braze.com A 41e0 server to Google
> 853 2.951146 84.946084 1.749187 184.184.184.80 184.184.184.10 28665 Q
> sdk.iad-08.braze.com A eaeb retry of 819
> 861 3.490542 85.48548 0.539396 184.184.184.10 1.1.1.1 60264 Q
> sdk.iad-08.braze.com A 8367 retry of 820
> 863 3.525652 85.52059 0.03511 1.1.1.1 184.184.184.10 60264 R
> sdk.iad-08.braze.com.cdn.cloudflare.net CNAME 8367 Response to 861 -
> Plus: A 104.18.37.58, A 172.64.150.198, RRSIG
> 864 3.526226 85.521164 0.000574 184.184.184.10 1.1.1.1 53574 Q
> sdk.iad-08.braze.com.cdn.cloudflare.net A 34b3 server to Cloudflare
> 877 4.727679 86.722617 1.201453 184.184.184.10 8.8.8.8 60387 Q
> sdk.iad-08.braze.com.cdn.cloudflare.net A e9d9 server to Google
> 896 7.025838 89.020776 2.298159 184.184.184.10 1.1.1.1 52402 Q
> sdk.iad-08.braze.com.cdn.cloudflare.net A 4bfc retry of 864
> 914 8.227313 90.222251 1.201475 184.184.184.10 8.8.8.8 35436 Q
> sdk.iad-08.braze.com.cdn.cloudflare.net A d447 retry of 877
> 936 10.529468 92.524406 5.801789 184.184.184.10 1.1.1.1 34148 Q
> sdk.iad-08.braze.com.cdn.cloudflare.net A fb01 retry of 864
> 980 11.730096 93.725034 1.200628 184.184.184.10 8.8.8.8 41704 Q
> sdk.iad-08.braze.com.cdn.cloudflare.net A 5631 retry of 877
> 981 11.7307 93.725638 0.000604 184.184.184.7 184.184.184.10 - - - ICMP -
> Destination
> unreachable (Port unreachable) but don't know which packet this is in
> response to.
> 982 11.731077 93.726015 0.000377 184.184.184.10 1.1.1.1 58228 Q
> sdk.iad-08.braze.com.cdn.cloudflare.net A 669e retry of 864 probably
> 990 13.332941 95.327879 1.601864 184.184.184.10 1.1.1.1 58016 Q
> sdk.iad-08.braze.com.cdn.cloudflare.net A eeab retry of 864 probably
> 991 13.333587 95.328525 0.000646 184.184.184.7 184.184.184.10 - - - ICMP -
> Destination
> unreachable (Port unreachable) but don't know which packet this is in
> response to.
> 992 13.334088 95.329026 0.001147 184.184.184.10 184.184.184.80 28665 R
> sdk.iad-08.braze.com A eaeb Server failure, response to 819
> 1032 18.420714 100.415652 5.086626 184.184.184.80 184.184.184.10 32337 Q
> sdk.iad-08.braze.com A 2e9e
> 1033 18.421187 100.416125 0.000473 184.184.184.10 1.1.1.1 49370 Q
> sdk.iad-08.braze.com.cdn.cloudflare.net A b069
> 1034 18.42184 100.416778 0.000653 184.184.184.7 184.184.184.10 - - - ICMP
> - Destination unreachable (Port unreachable) but don't know which packet
> this is in response to.
> 1035 18.42221 100.417148 0.00037 184.184.184.10 8.8.8.8 43783 Q
> sdk.iad-08.braze.com.cdn.cloudflare.net A 5b57
> 1053 20.772813 102.767751 2.350603 184.184.184.10 8.8.8.8 48067 Q
> sdk.iad-08.braze.com.cdn.cloudflare.net A ae45
> 1054 20.773441 102.768379 0.000628 184.184.184.7 184.184.184.10 - - - ICMP
> - Destination unreachable (Port unreachable) but don't know which packet
> this is in response to.
> 1055 20.773879 102.768817 0.000438 184.184.184.10 184.184.184.80 32337 R
> sdk.iad-08.braze.com A 2e9e Response to 1032
>
> Note that the BIND server at ...10 makes lots of outbound queries to both
> Cloudflare and Google that receive no responses, so it has to keep
> retrying. One successful response is received: frame 863, but other than
> that, either nothing or ICMP messages from the router (...7) to the server,
> telling it that it could not forward packets to the destination.
> Unfortunately you have cropped the ICMP frames, so we can't see which exact
> packets they refer to. But I think you get the general picture. Your
> network needs looking at, badly and this is not a BIND problem.
>
> I hope that helps you to know where to look next.
> Cheers, Greg
>
>
> On Sun, 18 May 2025 at 18:54, <bi...@clearviz.biz> wrote:
>
> Good Afternoon all.
>
> I am back with some data from tcpdump on my server machine fed through to
> Wireshark. See the attached three text files. The first is an entire
> tcpdump captured for roughly 30 minutes while I did my best to access sites
> on my smartphone that require DNS (and many do). Once again the actual
> subnet numbers havr been changed to a "place holder" (184.184.184.*) for
> security purposes. There are two other files. The first is a subset of
> that main file that deals only with packets where the last octet of my
> subnet is ".80" which is the IP assigned to my smartphone. The second is
> a similar file where the last octet is ".7" which is the default gateway
> (my physical router). I include it because all of the packets seem to have
> the same problem (the router attempts a ping to my main server (ending in
> octet ".10"), which it claims the host is unreachable. Not sure why that
> is happening. I do know that I won't be able to update the router anymore
> because it reached EOL in 2017 and if I try to access it by it's IP, all
> the browsers won't contact it because they say the "protocol is too old."
> Even removing SSL protections doesn't stop it. Ah well. When viewing the
> full file ("ALL"), the following are some meaningful "last octets" to
> consider:
>
>
>
> 1. The IP ending in ".23" is my Windows 7 Main Desktop client
> 2. The IP ending in ".17" is my Main Wireless Access Point (WAP)
> (wired to a switch connected to the main "wired" router).
> 3. The IP ending in ".74" is my Blink Camera system (including my
> doorbell camera);
> 4. The IP ending in ".80" is my Smartphone;
> 5. The IP ending in ".224" is my PTZ Security Camera;
> 6. The IP ending in ".52" is my Ubuntu client Main desktop;
> 7. The IP ending in ".249" is a Wifi Extender that feeds off the main
> WAP.
>
>
> The others are for things that are wired to the system like my NAS Drives,
> etc.
>
> If we look at the file just for octet .80 (my smartphone), we see that
> they were all queries and responses to those queries. Some were successful,
> but many were not. The two primary reasons for those queries that failed
> were either "SERVFAIL" and/or "query timeout." During the time period in
> which I captured this tcpdump file, I deliberately attempted to use the
> "Walmart" app, the "Amazon" app, and check the Blink Doorbell camera app on
> my phone. Whatever failures you see occurred as a result of my attempt to
> use those apps on my phone (for which the phone app responded with a "No
> Internet access" error).
>
>
> Questions:
>
> 1. What could be causing the port on the router (X.X.X.7) to be
> "unreachable?" If it is "closed," I'd imaigne it would be closed for
> everything, not just select packets.
> 2. Are there tweaks in BIND9 I can make to, for example, extend the
> time allowed to make the queries (i.e. to avoid timeout errors)? Or is that
> time limit set elsewhere?
> 3. Likewise, are there Bind9 tweaks I can do to extend the TTL for
> successful query responses to keep them just a little longer (not much... I
> Know)...
> 4. Are the problems we see inherent to BIND9 v.18? Could an upgrade
> to BIND9 v.20 help at all? And, do I need to upgrade Ubuntu to 24.x to get
> that done?
> 5. Are there buffer settings I can make in Bind9 to allow more to be
> processed at once in bulk? If, for example, I do a "dig" on an individual
> domain name right after i notice it failing (doing it on the Server itself
> in Cmd mode), it can access the site perfectly via dig. It just seems as
> though it fails when the server does an actual DNS query.
>
>
> I may consider rebuilding the DNS portion of the server with either
> BIND9.20 or "Unbound" if that doesn't work, just to see if the behavior
> changes.
>
>
> Thanks all!
>
>
>
>
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
