Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting
-
I'll elaborate the elaborating :
@bmeeks said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
Unchecking the DNSSEC Support option prevents misbehaving DNS server ....
For short : DNSSEC can be considered as self-repairing.
Because a golden rule applies : if the admin messes up the "DNSSEC setup", his domain name will vanish from the Internet. That's known as counter productive. The site admin will be motivated to do things right.
Because all DNS data is cached all ,over the world, there is no way to have your domain accessible again with a click.
So : DNSSEC : you set it up right - or you stay away from it. There is no middle way.DNSSEC info are actually just domain zone entries, like the famous MX, A, AAAA, TXT, NS, SOA etc. They are always bigger ... like much bigger, which means that returned DNS data becomes bigger as what fits in a standard UDP packet : the DNS data exchange will fall back to the good old TCP. Which explains why DNS traffic can be UDP and/or TCP. Not UDP only.
I have this DNSSEC option checked to "On" since unbound is part of pfSense. Never had - I guess - issues that were be DNSSEC related.
DNSSEC is only meaningful if you use unbound as a Resolver.
This https://dnsviz.net/d/test-domaine.fr/dnssec/ looks like a classic DNS top to bottom tree. The absence of red and yellow info means : all is ok. The entire DNS request concerning "test-domaine.fr" is quasi "non-dns-spoofable". Which means, when you see this domain in your browser, you know that your are looking at the 'right' site.
To wrap up the story :Activating the DNSSEC shouldn't break your browser experience.
When you mess up your DNSSEC settings, this is what happens : https://forum.netgate.com/topic/153360/when-you-up-your-ksk (it was me mistyping one single command).
The site of the company where I work, was gone .... as were the mails and other related Internet services ... (room reservations).
It took me my day off, and 2 litres of coffee to correct that one.@bmeeks said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
Unbound that is being addressed in a future update
That very question makes me check regularly here https://nlnetlabs.nl/projects/unbound/about/ == the authors of unbound.
Re parsing of configuration files - or even just the IP and/or DNSBL 'lookup' files 'on the fly' during daemon execution is not scheduled - as far as I know. It would need a rather massive code base re write.
unbound has not implemented a way so it can check if a config file changed, and if so, re read it content **.
unbound is known as mean and lean, especially for a DNSSEC capable resolver. Perfect for devices like firewall etc.
When the router firewall = pfSense also runs a DHCCP server, and he, the admin, want to register DHCP host names into the local DNS (= unbound) then, yes, it will get 'kicked' when a new lease comes in.** one shouldn't expect miracles when pfBlockerNG-devel changes is main DNSBL lookup file : pfb_dnsbl.conf
I have a light weight pfBlockerNG-devel setup, and this files is already 10622077 bytes ( a bit over 10 Mega) or 133420 lines .... this will take 'some' time as the content has to be compared and/or incerted in the local DNS cache, etc. -
UPDATE: In an attempt to eliminate web browser/web page behaviour I repeatedly ran the command
time dig microsoft.com from the command line and got the following results.
Does the fact that a command timed out almost immediately after a succesful command give any clues?
;; connection timed out; no servers could be reached
real 0m15.013s / user 0m0.008s / sys 0m0.004s
When the command was repeated immediately after the failed command, it appears based on response time to have been a cached response.# First run: (should cache microsoft.com) $ time dig microsoft.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> microsoft.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40844 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;microsoft.com. IN A ;; ANSWER SECTION: microsoft.com. 3600 IN A 104.215.148.63 microsoft.com. 3600 IN A 40.76.4.15 microsoft.com. 3600 IN A 40.112.72.205 microsoft.com. 3600 IN A 40.113.200.201 microsoft.com. 3600 IN A 13.77.161.179 ;; Query time: 181 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Sat Jun 06 17:12:11 EDT 2020 ;; MSG SIZE rcvd: 122 real 0m0.193s user 0m0.000s sys 0m0.012s =============================================================== Several "normal outputs deleted" =============================================================== $ time dig microsoft.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> microsoft.com ;; global options: +cmd ;; connection timed out; no servers could be reached real 0m15.013s user 0m0.008s sys 0m0.004s =============================================================== # Run immediately after failed command - appears based on response time to be cached response. $ time dig microsoft.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> microsoft.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28504 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;microsoft.com. IN A ;; ANSWER SECTION: microsoft.com. 3544 IN A 104.215.148.63 microsoft.com. 3544 IN A 40.76.4.15 microsoft.com. 3544 IN A 40.112.72.205 microsoft.com. 3544 IN A 40.113.200.201 microsoft.com. 3544 IN A 13.77.161.179 ;; Query time: 0 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Sat Jun 06 17:14:01 EDT 2020 ;; MSG SIZE rcvd: 122 real 0m0.025s user 0m0.024s sys 0m0.000sThanks @bcruze, @bmeeks, and @Gertjan for the replies--maybe you can clarify further based on my comments below
For now I have turned off DNSSEC, but turning off "Register DHCP leases in the DNS Resolver" will break some things, so I'm reluctant to do so for now.
Is there a way for me to see how long since Unbound was restarted, and/or the state of the cache?
The network is not in a high state of flux, so devices only come on/go off when they need to be rebooted for troubleshooting. DHCP is used in lieu of static configuration since it is much easier to update and is somewhat self documenting. Should I consider extending the lease lenght?If the cache is not being flushed, then google, duckduckgo, startpage, etc. that are frequently used should be a cache hit not a full DNS resolution -- hence the DNSSEC setting should not matter -- or am I missing something? For now, I've turned it off.
Going back to my original question: Is the correct setting for Network Interfaces ("Interface IPs used by the DNS Resolver for responding to queries from clients.") - ALL?
If so: Why should my internal DNS resolver respond to queries from WAN? (or is it just a non-issue unless port 53 is opened--firewall would make sure that there were no requests from the WAN).
What about IPv6? What about the IPv6 Link Local, PFBlocker IP, and Localhost entry settings?
It has also occurred to me that this may be a pfBlocker issue and not a "DNS" issue per se. How can I troubleshoot to determine the cause of the problem?
@bcruze said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
DHCP Registration: [CHECKED[ Register DHCP leases in the DNS Resolver
DNSSEC: [CHECKED] Enable DNSSEC Supportuncheck both of those. for a day and see if its resolved:
DHCP Registration: [CHECKED[ Register DHCP leases in the DNS Resolver
DNSSEC: [CHECKED] Enable DNSSEC Support@bmeeks said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
To elaborate a bit on @bcruze's response --
Unchecking the option to register DHCP leases with Unbound (the DNS resolver) keeps Unbound from restarting each time a DHCP lease is updated. That is an unfortunate "feature" of Unbound that is being addressed in a future update (I think).
Unchecking the DNSSEC Support option prevents misbehaving DNS servers from causing problems with DNSSEC. While DNSSEC is a good idea and using it improves security, not all DNS servers out on the Internet are correctly configured for DNSSEC yet. I run a Microsoft AD behind my firewall and let the DNS server on the domain controller resolve. I tried enabling DNSSEC with it and had trouble with some web sites not resolving properly. For a time one of Microsoft's own domains would not resolve properly when DNSSEC was enabled. May be fixed now, though. I have not tried DNSSEC again in the last several months. Also don't know if the problem was with the AD DNS server on my end, or the endpoint DNS I was querying.
The most likely cause for slow DNS resolution in your setup could be the DHCP lease registrations which cause Unbound to restart each time a lease is added or updated. That slowness can be greatly compounded when you use a package such as pfBlockerNG-devel with DNSBL because Unbound has to reload and parse all of those large IP list files each time it restarts.
=============
@Gertjan said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
I'll elaborate the elaborating :@bmeeks said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
Unchecking the DNSSEC Support option prevents misbehaving DNS server ....
For short : DNSSEC can be considered as self-repairing.
Because a golden rule applies : if the admin messes up the "DNSSEC setup", his domain name will vanish from the Internet. That's known as counter productive. The site admin will be motivated to do things right.
Because all DNS data is cached all ,over the world, there is no way to have your domain accessible again with a click.
So : DNSSEC : you set it up right - or you stay away from it. There is no middle way.DNSSEC info are actually just domain zone entries, like the famous MX, A, AAAA, TXT, NS, SOA etc. They are always bigger ... like much bigger, which means that returned DNS data becomes bigger as what fits in a standard UDP packet : the DNS data exchange will fall back to the good old TCP. Which explains why DNS traffic can be UDP and/or TCP. Not UDP only.
I have this DNSSEC option checked to "On" since unbound is part of pfSense. Never had - I guess - issues that were be DNSSEC related.
DNSSEC is only meaningful if you use unbound as a Resolver.
This https://dnsviz.net/d/test-domaine.fr/dnssec/ looks like a classic DNS top to bottom tree. The absence of red and yellow info means : all is ok. The entire DNS request concerning "test-domaine.fr" is quasi "non-dns-spoofable". Which means, when you see this domain in your browser, you know that your are looking at the 'right' site.
To wrap up the story :Activating the DNSSEC shouldn't break your browser experience.
When you mess up your DNSSEC settings, this is what happens : https://forum.netgate.com/topic/153360/when-you-up-your-ksk (it was me mistyping one single command).
The site of the company where I work, was gone .... as were the mails and other related Internet services ... (room reservations).
It took me my day off, and 2 litres of coffee to correct that one.@bmeeks said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
Unbound that is being addressed in a future update
That very question makes me check regularly here https://nlnetlabs.nl/projects/unbound/about/ == the authors of unbound.
Re parsing of configuration files - or even just the IP and/or DNSBL 'lookup' files 'on the fly' during daemon execution is not scheduled - as far as I know. It would need a rather massive code base re write.
unbound has not implemented a way so it can check if a config file changed, and if so, re read it content **.
unbound is known as mean and lean, especially for a DNSSEC capable resolver. Perfect for devices like firewall etc.
When the router firewall = pfSense also runs a DHCCP server, and he, the admin, want to register DHCP host names into the local DNS (= unbound) then, yes, it will get 'kicked' when a new lease comes in.** one shouldn't expect miracles when pfBlockerNG-devel changes is main DNSBL lookup file : pfb_dnsbl.conf
I have a light weight pfBlockerNG-devel setup, and this files is already 10622077 bytes ( a bit over 10 Mega) or 133420 lines .... this will take 'some' time as the content has to be compared and/or incerted in the local DNS cache, etc. -
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
but turning off "Register DHCP leases in the DNS Resolver" will break some things
It should not. What "thing" can it break ?
For all the devices that you need to "address" by hostname, or known, fixed LAN IP, use Static MAC leases. All the others are just 'consumer' devices, not offering any services to the network, so you don't care if they are listed in the DNS.@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
Is there a way for me to see how long since Unbound was restarted, and/or the state of the cache?
@johnpoz posted that command some time ago.
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
Going back to my original question: Is the correct setting for Network Interfaces ("Interface IPs used by the DNS Resolver for responding to queries from clients.") - ALL?
Yes.
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
If so: Why should my internal DNS resolver respond to queries from WAN? (or is it just a non-issue unless port 53 is opened--firewall would make sure that there were no requests from the WAN).
It doesn't. Remember : the default firewall behaviour is : nothing gets in.
Btw : check out the GUI web server process nginx : it listens on all interfaces, this includes WAN. (!). Still, by default, no one can connect to the GUI from WAN.
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
How can I troubleshoot to determine the cause of the problem?
First step : Remove pfBBlocker and does the issue goes away ?
Next step : use pfBlocker with minimal options and feeds, just a small one.
Closely monitor system resources at each step.
Monitor unbound restarts.
Etc etc -
@Gertjan said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
Is there a way for me to see how long since Unbound was restarted, and/or the state of the cache?
@johnpoz posted that command some time ago.
Not sure what you mean here. my best guess is that examining clog /var/log/resolver.log is the best way to determine what is going on.
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
How can I troubleshoot to determine the cause of the problem?
First step : Remove pfBBlocker and does the issue goes away ?
Next step : use pfBlocker with minimal options and feeds, just a small one.
Closely monitor system resources at each step.
Monitor unbound restarts.
Etc etc@Gertjan Thanks for the suggestions.... I was able to able to repeat the problem at approximately "Jun 8 02:39:01" -- I have copied some of the log both before an after the problem. I'm not sure where to look next but I suspect:
Jun 8 02:39:01 guardian unbound: [75093:0] info: service stopped (unbound 1.9.6).
and the presence of IPv6 (when IPv6 is turned off on all interfaces and on most network devices.
I have attached the relevant log entries-there are some "noise" searches from an open web browser on a PC..Why is the service stopped? Does the log give any clue?
-
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
Does the log give any clue?
Noop.
That is : it was asked to stop - actually : restart - at :Jun 8 02:39:01 guardian unbound: [75093:0] info: service stopped (unbound 1.9.6)After that line, a lot of sessions statistics are logged.
Then, as it was asked to restart :Jun 8 02:39:26 guardian unbound: [75093:0] info: start of service (unbound 1.9.6).You might try to stop the usage of IPv6, that's ok for now.
The rest of the world - that is : the Internet itself - is already IPv6 - and if that doesn't work out, it falls back to IPv4.This :
.... Jun 8 02:39:26 guardian unbound: [75093:1] debug: Need to send query but have no outgoing interfaces of that family Jun 8 02:39:26 guardian unbound: [75093:1] info: error sending query to auth server 2001:500:9f::42 port 53 Jun 8 02:39:26 guardian unbound: [75093:1] info: processQueryTargets: . NS IN Jun 8 02:39:26 guardian unbound: [75093:1] info: sending query: . NS IN Jun 8 02:39:26 guardian unbound: [75093:1] debug: sending to target: <.> 192.112.36.4#53 ....The first IPv6 and second IPv4 when it falls back to it , is one of the 13 main Internet Root servers.
unbound contacts them when it starts.
unbound is compiled with IPv6 - and use IPv4 as an alternative.Btw : this is is not a problem, as it is good enough if one of both protocols works.
For now ;)Too find who restarted unbound : see the other logs - at the same this moment : 02:39:01
-
Thanks @Gertjan
@Gertjan said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
Does the log give any clue?
Noop.
That is : it was asked to stop - actually : restart - at :What process would ask it to stop/restart? I could not find anything in /var/log/system.log where else would I look
Jun 8 02:39:01 guardian unbound: [75093:0] info: service stopped (unbound 1.9.6)After that line, a lot of sessions statistics are logged.
Then, as it was asked to restart :Jun 8 02:39:26 guardian unbound: [75093:0] info: start of service (unbound 1.9.6).You might try to stop the usage of IPv6, that's ok for now.
How do I do that? I IPv6 is disabled on all interfaces - What else do I need to do
The rest of the world - that is : the Internet itself - is already IPv6 - and if that doesn't work out, it falls back to IPv4.
This :
.... Jun 8 02:39:26 guardian unbound: [75093:1] debug: Need to send query but have no outgoing interfaces of that family Jun 8 02:39:26 guardian unbound: [75093:1] info: error sending query to auth server 2001:500:9f::42 port 53 Jun 8 02:39:26 guardian unbound: [75093:1] info: processQueryTargets: . NS IN Jun 8 02:39:26 guardian unbound: [75093:1] info: sending query: . NS IN Jun 8 02:39:26 guardian unbound: [75093:1] debug: sending to target: <.> 192.112.36.4#53 ....The first IPv6 and second IPv4 when it falls back to it , is one of the 13 main Internet Root servers.
unbound contacts them when it starts.
unbound is compiled with IPv6 - and use IPv4 as an alternative.Btw : this is is not a problem, as it is good enough if one of both protocols works.
For now ;)Too find who restarted unbound : see the other logs - at the same this moment : 02:39:01
This is the complete contents of /var/log/system.log around this time are:
Jun 8 02:05:28 guardian sshd[67229]: Accepted password for root from 172.16.50.33 port 45302 ssh2 Jun 8 02:15:09 guardian php: [pfBlockerNG] Starting cron process. Jun 8 02:42:52 guardian kernel: ugen0.4: <Logitech USB Optical Mouse> at usbus0Suggestions?
-
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
Jun 8 02:15:09 guardian php: [pfBlockerNG] Starting cron process.
...
What process would ask it to stop/restart? I could not find anything in /var/log/system.log where else would I lookYou missed a log ........ and were not aware the pfBlockerNG has "something to do with DNS" .....
According to you, pfBlockerNG does what ? using what ?
A short answer It download and "handles" lists with hostnames and IP's, so it can be used by unbound, the DNS resolver.
unbound only re reads these list - if changed - during startup.
Check the pfBlockerNG logs. It's restarting unbound '"all the time".Btw : incoming new DHCP lease could also restart unbound, as many other system events.
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
How do I do that? I IPv6 is disabled on all interfaces - What else do I need to do
The fact that you block incoming IPv6 traffic on interfaces doesn't mean process running on pfSense, or even the kernel itself do not try to use IPv6.
Again, not really a problem. -
@Gertjan said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
Jun 8 02:15:09 guardian php: [pfBlockerNG] Starting cron process.
...
What process would ask it to stop/restart? I could not find anything in /var/log/system.log where else would I lookYou missed a log ........ and were not aware the pfBlockerNG has "something to do with DNS" .....
According to you, pfBlockerNG does what ? using what ?
A short answer It download and "handles" lists with hostnames and IP's, so it can be used by unbound, the DNS resolver.
unbound only re reads these list - if changed - during startup.
Check the pfBlockerNG logs. It's restarting unbound '"all the time".Btw : incoming new DHCP lease could also restart unbound, as many other system events.
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
How do I do that? I IPv6 is disabled on all interfaces - What else do I need to do
The fact that you block incoming IPv6 traffic on interfaces doesn't mean process running on pfSense, or even the kernel itself do not try to use IPv6.
Again, not really a problem.Thanks for the input @Gertjan can you (or anyone else please elaborate or clarify any on the following):
Check the pfBlockerNG logs. It's restarting unbound '"all the time".
Thanks for mentioning that - just checked the log - I was aware that it will reload on update, which is maximum 1/hour -- the problem is more frequent than the the number of reloads I am seeing in the pfBlocker log -- I am only seeing a reload after update.Btw : incoming new DHCP lease could also restart unbound, as many other system events.
Why would I have a incoming new DHCP lease? (I should also mention that I took your advice and uncheced Register DHCP leases in the DNS Resolver.) I am on a small home network, there a re not a lot of changes occurring (unless there is something I am not aware of or my understanding of how things work is off). Am I missing something? How can I check this?The fact that you block incoming IPv6 traffic on interfaces doesn't mean process running on pfSense, or even the kernel itself do not try to use IPv6.
That was my understanding. What did you mean in one of your early posts by:
You might try to stop the usage of IPv6, that's ok for now.
Suggestions?
-
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
clarify any on the following
pfBlockerNG-devel : you're using it, right ?
Wrong. The actual work is done by the unbound, that matches DNS requests and IP's with the lists it loaded. These lists are prepared by pfBlockerNG-devel. When pfBlockerNG-deve has new info, it restart unbound.
Can't be more clear about that.Same thing from DHCP leases : if checked (see settings unbound first page) a new lease - the IP and host ,ame are added to the list of local devices, so that unbound can tell( == resolve ) how to address this device to the other devices. That's what DNS is all about on a local scale.
IPv6 : It works - it's the future. IPv4 will last for a while but soon IPv6 only hosts exist.
-
@Gertjan said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
clarify any on the following
pfBlockerNG-devel : you're using it, right ?
I'm using pfBlockerNG v2.1.4_22 not the devel version
Wrong. The actual work is done by the unbound, that matches DNS requests and IP's with the lists it loaded. These lists are prepared by pfBlockerNG-devel. When pfBlockerNG-deve has new info, it restart unbound.
Can't be more clear about that.I understand that - what I don't understand is why Unbound is restarting so often
Same thing from DHCP leases : if checked (see settings unbound first page) a new lease - the IP and host ,ame are added to the list of local devices, so that unbound can tell( == resolve ) how to address this device to the other devices. That's what DNS is all about on a local scale.
IPv6 : It works - it's the future. IPv4 will last for a while but soon IPv6 only hosts exist.
I have been avoiding IPv6 for as long as possible since security practices/system have some catching up to do.
-
@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
I'm using pfBlockerNG v2.1.4_22 not the devel version
Ah ....
We all, the author included, switch to devel years ago.@guardian said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
why Unbound is restarting so often
We're in a loop here.
To see what restarts unbound, check the logs. I can't tell it from here.
You'll have to look, tell us who's doing it.
We tell you what not do do so it starts less often.What's often ?
Executeclog /var/log/resolver.log | grep 'Restart of'If you have this one checked :
then, related to the number of devices in your network - or if you have a stupid device that asks a new lease every minute or so, then yes, unbound will get restart that many times.
I also advise you to remove the ancient pfBlockerNG.
Get the far better pfBlockerNG-devel - version 2.2.5_32First remove the current pfBlockerNG. Wait a day or so before installing the new one.
During that time, unbound starts less often ?edit : this one :
When you use the OpenVPN server - and a client(s) are connected, every time the tunnel goes up and down, because you shifted Wifi SSID - or went from Wifi to data carrier, unbound gets restarted.
I just saw this :Jun 9 09:27:09 pfsense unbound: [31040:0] notice: Restart of unbound 1.10.1. Jun 9 09:27:14 pfsense unbound: [31040:0] notice: Restart of unbound 1.10.1. Jun 9 09:27:38 pfsense unbound: [31040:0] notice: Restart of unbound 1.10.1.So, keep this option unchecked also.
-
@Gertjan said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
clog /var/log/resolver.log | grep 'Restart of
Followup :Since the last
Jun 9 09:29:03 pfsense unbound: [31040:0] notice: Restart of unbound 1.10.1.posted previously, I had no more unbound resstarts.
That is : I update pfBlockerNG-devel feeds every 3 days, or less frequent (if they are themselves updated every week, I respect that time frame - no need to update all feeds every hour as seen elsewhere) as pfBlockerNG will restart unbound if one or more of the lists changed.
-
@Gertjan said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
@Gertjan said in Question re slow DNS resolution/General DNS Resolver Options setup/Troubleshooting:
clog /var/log/resolver.log | grep 'Restart of
Followup :Since the last
Jun 9 09:29:03 pfsense unbound: [31040:0] notice: Restart of unbound 1.10.1.posted previously, I had no more unbound resstarts.
That is : I update pfBlockerNG-devel feeds every 3 days, or less frequent (if they are themselves updated every week, I respect that time frame - no need to update all feeds every hour as seen elsewhere) as pfBlockerNG will restart unbound if one or more of the lists changed.
Thanks for the update @Gertjan - I'm not 100% sure what happened, but I think that I might have had a problem with one of the feeds. I did a bit of a cleanup, and got rid of a couple of feeds. The system still restarts, but just once an hour, and it doesn't seem to cause problems with DNS resolution now.
I have a script running as we speak that does a dig microsoft.com every 5 seconds until such time as an error occurs. It ran for several hours yesterday, and I have it running again now.
