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, <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:
* 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@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
--
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
