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 [1]
> 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 [1]
> 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 [1]
> 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 [1]
> 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 [1]
> 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 [2]
> 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 [2]
> 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 [2]
> 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 [2]
> 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 [2]
> 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 [2]
> 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 [2]
> 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 [2]
> 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 [2]
> 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 [1]
> 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 [1]
> 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 [2]
> 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 [2]
> 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 [2]
> 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 [1]
> 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, <[email protected]> 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:
>>
>> * The IP ending in ".23" is my Windows 7 Main Desktop client
>> * The IP ending in ".17" is my Main Wireless Access Point (WAP) (wired
>> to a switch connected to the main "wired" router).
>> * The IP ending in ".74" is my Blink Camera system (including my
>> doorbell camera);
>> * The IP ending in ".80" is my Smartphone;
>> * The IP ending in ".224" is my PTZ Security Camera;
>> * The IP ending in ".52" is my Ubuntu client Main desktop;
>> * 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:
>>
>> * 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.
>> * 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?
>> * 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)...
>> * 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?
>> * 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
>> [email protected]
>> https://lists.isc.org/mailman/listinfo/bind-users
Links:
------
[1] http://sdk.iad-08.braze.com
[2] http://sdk.iad-08.braze.com.cdn.cloudflare.net
--
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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.