DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times
-
I've been using pfsense for years without this issue and I've made no recent changes to the config but a couple weeks ago my wife started complaining about briefly not being able to "use the internet" and I didn't believe her cause I would be streaming or something at the time and by the time I tested her devices, it was fine. But I experienced it yesterday and today, DNS_PROBE_FINISHED_NXDOMAIN will flash on the browser when trying to access webpages via url. This happens on my main LAN and VLAN's and resolves itself in anywhere between 30 seconds to 10 minutes and then I experience no issues at any other time (that i can tell). I can use other aspects of the internet and can even ping google.com from the command line with low latency. I've tested on android and Mac Chrome browsers but its so far fixed itself before i can get to another browser or device. What gives? I don't even know where to begin to troubleshoot this but my hunch is that the DNS server is being overloaded briefly by something? Not sure how reasonable a theory this is or how to track it down but it's the best I got right now...
I use DNS Resolver with basically default settings (enabled on all interfaces, DNSSEC enabled, Register DHCP, Static DHCP, OpenVPN all enabled), all the devices are pointed to the pfsense box for their DNS Server. In the DNS Server(s) on the main page I have listed:
-
127.0.0.1
-
8.8.8.8
-
208.67.220.220
-
8.8.4.4
-
208.67.222.222
Any advice extremely appreciated!
-
-
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
Register DHCP
This is going to restart unbound.. So yeah depending how much unbound is restarting, and how long it takes to restart.. If you have pfblocker enabled with lots of stuff and delays the restart of unbound then sure you can have problematic dns issues if unbound is not running when you ask for something.
Also if your using unbound in default, ie a resolver then those other dns settings make no sense. If your using unbound, the only thing that should be in pfsense dns is 127.0.0.1
Also just generally pointing to google and opendns in general is problematic in that one filters and the other doesn't so you have no idea which one would be queried - so something your looking for might be filtered or it might not be.. This is generally bad practice.
-
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
If you have pfblocker enabled
I do not currently have pfblocker enabled. I thought about it in the past but for, kind of, this reason (not being able to troubleshoot issues well) I decided against it. perhaps something else is delaying the restart? but wouldn't restart only happen when the DHCP settings change?
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
Also if your using unbound in default
I'll be honest, i read as many posts (in English) as I could with DNS_PROBE_FINISHED_NXDOMAIN in the title and this came up a lot and I think i fundamentally don't understand EXACTLY what unbound is, so I think with that lack of fundamental understanding it's hard for me to understand why the setting should just be 127.0.0.1....I'd love to understand the mechanics better so I can understand what I did wrong (or why it's all of a sudden been an issue after years of not being one), but if your suggestion is to simply remove the other 4 lower entries, i'm happy to try that...Should I do that before unclicking "Register DHCP"? vice versa? both?
-
@RickyBaker unbound is a resolver.. Ie if you ask it for www.somedomain.tld it will ask the root servers, hey what is the NS (nameserver) for .tld, then ask hey NSers of .tld what is the ns for somedomain.tld, then hey ns for somedomain.tld what is the IP address of www.somedomain.tld
You can see this in action with say a dig www.netgate.com +trace.
; <<>> DiG 9.18.16 <<>> www.netgate.com +trace +nodnssec ;; global options: +cmd . 75782 IN NS j.root-servers.net. . 75782 IN NS k.root-servers.net. . 75782 IN NS b.root-servers.net. . 75782 IN NS m.root-servers.net. . 75782 IN NS f.root-servers.net. . 75782 IN NS i.root-servers.net. . 75782 IN NS l.root-servers.net. . 75782 IN NS d.root-servers.net. . 75782 IN NS a.root-servers.net. . 75782 IN NS g.root-servers.net. . 75782 IN NS e.root-servers.net. . 75782 IN NS h.root-servers.net. . 75782 IN NS c.root-servers.net. ;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. ;; Received 840 bytes from 198.97.190.53#53(h.root-servers.net) in 27 ms netgate.com. 172800 IN NS ns1.netgate.com. netgate.com. 172800 IN NS ns2.netgate.com. netgate.com. 172800 IN NS ns3.netgate.com. ;; Received 230 bytes from 192.12.94.30#53(e.gtld-servers.net) in 39 ms www.netgate.com. 60 IN CNAME 1826203.group3.sites.hubspot.net. ;; Received 118 bytes from 208.123.73.80#53(ns1.netgate.com) in 48 ms [23.09.1-RELEASE][admin@sg4860.home.arpa]/root:
I did it without dnssec so easier to read.
Now this info will be cached, so if you ask for say somethingelse.somedomain.tld it will just ask the ns for somedomain.tld directly.
With a forward, when you ask say 8.8.8.8 for www.somedomain.tld, it will either have that already cached, or it would have to resolve it just like the above, or it will itself forward to some other dns that is a resolver. Resolvers is how the internet works.. Without resolvers dns would never work.
As to register dhcp, no that restarts unbound every single time there is a dhcp event, client gets an IP, client renews an IP, etc.. Look in your log is unbound restarting - look for next time you have an issue - was unbound restarting, or restarted exactly when you had your dns problem?
If you register static dhcp, then this only restarts unbound when you add a new record for static dhcp.. But with register dhcp every single dhcp event will restart unbound.
If you only have a few clients, and a decent length lease time so there are not many events then you may never notice it.
Your browser throwing up an error about dns, could be maybe dns was having issues resolving what you asked for... You could do an above example +trace on pfsense to see if maybe your just having a problem talking to a NS to find what your looking for..
-
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
DNSSEC enabled
In the DNS Server(s) on the main page I have listed
If you have DNS Resolver set to forward to those servers, disable DNSSEC. If not then that list of DNS servers isn't used. (forwarding is not a default setting)
-
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
@RickyBaker unbound is a resolver.. Ie if you ask it for www.somedomain.tld it will ask the root servers, hey what is the NS (nameserver) for .tld, then ask hey NSers of .tld what is the ns for somedomain.tld, then hey ns for somedomain.tld what is the IP address of www.somedomain.tld
thank you! that's a very good explanation. so it's kind of the structural umbrella above the DNS server...and it seems like it includes DNS servers? so it's really overkill to include google/opendns ones?
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
As to register dhcp, no that restarts unbound every single time there is a dhcp event, client gets an IP, client renews an IP, etc.. Look in your log is unbound restarting - look for next time you have an issue - was unbound restarting, or restarted exactly when you had your dns problem?
ok great, this is a good troubleshooting action plan. I did remove the 4 extra DNS servers from General Setup and still had a "No internet" event this morning that lasted 2-3 minutes. I subsequently restarted my Unifi Switches, just cause...will dig into the log now
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
If you register static dhcp, then this only restarts unbound when you add a new record for static dhcp.. But with register dhcp every single dhcp event will restart unbound.
yeah this seems like an excessive amt of work, i'll disable for now and see what breaks. What type of use-case is the Register DHCP option typically used for? What benefit am I giving up by disabling it?
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
If you only have a few clients, and a decent length lease time so there are not many events then you may never notice it.
I have a TON of clients and a TON of static DHCP addresses. I use default lease time, never considered changing that but maybe I should..
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
Your browser throwing up an error about dns, could be maybe dns was having issues resolving what you asked for... You could do an above example +trace on pfsense to see if maybe your just having a problem talking to a NS to find what your looking for..
another good suggestion. I've actually never heard of dig before. I'll have to research how to use it but your example should help, what type of shell is that being executed in?
-
@RickyBaker Dig is a program similar to nslookup, distributed with BIND, on Windows as part of the "tools" install choice, and could be installed by itself. However BIND on Windows is EOL so not sure if you can get it from isc.org anymore.
It is much more common on Linux/BSD.
use-case is the Register DHCP option
To access PCs by full hostname, however, often PCs can discover other PCs on the network.
-
@SteveITS you can still get dig for windows... Its just a bit behind what is current version.. And yeah they are not going to provide it past the 9.16 branch.
I use it all the time, but you can install on wsl on windows so there is that which is on the 9.18 branch and underdevelopment
user@i9-win:~$ dig ; <<>> DiG 9.18.26-1+ubuntu22.04.1+deb.sury.org+1-Ubuntu <<>>
Latest for windows is 9.16.50
$ dig ; <<>> DiG 9.16.50 <<>>
side note, how to say you don't know anything about dns without stating you don't know anything about dns..
"I've actually never heard of dig before." hahahah
-
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
side note, how to say you don't know anything about dns without stating you don't know anything about dns..
"I've actually never heard of dig before." hahahah
o i never claimed to know anything about DNS. or much of anything for that matter. I'll be honest, a bit out of my depth with dig. Downloaded the zip from isc.org and installed it but i'm really not sure how to execute it.
I'm likewise a bit out of my depth with the logs. I've navigated to the DHCP subsection of the systemlogs and see the restarts you were referring to from before I disabled "Register DHCP" but nothing alarming just after it. But i have no idea what to be looking for. Can I upload the log for more expert eyes to see if anything jumps out?
-
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
but i'm really not sure how to execute it.
type dig ;) at a command prompt
$ dig -h Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt} {global-d-opt} host [@local-server] {local-d-opt} [ host [@local-server] {local-d-opt} [...]] Where: domain is in the Domain Name System q-class is one of (in,hs,ch,...) [default: in] q-type is one of (a,any,mx,ns,soa,hinfo,axfr,txt,...) [default:a] (Use ixfr=version for type ixfr) q-opt is one of: -4 (use IPv4 query transport only) -6 (use IPv6 query transport only) -b address[#port] (bind to source address/port) -c class (specify query class) -f filename (batch mode) -k keyfile (specify tsig key file) -m (enable memory usage debugging) -p port (specify port number) -q name (specify query name) -r (do not read ~/.digrc) -t type (specify query type) -u (display times in usec instead of msec) -x dot-notation (shortcut for reverse lookups) -y [hmac:]name:key (specify named base64 tsig key) d-opt is of the form +keyword[=value], where keyword is: +[no]aaflag (Set AA flag in query (+[no]aaflag)) +[no]aaonly (Set AA flag in query (+[no]aaflag)) +[no]additional (Control display of additional section) +[no]adflag (Set AD flag in query (default on)) +[no]all (Set or clear all display flags) +[no]answer (Control display of answer section) +[no]authority (Control display of authority section) +[no]badcookie (Retry BADCOOKIE responses) +[no]besteffort (Try to parse even illegal messages) +bufsize[=###] (Set EDNS0 Max UDP packet size) +[no]cdflag (Set checking disabled flag in query) +[no]class (Control display of class in records) +[no]cmd (Control display of command line - global option) +[no]comments (Control display of packet header and section name comments) +[no]cookie (Add a COOKIE option to the request) +[no]crypto (Control display of cryptographic fields in records) +[no]defname (Use search list (+[no]search)) +[no]dnssec (Request DNSSEC records) +domain=### (Set default domainname) +[no]dscp[=###] (Set the DSCP value to ### [0..63]) +[no]edns[=###] (Set EDNS version) [0] +ednsflags=### (Set EDNS flag bits) +[no]ednsnegotiation (Set EDNS version negotiation) +ednsopt=###[:value] (Send specified EDNS option) +noednsopt (Clear list of +ednsopt options) +[no]expandaaaa (Expand AAAA records) +[no]expire (Request time to expire) +[no]fail (Don't try next server on SERVFAIL) +[no]header-only (Send query without a question section) +[no]identify (ID responders in short answers) +[no]ignore (Don't revert to TCP for TC responses.) +[no]keepalive (Request EDNS TCP keepalive) +[no]keepopen (Keep the TCP socket open between queries) +[no]mapped (Allow mapped IPv4 over IPv6) +[no]multiline (Print records in an expanded format) +ndots=### (Set search NDOTS value) +[no]nsid (Request Name Server ID) +[no]nssearch (Search all authoritative nameservers) +[no]onesoa (AXFR prints only one soa record) +[no]opcode=### (Set the opcode of the request) +padding=### (Set padding block size [0]) +[no]qr (Print question before sending) +[no]question (Control display of question section) +[no]raflag (Set RA flag in query (+[no]raflag)) +[no]rdflag (Recursive mode (+[no]recurse)) +[no]recurse (Recursive mode (+[no]rdflag)) +retry=### (Set number of UDP retries) [2] +[no]rrcomments (Control display of per-record comments) +[no]search (Set whether to use searchlist) +[no]short (Display nothing except short form of answers - global option) +[no]showsearch (Search with intermediate results) +[no]split=## (Split hex/base64 fields into chunks) +[no]stats (Control display of statistics) +subnet=addr (Set edns-client-subnet option) +[no]tcflag (Set TC flag in query (+[no]tcflag)) +[no]tcp (TCP mode (+[no]vc)) +timeout=### (Set query timeout) [5] +[no]trace (Trace delegation down from root [+dnssec]) +tries=### (Set number of UDP attempts) [3] +[no]ttlid (Control display of ttls in records) +[no]ttlunits (Display TTLs in human-readable units) +[no]unexpected (Print replies from unexpected sources default=off) +[no]unknownformat (Print RDATA in RFC 3597 "unknown" format) +[no]vc (TCP mode (+[no]tcp)) +[no]yaml (Present the results as YAML) +[no]zflag (Set Z flag in query) global d-opts and servers (before host name) affect all queries. local d-opts and servers (after host name) affect only that lookup. -h (print help and exit) -v (print version and exit)
Sure you can upload stuff.. There are some file size limits and such
-
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
type dig ;) at a command prompt
lol yeah obviously not in the windows cmd prompt i was trying it in. I thought installing the package from isc.org would install the command into the PATH but i guess not. I will try on a linux machine.
as for the logs, took me a while but here's some logs
dhcp: https://pastebin.com/3RuMUSc2
resolver: https://pastebin.com/3GFsYCE7 (not sure why this stopped updating on saturday, probably from one of the changes i instituted)
system: https://pastebin.com/1c6PwRu2let me know if any others would be useful. fwiw my wife experienced the error around 8:24am today (4.23.24
-
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
type dig ;) at a command prompt
well i'll be...
tried to paste as code like you but kept identifying as spam. Running the same command while ssh'ed into the pfsense box though:
-
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
resolver: https://pastebin.com/3GFsYCE7
Unbound restarted 32 times in the ~1.5 days of log you posted. Looks like your DHCP is set for a 2 hour lease (meaning 1 hour renewal). You could try extending that to say 8 or 12 hours.
I don't see whether you posted you tried with DNSSEC disabled. Are you actually forwarding or not?
-
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
Looks like your DHCP is set for a 2 hour lease (meaning 1 hour renewal). You could try extending that to say 8 or 12 hours.
thanks, i'll look for that option and change it to 8
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
I don't see whether you posted you tried with DNSSEC disabled. Are you actually forwarding or not?
🔒 Log in to view
is this option not showing up unticked in the logs? or is this screenshot suffice to say it's disabled.
I don't think I'm forwarding?
🔒 Log in to view -
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
or is this screenshot suffice to say it's disabled.
That's fine, I just didn't see a response above. Before 23.01 forwarding + DNSSEC didn't seem to be a problem but after 23.01 it often is.
There's a checkbox in the resolver settings to forward but if DNSSEC is disabled that point is irrelevant.
-
@SteveITS Happened again this morning. Though just for my wife. She got DNS_PROBE_FINISHED_NXDOMAIN error in chrome but said the amazon link worked (so weird) but I did not experience any issues by the time i got a browser opened. This is the log for around that time:
I did notice that attack from 180.101.88.225 with a Level 10 a LOT in the logs, is it possible my firewall has misidentified some of my devices as attackers? But then quickly resolves that's wrong before making the same mistake again soon?
-
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
180.101.88.225 with a Level 10 a LOT in the logs, is it possible my firewall has misidentified some of my devices as attackers?
misidentified ?
It's 180.101.88.225. No doubt about it.
It that IP coming from your LAN ? Disconnect it, have it cleaned. Do have a talk with the owner.
Is the IP coming from the Internet ? Empty the WAN firewall rule list, and you're good. I would fire the pfSense adminedit : no LAN IP, whois told me "180.101.88.225" is Chinese allocated.
Rip out your WAN cable now. We'll talk later ^^ -
@RickyBaker the “now monitoring attacks” is logged whenever a log file rotates so is normal.
The logged attacks though do indicate you have port 22 open on WAN, and check for other ports too, as that’s a good way to get hacked.
-
@SteveITS so close port 22 immediately?
-
@RickyBaker I'd close all ports on WAN that are not needed. By default WAN has no rules so all incoming traffic from the Internet is blocked.
-
@SteveITS I certainly did not intentionally leave any ports open...Am firing up my VPN now...These logs are saying this IP is TRYING to access my network, not accessing it though right?
-
@RickyBaker
Not "closing".
Don't use any firewall rules that allow SSH access (port 22) or actually any access on the WAN interface.
Exactly like the way you found it, when installing pfSense.
No rules on WAN = safe.
Opening port 22 = "China" (the entire planet in reality) is lining up for you to 'try'.There is an exception (as always) :
If you activate a VPN server (on pfSense), this will, by default, allow UDP traffic on port 1194 on the WAN interface.
If you need to access resources from the outside = WAN, use a VPN, or comparable. -
@Gertjan said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
There is an exception (as always) :
If you activate a VPN server (on pfSense), this will, by default, allow UDP traffic on port 1194 on the WAN interface.
If you need to access resources from the outside = WAN, use a VPN, or comparable.I do! there's always the concern i messed up during set up, but that was the intention. checking now
-
f#$k this looks wide open. i dunno how that happened it says it comes from OpenVPN wizard. Is this wrong? Should Destination port be changed from asterix to 1194?
-
@RickyBaker 🔒 Log in to view
also, DEF didn't put in this rule, that ip address is my Synology box, think it added this rule via UPNP? -
@RickyBaker I would guess, it was edited at some point and the description remained. If you look at the rule without saving it, it will show a created and last saved date at the bottom.
Yes it should be 1194 UDP.
The floating rule could be from traffic shaping? (per the m_P2P text)
-
@SteveITS this look right then? 🔒 Log in to view
disabled the floating rule and made this change and still have access to the pfsense remotely so seems to not have broken the openvpn connection, thank you for the confirmation.
I would LOVE to do traffic shaping but I have not actually attempted it in many years and recently redid all the rules to add VLANs so i'm very puzzled by this (I also don't even use the Synology really) but you are absolutely right that qP2P sure looks like a traffic shaping effort...very disconcerting
-
@RickyBaker yes that looks better and will not allow connections to 22/80/443.
What is the date on the floating rule? (bottom of the edit rule page)
-
@SteveITS that's it, Created and Updated 2/4/17 by Traffic Shaper Wizard. That was pre kids and pre VPN. Thanks for teaching me that trick. happy to just disable, possibly just delete
-
@SteveITS thanks so much for your help with this. Assuming for the best that the attacker was not able to gain access, what is my next steps? Could this have caused my weird DNS/DHCP problems or is this just a "happy" coincidence that y'all helped me find this vulnerability.
Currently tracking down the 4 DHCP leases that aren't statically assigned. FIgured out 2 of them, need to google Part II research for the 3rd and the 4th was idle so i just booted it
-
@RickyBaker I think it's just a coincidence but a fortunate one.
Is there anything notable in the DNS Resolver log when the outage happens?
-
The final device has this mac address manufacturer. The most common device seems to be a Dreo fan (which I don't have). Googling isn't ringing any bells and pointing to the IP address doesn't give me a splash page or anything. Any advice on blocking just this mac address so I can see what breaks?
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
Is there anything notable in the DNS Resolver log when the outage happens?
Surprisingly sparse....
-
@RickyBaker the DHCP log seems like all the same as well:
🔒 Log in to view -
@RickyBaker if your DNS outage wa around 6:26-6:40 and you have DHCP set to register leases in DNS, unbound would have restarted a bunch of times there.
re: MAC, it has to be something on the network. You could find its IP on the Status/DHCP leases page and create a rule on LAN to block (or allow, and/or log) it.
-
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
if your DNS outage wa around 6:26-6:40 and you have DHCP set to register leases in DNS, unbound would have restarted a bunch of times there.
per @johnpoz suggestion i have unchecked "Register DHCP", should I re-enable for testing purposes?
@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
re: MAC, it has to be something on the network. You could find its IP on the Status/DHCP leases page and create a rule on LAN to block (or allow, and/or log) it.
good suggestion. I THINK i found it. My wife recently purchased a fancy humidifier that, for some reason, has internet connectivity. So i will confirm when i'm home but that's most likely it...So no errant devices that aren't accounted for aside from the stale lease i booted.
-
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
i have unchecked "Register DHCP", should I re-enable for testing purposes
No, having it on is unlikely to help here. It's hard to keep track of multiple threads over a few days...
So is unbound no longer restarting? But still the errors? I do not have another idea. Perhaps, on the DNS Resolver advanced page raise Log Level temporarily and see if that provides any info.
-
@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
This is going to restart unbound..
i thought this was fixed last year, no?
-
@michmoor said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
thought this was fixed last year, no?
nope still open
https://redmine.pfsense.org/issues/5413 -
@michmoor said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
i thought this was fixed last year, no?
update: https://forum.netgate.com/topic/187506/kea-dhcp-feature-roadmap/6
-
@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
per @johnpoz suggestion i have unchecked "Register DHCP", should I re-enable for testing purposes?
Certainly not ;) Keep it of.
Your DHCP log image above show about 10 DHCP request/renewals in let then (42-26)=16 minutes.
That means 10 unbound restart in 16 minutes ...
Every restart takes ... 30 seconds ? So during this 16 minutes your DNS is 'out' for 5 minutes.
That's not good at all.And before you start to think : isn't that totally flawed ?
Yes, it is. But help is coming - see here what cmcdonald said this morning.
( some of us are waiting for this to happen ... ten years )@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:
f your DNS outage wa around 6:26-6:40 and you have DHCP set to register leases in DNS, unbound would have restarted a bunch of times there.
Exact.
As I said above.
Or, his unbound doesn't restart that often. Not 10 x in 16 minutes ^^@RickyBaker : I saw you use 10.10.10.x as a LAN network
You don't use pfBlockerng, right ?