3Rd Follow Up - Re: My Introduction and current issues
bind9 at clearviz.biz
bind9 at clearviz.biz
Thu May 22 14:23:55 UTC 2025
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, <bind9 at 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:
>>
>> * 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
>> bind-users at lists.isc.org
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250522/c55b9a84/attachment-0001.htm>
More information about the bind-users
mailing list