Frequent DNS timeouts
-
@jonh I think the context of Gertjan's message was to help that poster to assign static IPs, in order to avoid DHCP registrations, which does restart Unbound.
There are many threads, as you said. In another thread someone suggested/speculated Quad9 was rate limiting or just not answering if there were a lot of DoT requests. At home I have had DoT with Quad9 on 23.01 enabled for a few weeks now, but volume is not high. I haven't tried DoT on, at other places, but we've had no reports of DNS issues with it off. I did have to turn off DNSSEC on 23.01, which Quad9 themselves say will cause problems when forwarding. Others have posted disabling DNSSEC didn't help but disabling DoT did.
-
@steveits said in Frequent DNS timeouts:
At home I have had DoT with Quad9 on 23.01 enabled for a few weeks now, but volume is not high.
That's interesting. My DoT subnet has only 3 states set with 12MiB with an uptime of < 2 days.
I'm not sure that is a good indicator but it does seem maybe it is high. But again, this was not happening prior to my upgrade. As for Quad9 rate limiting, if that is the reason the it implies the other 3 DNS/TLS servers I tried also may be rate limiting. I have not seen that in my logs when I was looking for a common cause for this problem.I want to be able to access my DoT via Apple's Homekit while away from home.
Here is a snippet from resolver.log for a typical 'hang'
Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.143 p39-imap.mail.me.com.akadns.net. AAAA IN SERVFAIL 0.000000 0 49 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: resolving p39-imap.mail.me.com.akadns.net. A IN Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.143 p39-imap.mail.me.com.akadns.net. A IN SERVFAIL 0.000000 0 49 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: resolving jimap.imap.mail.yahoo.com. AAAA IN Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.143 jimap.imap.mail.yahoo.com. AAAA IN SERVFAIL 0.000000 0 43 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: resolving jimap.imap.mail.yahoo.com. A IN Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.143 jimap.imap.mail.yahoo.com. A IN SERVFAIL 0.000000 0 43 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: resolving www.chevybolt.org. HTTPS IN Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.7 www.chevybolt.org. HTTPS IN SERVFAIL 0.000000 0 35 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: resolving www.chevybolt.org. A IN Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.7 www.chevybolt.org. A IN SERVFAIL 0.000000 0 35 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: resolving config.htplayground.com. HTTPS IN Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.7 config.htplayground.com. HTTPS IN SERVFAIL 0.000000 0 41 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: resolving config.htplayground.com. A IN Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.7 config.htplayground.com. A IN SERVFAIL 0.000000 0 41 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.143 p39-imap.mail.me.com.akadns.net. AAAA IN SERVFAIL 0.000000 1 49 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.143 jimap.imap.mail.yahoo.com. AAAA IN SERVFAIL 0.000000 1 43 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.143 p39-imap.mail.me.com.akadns.net. A IN SERVFAIL 0.000000 1 49 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.143 jimap.imap.mail.yahoo.com. A IN SERVFAIL 0.000000 1 43 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.7 www.chevybolt.org. HTTPS IN SERVFAIL 0.000000 1 35 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.7 www.chevybolt.org. A IN SERVFAIL 0.000000 1 35 Mar 17 11:06:59 pfSense unbound[77573]: [77573:1] info: 192.168.10.7 config.htplayground.com. HTTPS IN SERVFAIL 0.000000 1 41
This particular hang lasted 2.5 minutes before I manually restarted unbound.
Here is the final sequence during a restart of unbound:
Mar 17 11:07:21 pfSense unbound[77573]: [77573:0] info: [pfBlockerNG]: pfb_unbound.py script exiting Mar 17 11:08:12 pfSense unbound[35852]: [35852:0] notice: init module 0: python Mar 17 11:08:12 pfSense unbound[35852]: [35852:0] info: [pfBlockerNG]: pfb_unbound.py script loaded Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: [pfBlockerNG]: init_standard script loaded Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] notice: init module 1: iterator Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: start of service (unbound 1.17.1). Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: resolving ocsp2.apple.com. HTTPS IN Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: resolving ocsp2.apple.com. A IN Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: resolving amp-api-edge.apps.apple.com. HTTPS IN Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: resolving ocsp2.apple.com. AAAA IN Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: resolving amp-api-edge.apps.apple.com. AAAA IN Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: resolving amp-api-edge.apps.apple.com. A IN Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: response for amp-api-edge.apps.apple.com. A IN Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: reply from <.> 149.112.112.112#853 Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: query response was CNAME Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: resolving amp-api-edge.apps.apple.com. A IN Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: response for ocsp2.apple.com. AAAA IN Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: reply from <.> 9.9.9.9#853 Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: query response was CNAME Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: resolving ocsp2.apple.com. AAAA IN Mar 17 11:08:14 pfSense unbound[35852]: [35852:0] info: response for ocsp2.apple.com. HTTPS IN
And after the restart I'm back up and running.
-
@jonh said in Frequent DNS timeouts:
As for Quad9 rate limiting, if that is the reason the it implies the other 3 DNS/TLS servers I tried also may be rate limiting
It occurs to me that if (if) it is rate limiting on the remote end, restarting Unbound probably wouldn't fix it. However if connections are being held open for some reason (e.g. rate limiting? bug?) and Unbound stops connecting out, or gets connection refusals, that could explain both the "self recover" and "restart to recover" behavior...?
-
@steveits said in Frequent DNS timeouts:
It occurs to me that if (if) it is rate limiting on the remote end, restarting Unbound probably wouldn't fix it.
That's a good point.
I forgot to mention that I am using an SG5100, it should be robust enough for my little home use.
I also realize there are many folks here with different skill levels, and I probably am at the lower end of that range. There is always the possibility that I have a mis-configuration problem although it is essentially the same as it has been through many releases of pfSense. The major change seems to be (IMO) the implementation of Python.
I'll look through some of my older log captures and see if I can find a log that shows the beginning of these 'hangs' I and others have experienced. Maybe the guru's here will see something obvious.
In the meantime I'll just keep running that cron job and restarting unbound ev. 30 min.
-
@jonh
I have two different firewalls based on different hardware, not the Netgate. I have been running into this problem several times, I don't what was the reason exactly, because it stopped doing it after some time and maybe some settings change. I have pfblockerNG-devel 3.2.0_3 and 23.01 with current patches added vi system patches package, also DNS block enabled in pfBlocker and I use forwarding to google and cloudflare TLS
Here are my settings for resolver:
-
@w0w said in Frequent DNS timeouts:
I have pfblockerNG-devel 3.2.0_3 and 23.01 with current patches added vi system patches package, also DNS block enabled in pfBlocker and I use forwarding to google and cloudflare TLS
Thank you for this info.
Previously I used pfB-devel but when 23.01 was released it was stated that since it matched devel I should go to the non-devel package, which I did. I tried to check the current version of -devel but oddly enough, at time of this writing, there are ZERO packages on 'available' packages. Installed package list populates correctly. I'll check on this later.
There are a few differences on my dns settings, about 1/2 of the settings you posted for the 'advanced settings' are different from mine, mine are all set to the defaults and I'm not changed them except for the 'log level', which I set up to 3 last night trying to find something, anything, to give a clue on this issue. I will research your settings for more detail. I have a smaller msg cache and tcp buffers and maybe I can benefit from bumping those up.
On the DNS 'GeneralSettings' page, you have 'outgoing' interfaces set to WAN, I have it set to 'all', which is the default.
Under custom options you have the path to pfblockerNG 'dnsbl config' which was once required in an earlier version but I believe that requirement was removed for python mode. I'll look into that again, it is a possible I'm wrong. I do have "server: log-replies: yes" which is a recommendation for quad9.
Again, thanks so much for posting your setup.
-
-
Okay this has been driving me nuts. For years I have never noticed DNS issues but ever since upgrading to 23.01 I am constantly getting DNS timeouts because unbound is restarting. Looking at my logs unbound is restarting ~ every 5 minutes. It does appear to happen right after DHCP for clients with Hostnames. But why all of a sudden is this a noticeable issue. In previously releases I saw the same restart cadence but have never experienced DNS timeouts. Is the only solution to really disable DNS registration??
-
@nedyah700 said in Frequent DNS timeouts:
disable DNS registration??
Is that really such a bad thing? What dhcp clients are you resolving via name - how many clients?
Here is the thing, if unbound is restarting - even if you don't notice and issue with resolving.. it clears its cache ever time it restarts.
I simple work around to the problem is just to setup reservations - so you devices always get the same IP.. Unless you have hundreds of clients.. Or you have lots of clients that come and go onto your network without any clue to what they are - then why would you want/need to resolve them?
Sure in a perfect world, unbound wouldn't restart and it could register your dhcp clients - maybe someday that will be an option. But its a been a known issue and long time standing thing that dhcp registrations restarts unbound. Many users may never notice - they have a handful of clients, they have a long time lease - unbound only restarts a now and then during a day..
But if your dns is restarting every 5 minutes - that is going to be problematic for sure. Be it you wanting to query something during the restart, or just that its loosing all of its cache every 5 minutes is not very efficient..
While it might seem daunting to setup reservations - its a one time thing, do a few at a time when you have a chance, etc. All of the like 40+ some devices on my network have reservations.. the only thing I don't have reservations for is like guest devices - which I could care less about resolving their names..
-
@johnpoz
I just don't understand why with 0 configuration changes this upgrade made the impact so much more sever. Multiple times a day I am getting DNS resolution timeouts lasting one to two minutes. Prior to upgrading the restarts had no notable impact. -
@nedyah700 unbound has restarted with dhcp reservations since for ever.. Can tell you that for sure..
Timeout lasting a few minutes shouldn't happen unless your getting a flood of renews like all in a row or something.. Maybe before your registrations were more spread out and didn't come in groups.
-
@johnpoz Agree, and I've seen it in my logs like this since day 1 with pfSense. But all of a sudden now it's actually causing experienced issues with users. Clearly I am not alone judging by all the various posts here on the forums.
-
@nedyah700 I've had the same problems except my unbound service was not restarting, it was hanging and if I did nothing it would eventually get going again. I was manually restarting it rather than waiting it out. Now I rarely have that 2 min delay and have not observed it hanging. I set the logging up to level 3 and noticed a lot of "debug: outnettcp got tcp error -1" errors when it was hung.
I am using pfBlockerNG and under DNSBL I have DNS set to "unbound python mode". I have my dhcp set to a limited pool range and have some clients with static IP's outside the pool range.
The changes I made, and I don't know which one or combo that helped me but here are some things I changed:
1). In System->General setup I changed the default "use local, fall back to remote DNS" to "Use local, ignore remote"
2). In DNS Resolver I previously had all interfaces selected under "outgoing network interfaces". I changed that to select WAN only.
3). Under Resolver -> Advanced I changed the 'outgoing' and the 'incoming' TCP Buffers from the default 10 to 20. When I changed this I was still experiencing the problem but now I have not observed the problem. I have not idea if changing this setting is applicable to the problem, I only know that after changing this and rebooting pfSense, my switch, and my AP everything is better.
-
@jonh said in Frequent DNS timeouts:
pfBlockerNG
Thanks! I'll give some of these a try. I am using pfBlockerNG but not DNSBL.
-
@nedyah700 are you forwarding or doing a normal resolve, which is default. If your forwarding are you forwarding over tcp? ie dot?
"use local, fall back to remote DNS" to "Use local, ignore remote"
This setting has zero to do with anything - this is what pfsense would do when it needed to resolve something. Ie look to see if there was an update, checking for packages, etc. Or you click to resolve an IP in your firewall log, etc.
That settings has nothing to do with clients asking unbound, or unbound resolving or forwarding.
I have it set to ignore - because I don't have any remote dns, I only resolve.. I could of just left it at default, but was like why - there is no remote dns set, and even if there was I sure wouldn't want pfsense using them ;)
If I recall correctly that setting came to be when they added dot and such, and you were adding the forwarders into the general settings.. You were not sure before if pfsense would ask unbound, which would use dot to talk to forwarders you had set. Or if pfsense used them it would just ask them via normal dns.. This setting allows you to ignore the forwarders you might have setup for dot use, because while unbound will use dot to talk to them. Pfsense would only just query them over normal 53..
This has nothing to do with unbound restarting, or clients on your network asking unbound for dns.. This is what pfsense will do for its own dns needs.
-
For me those Unbound restarts do still exist.
I do not have any forwarded DNS. Only using direct Unbound with the system.
DHCP registration is turned off.
Only pfblockerNG in python mode.
And my DNS Resolver log is full of entries.... Don't really know what is causing this issues?!
-
@thundergate yeah unbound would be pretty much useless if its restarting that often.. Something is wrong - can you up the verbose level so you might be able to see more info.. Or it looks like you filtered that output, what else is the log?
You sure you have dhcp registrations off? That sure looks like what I had posted in this or some other dns related thread where my wifes phone was constantly asking for dhcp, mine doesn't restart unbound because dhcp registrations are off..
Do you have dhcp stuff in its log that might match up - maybe the setting didn't take and for some reason its still restarting on dhcp
-
@johnpoz said in Frequent DNS timeouts:
You sure you have dhcp registrations off? That sure looks like what I had posted in this or some other dns related thread where my wifes phone was constantly asking for dhcp, mine doesn't restart unbound because dhcp registrations are off..
Thx. Yes. See screenshot. Even disabling static DHCP doesn't help.
Also disabled python mode - and still all the unbound restarts.
Activated Level 2 Logging and will have a look into it.
-
@johnpoz said in Frequent DNS timeouts:
Do you have dhcp stuff in its log that might match up
Within DHCP I do have a lot of those messages (see screenshot):
-
@thundergate do those times match up? I see you have register dhcp off in your settings.. But maybe it didn't take?
Something is clearly restarting unbound, and a lot.. And the only thing comes to mind that would restart it that often would be dhcp registrations.
I would guess for whatever reason your setting of not to register dhcp is not actually working.. For whatever reason.
Quick test of that might be to just turn off all your dhcp services on pfsense.. Do your restarts stop? You don't need dhcp running 24/7 it can be off for a while. if you you have all your dhcp services off on pfsense, and your still seeing unbound restart like crazy like that - then you know its not dhcp registrations doing it. With the amount of restarts your seeing - I would think you should be able to tell in 10 minutes or so if that is the problem..
-
@thundergate said in Frequent DNS timeouts:
And my DNS Resolver log is full of entries.... Don't really know what is causing this issues?!
Do you use Service Watchdog? Is it possible that these restarts could be from the Watchdog restarting it? I removed unbound from my Watchdog monitoring because it was restarting it too often. It was a month ago and I've forgotten if my problems created a log like you posted.
Also note that my Resolver was not stopping, it was hanging and would simply 'fix itself' after 3-6 minutes or so. In my case not using Watchdog has been useful for me.
-
@thundergate said in Frequent DNS timeouts:
Within DHCP I do have a lot of those messages (see screenshot):
The other day i had similar entries in DHCP log for one IP. These started after I had removed power from one of my IoT devices that I was also blocking with a firewall rule.
This particular device is a bed that also monitors sleep patterns. I have rules that block it's access to 'the motherland'. It also uses an iPhone app so there is also this extra chatter. The app is unused so I deleted it. I also found entries in the States table for that IP and deleted the State for the specific IP. I also deleted the arp entry and rebooted pfSense and my wifi AP at the same time prior to repowering the device that was causing this issue.
That problem has now stopped.
-
Sorry for my late feedback.
But after disabling and re-enabling some settings the issues are gone.
Don't know why - but at the moment no unbound restarts.
-
Be aware that pfBlocker-NG cron/update also restarts Unbound, when (for instance) DNSBL lists are updated.
-
Oh no... The stop/start of unbound started again.
What I could figure out is, that is has somehow be related to my Mac going into standby/hybernate mode. Than those unbound stop/start begins.
As it's a testing setup and my Mac is the only network device within the pfSense setup I can say, that it has to be something related to the Mac and pfSense / pfBlockerNG?!
-
@thundergate said in Frequent DNS timeouts:
Mac going into standby/hybernate mode.
Or is asking for dhcp all the time like my wife's iphone.. Would seem more like it - what would your mac going into standby have to do with pfblocker ???
See above where I posted my wife phone doing this
Mar 16 01:38:52 dhcpd 93450 DHCPACK on 192.168.2.203 to 88:b2:91:98:d6:f0 via igb2 Mar 16 01:38:52 dhcpd 93450 DHCPREQUEST for 192.168.2.203 from 88:b2:91:98:d6:f0 via igb2 Mar 16 01:37:41 dhcpd 93450 DHCPACK on 192.168.2.203 to 88:b2:91:98:d6:f0 via igb2 Mar 16 01:37:41 dhcpd 93450 DHCPREQUEST for 192.168.2.203 from 88:b2:91:98:d6:f0 via igb2 Mar 16 01:31:44 dhcpd 93450 DHCPACK on 192.168.2.203 to 88:b2:91:98:d6:f0 via igb2 Mar 16 01:31:44 dhcpd 93450 DHCPREQUEST for 192.168.2.203 from 88:b2:91:98:d6:f0 via igb2 Mar 16 01:30:01 dhcpd 93450 DHCPACK on 192.168.2.203 to 88:b2:91:98:d6:f0 via igb2 Mar 16 01:30:01 dhcpd 93450 DHCPREQUEST for 192.168.2.203 from 88:b2:91:98:d6:f0 via igb2 Mar 16 01:29:20 dhcpd 93450 DHCPACK on 192.168.2.203 to 88:b2:91:98:d6:f0 via igb2 Mar 16 01:29:20 dhcpd 93450 DHCPREQUEST for 192.168.2.203 from 88:b2:91:98:d6:f0 via igb2
If your unbound is restarting on dhcp then yeah that is going to be horrible.. That was when my wifes phone is on the charger, it shouldn't of been doing shit, let also be asking for dhcp..
-
@thundergate said in Frequent DNS timeouts:
related to my Mac going into standby/hybernate mode. Than those unbound stop/start begins
MAC directly connected by wire on the LAN port ?
In that case, when mac goes down, LAN port goes down == NIC event == unbound restarts.
Solution : use a switch.
Or is this not your case ? -
@gertjan said in Frequent DNS timeouts:
MAC directly connected by wire on the LAN port ?
That would be odd, but yeah that could do it ass well ;)
-
@gertjan said in Frequent DNS timeouts:
MAC directly connected by wire on the LAN port ?
Oh noooo. That's it. Thanks for the hint. I was looking into logs forever, but forget about that simple one.
-
Now you know it, look again at the main system log using the console access while your MAC system is shut down == LAN shut down also.
Switch on the MAC.
You'll see a NIC (LAN) uplink event in the system log (check also the hardware or dmesg log).
That triggers a whole lot activity on the system. Every system process using (listing) to the LAN interface will get restarted = DHCP server, NTP, the WebGUI to name a few, and also unbound. -
So far the only thing that has worked for me regarding the DNS hanging is to not use DNS over TLS to quad9 or Cloudflare or whatever upstream servers you have set. I did not see anyone else mention that so far (though it's likely I missed it). After going back to plain old DNS on port 53, all pages load much faster and I don't have missing icons and images. No more timeouts seen on the Status/DNS Resolver page either.
-
@phipac said in Frequent DNS timeouts:
not use DNS over TLS
I posted it above, referencing a different thread. It didn't seem to be any problem for me at home, but others (in one or more threads, have lost track) have said it definitely made a difference. One theory offered was that a high number of DNS requests could perhaps influence it.
-
-
@phipac I switched from quad9 to cloudflare about a week ago. There was a noticeable improvement in reliability but I still experience hangs. Much fewer and lasting shorter periods. I may try openDNS next.
The theory @SteveITS mentioned seems plausible. Equally plausible is maybe I have a configuration error. I note Apple devices seem very chatty although I haven’t had the opportunity to check other os’s to compare. The hangs I experience usually happen while using iPad/iPhone’s. I haven’t noticed it on a Mac but cannot say for sure.
-
Clouadflare, quad9, OpenDNS using TLS :
Read the first phrase here : Support TLS de Postfix where Postfix could actually be 'anything'.It's probably not 'thousands' but tens of thousands of lines, because back then, TLS wasn't even TLS 1.x, but the far more simple SSL. I'm not pointing the exisyte,nce of bug, as a decade or so later, most are ironed out. But the code complexity is huge. For those who doubt : have a look at what OpenSSL is. It's open source, and it's mind boggling.
edit : and keep in mind that all the TLS carefully constructed on your side has to be undone on the other side.
Running on hardware that handles millions identical tasks .... On these guys also just found out that their electricity bill just 3 folded. So, If I was to maintain these (free !!) services, I would start to 'throttle'. What would you do ? ;)And then there is this. If entropy is missing on a system, TLS goes bad.
My words : entropy is the possibility of the system to generate random numbers. Belief it or not, these are hard to generate. And when the stock goes low, the system ... does what, wait ?
TLS eats entropy for breakfast.All that said : I've been using 1.1.1.1 and the IPv6 counterpart for several weeks.
The only thing I noticed is that I noticed nothing. I forgot that I switched from DNSSEC Resolving to forwarding over TLS.
I'm not using a big system : a SG 4100 with 23.01. -
-
-
@gertjan said in Frequent DNS timeouts:
I'm not using a big system : a SG 4100 with 23.01.
Me neither. SG-5100.
What is not clear to me in many posts is if pfBlocker is part of what folks are seeing. As many others said, I too had no problems with 22.xx and problems started after upgrading to 23.01 and new release of pfBlocker. The one change that comes to mind is using python mode for unbound.
I am now traveling and hope all the smoke settles over the next few weeks.
-
@jonh said in Frequent DNS timeouts:
that comes to mind is using python mode for unbound
That 'mode' doesn't restart unbound.
@thundergate said in Frequent DNS timeouts:
Also disabled python mode - and still all the unbound restarts.
Later on he discovered that unbound also restart when a LAN interface is take Up/Down.
So, unbound can get restarted for more then one reason.
I admit, my words, and what @thundergate wrote, are not a proof. With some luck, @BBcan177 can certify my words (but he probably won't even bother) as he can read that python script very well, as he wrote it.
pfBlockerng can restart unbound, as that is way to take in account new DNDBL info.
If it was possible to re download all the DNSBL feeds every five minutes, and (condition) one of these feeds had a changed content, then, yeah, unbound would get restarted every 5 minutes.
The golden rule always applies : the admin always rules, even if he doesn't know what he is doing ;)One of the reason why I refresh my DNSBL feeds ones a week. If a DNSBL feedactually changed, then unbound gets restarted. The cron task has been set at 3 AM sunday, so I never detect an unbound restart = a 3 seconds outage.
Also, don't see this post as a 'your are silly' and 'I am smart'. It's just me pushing you to discover what the real reason is.
The logs will tell you. -
@jonh Good information - thank you! I have not noticed a difference based on OS or manufacturer. I was seeing similar rates of hang on Windows, Linux, and Android.
Conducting a few more tests to see if I can narrow anything else down.
-
@gertjan Entropy. I hadn't considered that. I just noticed all of my ubuntu-based VMs flatlined to 256 entropy last fall. I think it lined up with the release of the 5.10 kernel but I can't be sure. It happens that I have pfsense running on proxmox, which also shows a flatline of 256 entropy. In pfsense, this is what I get from sysctl kern.random:
kern.random.fortuna.concurrent_read: 1
kern.random.fortuna.minpoolsize: 64
kern.random.rdrand.rdrand_independent_seed: 0
kern.random.use_chacha20_cipher: 1
kern.random.block_seeded_status: 0
kern.random.random_sources: 'Intel Secure Key RNG'
kern.random.harvest.mask_symbolic: PURE_VMGENID,PURE_RDRAND,[CALLOUT],[UMA],[FS_ATIME],SWI,[INTERRUPT],NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
kern.random.harvest.mask_bin: 01000000010000000101011111
kern.random.harvest.mask: 16843103
kern.random.initial_seeding.disable_bypass_warnings: 0
kern.random.initial_seeding.arc4random_bypassed_before_seeding: 0
kern.random.initial_seeding.read_random_bypassed_before_seeding: 0
kern.random.initial_seeding.bypass_before_seeding: 1 -
@gertjan said in Frequent DNS timeouts:
@jonh said in Frequent DNS timeouts:
that comes to mind is using python mode for unbound
That 'mode' doesn't restart unbound.
And I don’t believe I said anything about that mode restarting unbound..
- my unbound stops responding ever so often for 2-4 minutes. I have not seen anything in my logs about restarting during these occurances. Early on I did restart it manually, that does show in the logs. Now I just wait it out.
-
@jonh same, but everyone keeps just repeating that it must be dhcp registrations ...