>From the correct alias this time!
On Mon, 19 May 2025 at 22:46, Greg Choules <gregchou...@googlemail.com>
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
