DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times

[RickyBaker]

@Gertjan i know i know. here's the dns log: https://pastebin.com/FCRuijbe i can't seem to find the right degree of logging. If I set it to 1 I get almost no information, if I set it to 2 or above 2000 lines doesn't go back 2 minutes. I'll be setting at 2 though cause this is useless.

I'll be totally honest, it happened at the worst possible time. I was watching both my kids and making dinner (trying to look up a recipe). the closest computer was floors away and I just didn't have time. I very quickly ran the ping on my phone before i burned the garlic:). I'm "hoping" for a more opportune break down tonight.

[RickyBaker]

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

int your options box in unbound

This look right?

[Gertjan]

@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

If I set it to 1 I get almost no information

Leave it to 1.

This - most recent at the top :

May 6 14:05:33	unbound	41106	[41106:0] info: average recursion processing time 0.809539 sec
May 6 14:05:33	unbound	41106	[41106:0] info: server stats for thread 0: requestlist max 62 avg 2.13559 exceeded 0 jostled 0
May 6 14:05:33	unbound	41106	[41106:0] info: server stats for thread 0: 46864 queries, 34916 answers from cache, 11948 recursions, 0 prefetch, 0 rejected by ip ratelimiting
May 6 14:05:33	unbound	41106	[41106:0] info: service stopped (unbound 1.17.1).
May 6 13:04:22	unbound	41106	[41106:0] info: generate keytag query _ta-4f66. NULL IN
May 6 01:40:18	unbound	41106	[41106:0] info: generate keytag query _ta-4f66. NULL IN
May 5 14:44:33	unbound	41106	[41106:0] info: generate keytag query _ta-4f66. NULL IN
May 5 02:54:05	unbound	41106	[41106:0] info: generate keytag query _ta-4f66. NULL IN
May 4 15:34:00	newsyslog	97047	logfile turned over due to size>500K
May 4 15:34:00	newsyslog	97047	logfile turned over due to size>500K
May 4 15:33:17	unbound	41106	[41106:1] info: generate keytag query _ta-4f66. NULL IN
May 4 15:33:17	unbound	41106	[41106:0] info: start of service (unbound 1.17.1).
May 4 15:33:17	unbound	41106	[41106:0] notice: init module 1: iterator

is somewhat strange.
Up until May 4 15:34:17 you get hundreds of log line per second. Not an issue, but this will flood the logs. To make logs more useful, and if possible (disk size), make logs files way bigger then just "500K", for example 2Mbytes each.

Then there is the line from the system logger at 15h34 that says : time's up, file to big, rotating.
From that moment, no more unbound logs ....
Lines start to re appear the next day with the usual, hourly "info: generate keytag query _ta-4f66.NULL IN" It looks like unbound now logs at "level 1"

And the the log continues at May 6. ..... again a rather big gap in the logging.

I'm pretty sure unbound was working for you all this time.
Why it's not logging the "level 1" classic hourly "generate keytag..." is puzzling to me. The log system (syslog) fails ? Something else ?

I'm not sure if it was already asked, but :
What's the system you're running pfSense on, bare metal, VM ?
How much RAM ? Disk size ? pfSense 2.7.2, right ?

[RickyBaker]

@Gertjan said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

Leave it to 1.

done, changed it back, here's today's log on Level 2 just in case there's anything useful in it: https://pastebin.com/x4ryj4AB I had an outage at about 630am.

@Gertjan said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

make logs files way bigger then just "500K", for example 2Mbytes each.

sure, where would i set this option? I didn't see it in System->General Setup or Advanced Settings but that could be user error.

@Gertjan said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

From that moment, no more unbound logs

that's super weird right?

@Gertjan said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

The log system (syslog) fails ? Something else ?

genuinely don't know, how would I find out?

@Gertjan said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

I'm not sure if it was already asked, but :
What's the system you're running pfSense on, bare metal, VM ?
How much RAM ? Disk size ?

it's a Dell Poweredge R210 II 1U Server Xeon E3-1240 3.3GHz 8GB 500GB I bought a number of years ago. It is only running pfsense

@Gertjan said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

pfSense 2.7.2, right ?

no 2.7.0. I was unable to update from 2.7.0 to 2.7.2 when you suggested that earlier in the thread. I followed the instructions in this thread i can see you referenced at one point:: https://forum.netgate.com/topic/184670/issue-with-going-from-2-7-0-to-2-7-2 and it def got me closer but I can't seem to complete the upgrade. This is what i always see when i select option 13 when ssh'ed in:

[johnpoz]

@RickyBaker if you can not update to 2.7.2 and you have tried all the common tricks to get past whatever specific issue your running into.. There is always clean install option.

Take a backup of your config, install clean from scratch 2.7.2 an then restore config.. To be honest this shouldn't take much longer than upgrading it from previous version..

I have done this a few times over the years, recently last time was when they started allowing zfs, and then new version changed the layout, etc. and to get the new layout you really needed to just do a clean install.

Reason I am not yet on 24.03 is same reason, need to do clean install.. Because I want to move over to ssd.. And to do that I have to unplug all the cables, open the box install the ssd, etc. etc. And have just not yet gotten around to it. And I know if I just click upgrade, I will put it off until next version of + releases.. And really don't want to do that ;) Maybe next time my wife goes out for a few hours and I am not working will be good time to take the network down ;)

[Gertjan]

@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

sure, where would i set this option? I didn't see it in System->General Setup or Advanced Settings but that could be user error.

The log file size can be set under Status > System Logs > Settings :

I've made mine 4 times bigger.
You can check the max needed size, and free space left.

@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

ow would I find out?

I'm not sure.
I just had a look at my Resolver log (level 1 set) :

as you can see, only a couple of lines since May 8 ...

Only the DNSSEC related "info: generate keytag query _ta-4f66. NULL IN" shows up every xx hours or so.
So, unbound being silent for longer periods is normal after all.

[johnpoz]

How many days are we into this - and you say its a problem for like 10 minutes... And yet to get one actual test of what is happening other than you saying your internet stops working for like 10 minutes.

Other than a ping from your phone to 8.8.8.8, which for all we know used cell data at the time?

And your browser reports NX... for all we know its using doh to resolve and not even asking unbound - do we have some entries in your log of these queries and answers you set, coming from your devices in the logs - you turned on query logging did you not.

edit:
Here I turned on logging, you can see my client asked for www.yahoo.com and got an answer - the no error

Then a I asked for just some gibberish, see the NX response

May 10 09:58:56 	unbound 	49103 	[49103:2] info: 192.168.9.100 www.lsjhfldsjdlfsjdf.com. A IN NXDOMAIN 0.039479 0 126
May 10 09:58:55 	unbound 	49103 	[49103:2] info: 192.168.9.100 www.lsjhfldsjdlfsjdf.com. A IN
May 10 09:58:47 	unbound 	49103 	[49103:2] info: 192.168.9.100 www.yahoo.com. A IN NOERROR 0.379134 0 119
May 10 09:58:47 	unbound 	49103 	[49103:2] info: 192.168.9.100 www.yahoo.com. A IN 

[RickyBaker]

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

Maybe next time my wife goes out for a few hours and I am not working will be good time to take the network down ;)

exactly. I have 2 young kids, if I get the house to myself for an hour, weathering the anxiety of clean installing pfsense isn't the most tantalizing prospect. But i can prioritize if we think it's possible it's causing the issue.

@Gertjan said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

The log file size can be set under Status > System Logs > Settings :

really helpful thank you. i have mirrored your settings. Only the "Disk space currently used by logs" is different (understandably)

@Gertjan said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

So, unbound being silent for longer periods is normal after all.

ok good to know, ty

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

How many days are we into this

yeah I know, and I'm sorry. in my defense, I'm rarely home and it happens rarely. It's only happened to me when I was home twice since i recieved the latest troubleshooting steps and they were, to save you the unsavory details, very inopportune times. I have screenshotted the posts with instructions and will be carrying around a laptop all weekend in hopes of "catching it" thank you for your patience.

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

for all we know its using doh to resolve and not even asking unbound - do we have some entries in your log of these queries and answers you set, coming from your devices in the logs - you turned on query logging did you not.

yeah i'm not so sure what DOH is, but I assume those steps you included will get to the bottom of it, and I hope to have those results before the end of the weekend.
Is this sufficient for turning on queries?

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

Then a I asked for just some gibberish, see the NX response

i see a fair number of NOERROR responses in the log but mostly it seems to be pimarily occupied by my IP cams. I tried to run your test (yahoo.com and slkdjfuiughdil.com) over the vpn but the log doesn't seem to be updating in the GUI. It's currently 11:29 but my log is last showing 11:11 and I just opened yahoo.com. I'll try not over the VPN tonight.
It's been 5 minutes and still no update to the log. I did search for NXDOMAIN and there are 43 instances (of 3000 entries). Here's one:

[johnpoz]

@RickyBaker Those are be expected... That 10.10.10.6 is asking for the ptr (reverse) of 172.17.0.1 - is that an IP on your network, seems like a default sort of docker network to me.

But yeah that would return nx normally because your local dns doesn't have it setup.. But the ptr for say your pfsense IP should answer..

example

                                                                         
; <<>> DiG 9.16.50 <<>> -x 192.168.9.253                                 
;; global options: +cmd                                                  
;; Got answer:                                                           
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58768                
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1  
                                                                         
;; OPT PSEUDOSECTION:                                                    
; EDNS: version: 0, flags:; udp: 1232                                    
;; QUESTION SECTION:                                                     
;253.9.168.192.in-addr.arpa.    IN      PTR                              
                                                                         
;; ANSWER SECTION:                                                       
253.9.168.192.in-addr.arpa. 3600 IN     PTR     sg4860.home.arpa.        
                                                                         
;; Query time: 9 msec                                                    
;; SERVER: 192.168.3.10#53(192.168.3.10)                                 
;; WHEN: Fri May 10 11:43:43 Central Daylight Time 2024                  
;; MSG SIZE  rcvd: 81                                                    

Your logs shouldn't be behind.... Maybe you have time off on pfsense? If that was the case you could be having issues with dnssec validation?

Here I did a query for something that was pretty sure would not be asked for often and in cache www.msn.com because don't go there.. The 192.168.3.10 is my pihole IP.. So client via my dig command pihole, which then asked unbound on pfsense to look it up.

You can see the time in the unbound log matches up with the time on my client. 11:48:02

And I can see that query in my pihole as well - at the same time..

If logs are delayed or time is off in them - then yeah you got other things going on.. Do you have log compression setup?

What for sure would like to validate is your browser is even asking unbound for stuff - so if in your browser go to say www.lsjdfldsjdflsjgibberishwhatever.com you should be able to see that get asked for in unbound, and an NX response - like you saw in my previous screenshot.

And normally - by the time you do it in your browser.. And then go open the resolver log in the pfsense gui, that entry should be listed. There sure shouldn't be minutes of delay before that is in your log, fractions of seconds, maybe a second? But if delayed being seen in the log the timestamp should be pretty freaking exact on..

[RickyBaker]

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

@RickyBaker Those are be expected... That 10.10.10.6 is asking for the ptr (reverse) of 172.17.0.1 - is that an IP on your network, seems like a default sort of docker network to me.

i can't say off the top of my head but 10.10.10.6 is my unraid server and that is where the dockers live so seems likely. There are also a lot from wpad.localdomain from the computer i'm connected with over VPN. here's a couple other ones:


10.10.10.12 is a hardwired PC i'm running wireshark on to capture any shenanigans

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

Your logs shouldn't be behind.... Maybe you have time off on pfsense? If that was the case you could be having issues with dnssec validation?

i even ssh'ed into the /var/log and it hasn't been updated since 11:11 but other logs have been:

very odd indeed. My pfsense time is up to date but i did notice that the last log update seems to oddly coincide with the last config change:

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

If logs are delayed or time is off in them - then yeah you got other things going on.. Do you have log compression setup?

i just removed the compression per @Gertjan helpful suggestions

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

And normally - by the time you do it in your browser.. And then go open the resolver log in the pfsense gui, that entry should be listed. There sure shouldn't be minutes of delay before that is in your log, fractions of seconds, maybe a second? But if delayed being seen in the log the timestamp should be pretty freaking exact on..

it's less than perfect that I'm doing this over VPN. I'll run these tests in a couple hours the minute i get home. But i'm not seeing that for some reason.

[johnpoz]

@RickyBaker said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

hasn't been updated since 11:11 but other logs have been:

You sure anything is even asking unbound anything? If you set to query unbound, and unbound is not showing anything in the logs for it - and you have it set to log queries.. Then there should be log entries being made - IF!! anything is asking unbound anything..

Can see see a simple output from nslookup, that is pretty much anything other than a phone.. And it will show you what dns your talking too.

$ nslookup
Default Server:  pi.hole
Address:  192.168.3.10

If you set a debug you can get all kinds of info, the response who was asked, etc..

$ nslookup
Default Server:  pi.hole
Address:  192.168.3.10

> set debug
> www.msn.com
Server:  pi.hole
Address:  192.168.3.10

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        www.msn.com.home.arpa, type = A, class = IN

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 3, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        www.msn.com.home.arpa, type = AAAA, class = IN

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 4, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 3,  authority records = 0,  additional = 0

    QUESTIONS:
        www.msn.com, type = A, class = IN
    ANSWERS:
    ->  www.msn.com
        canonical name = www-msn-com.a-0003.a-msedge.net
        ttl = 14906 (4 hours 8 mins 26 secs)
    ->  www-msn-com.a-0003.a-msedge.net
        canonical name = a-0003.a-msedge.net
        ttl = 30 (30 secs)
    ->  a-0003.a-msedge.net
        internet address = 204.79.197.203
        ttl = 30 (30 secs)

------------
Non-authoritative answer:
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 5, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 2,  authority records = 1,  additional = 0

    QUESTIONS:
        www.msn.com, type = AAAA, class = IN
    ANSWERS:
    ->  www.msn.com
        canonical name = www-msn-com.a-0003.a-msedge.net
        ttl = 14906 (4 hours 8 mins 26 secs)
    ->  www-msn-com.a-0003.a-msedge.net
        canonical name = a-0003.a-msedge.net
        ttl = 3600 (1 hour)
    AUTHORITY RECORDS:
    ->  a-msedge.net
        ttl = 3600 (1 hour)
        primary name server = ns1.a-msedge.net
        responsible mail addr = msnhst.microsoft.com
        serial  = 2016092901
        refresh = 1800 (30 mins)
        retry   = 900 (15 mins)
        expire  = 2419200 (28 days)
        default TTL = 240 (4 mins)

------------
Name:    a-0003.a-msedge.net
Address:  204.79.197.203
Aliases:  www.msn.com
          www-msn-com.a-0003.a-msedge.net

>

For all we know your clients your having issues with are not even talking to unbound on pfsense - and whatever ns they are talking to your having issues with..

Your typical network with a few devices on it - the dns would be very busy answering queries all the time.. Shoot even when nobody is actually using the device, there is quite often dns queries... If they are asking unbound, and you set it to log queries - then you should be seeing the log file increment like every minute or atleast when there is a query.

If you change it to show seconds... You should be seeing the log change everytime something is written

[23.09.1-RELEASE][admin@sg4860.home.arpa]/var/log: ls -D %H:%M:%S -l resolver.log
-rw-------  1 root wheel 734731 13:48:50 resolver.log
[23.09.1-RELEASE][admin@sg4860.home.arpa]/var/log: ls -D %H:%M:%S -l resolver.log
-rw-------  1 root wheel 735595 13:48:59 resolver.log
[23.09.1-RELEASE][admin@sg4860.home.arpa]/var/log: ls -D %H:%M:%S -l resolver.log
-rw-------  1 root wheel 735822 13:49:02 resolver.log
[23.09.1-RELEASE][admin@sg4860.home.arpa]/var/log: ls -D %H:%M:%S -l resolver.log
-rw-------  1 root wheel 736254 13:49:08 resolver.log
[23.09.1-RELEASE][admin@sg4860.home.arpa]/var/log: ls -D %H:%M:%S -l resolver.log
-rw-------  1 root wheel 736479 13:49:10 resolver.log
[23.09.1-RELEASE][admin@sg4860.home.arpa]/var/log: ls -D %H:%M:%S -l resolver.log
-rw-------  1 root wheel 736479 13:49:10 resolver.log
[23.09.1-RELEASE][admin@sg4860.home.arpa]/var/log: ls -D %H:%M:%S -l resolver.log
-rw-------  1 root wheel 736479 13:49:10 resolver.log
[23.09.1-RELEASE][admin@sg4860.home.arpa]/var/log: ls -D %H:%M:%S -l resolver.log
-rw-------  1 root wheel 736479 13:49:10 resolver.log
[23.09.1-RELEASE][admin@sg4860.home.arpa]/var/log: ls -D %H:%M:%S -l resolver.log
-rw-------  1 root wheel 736713 13:49:21 resolver.log
[23.09.1-RELEASE][admin@sg4860.home.arpa]/var/log: 

If its not changing - then nothing is being log makes the most sense!

[RickyBaker]

@johnpoz the queries I was doing was just searching in the browser. I will run those sample dig commands you posted earlier when I get home and am not over VPN.

[johnpoz]

@RickyBaker and browsers these days LOVE to use doh, and not even ask your local dns.. If your issues were in the browser its quite possible it was talking to whatever it uses for default doh (dns over https).. Browsers love to switch to this without any user intervention at all.. You know the browser people looking out for their idiot users that are too stupid to decide what dns they want to use..

And if they are using our browser, then clearly we should point them to our dns for their own good without telling them we are doing so, or even asking them if we should.

What browser are you using?

https://support.mozilla.org/en-US/kb/firefox-dns-over-https

[RickyBaker]

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

If you set a debug you can get all kinds of info, the response who was asked, etc..

seems bad
When i attempted it on my unraid server the command wasn't found. when i did on pfsense itself and my plex server nslookup just seemed to hang looking for more input.

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

What browser are you using?

chrome but i can't imagine that's better

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

If logs are delayed or time is off in them

My logs were still stuck on 11:11:03 (last config update). i restarted the service and they are updating again.


mine doens't seem to have an answer section like yours
And this I believe is the corresponding failure in the log:

the previous fail in the log was from the browser...

I'm kind of swimming in all the different steps that were needed. Was this helpful? What have I discovered about my devices and their usage of the DNS?

[johnpoz]

@RickyBaker all those are failing.. You see servfail.. So no its never going to work.

Is 10.10.10.1 your actual IP, or are you pointing to the vip of pfblocker?

In your nslookup debug you never even asked for just www.msn.com - you just asked for www.msn.com.localdomain.

Put a . on the end with your nslookup.. You see how mine did search, with my home.arpa but then it dropped that and did my actual query. Your never did that.

What is asking for HTTPS record vs just A record? You see where you see query from 10.10.10.10 its doing both a A record query and a HTTPS query?

You might want to add these two options.. So easier to see what is query and what is reply.. And prob want to add the servfail option so might get some info to why it failed.

log-tag-queryreply: yes
log-servfail: yes

Add those to what you already have in your options box and save and apply.. This can give you more info..

So your not behind a vpn here, pfsense has no vpn client connection? You need to see in your debug for what your actually asking for www.msn.com.localdomain is never going to resolve.. Unless you had created that record locally.

And didn't we go over that 127.0.0.53, you need to know who exactly that is asking.. If you going to do a dig - do a directed query with the @ipaddress...

[RickyBaker]

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

So no its never going to work.

but it DOES SOMETIME work! that's why it's so infuriating

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

Is 10.10.10.1 your actual IP, or are you pointing to the vip of pfblocker?

i don't have pfblocker installed 10.10.10.1 is the ip address of my pfsense router.

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

In your nslookup debug you never even asked for just www.msn.com - you just asked for www.msn.com.localdomain.

I def did not intend to ask for www.msn.com.localdomain and I def did not type the words localdomain when I was running the sample you suggested. I merely enacted the samples you suggested as well as pointing my browser at www.msn.com. I'm guessing the https request is a browser feature that forces https, but that's just conjecture

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

So your not behind a vpn here, pfsense has no vpn client connection? You need to see in your debug for what your actually asking for www.msn.com.localdomain is never going to resolve.. Unless you had created that record locally.

I am not behind a VPN here (intentionally at least) and I have not created a record for msn.com locally (intentionally at least).

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

And didn't we go over that 127.0.0.53, you need to know who exactly that is asking.. If you going to do a dig - do a directed query with the @ipaddress...

yes, i knew there was a detail i forgot in that troubleshooting



i'm not 100% sure of the middle one and i have no idea what 127.0.0.53 is. Is there another test i should run to get more color?

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

log-tag-queryreply: yes
log-servfail: yes

[johnpoz]

@RickyBaker well lets see what happens with logging of servfail detaills. Because clearly its running and resolved your pfsense.localdomain name from from 10.10.10.1 when you did your nslookup.

Another thing I notice on your servfail your not getting the ede back..

You should be able to enable that with ede: yes in your custom box

See here

[SteveITS]

@RickyBaker

127.0.0.53

Your screenshot shows Ubuntu, that’s the local DNS resolver.
https://unix.stackexchange.com/questions/612416/why-does-etc-resolv-conf-point-at-127-0-0-53

[RickyBaker]

@SteveITS said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

Your screenshot shows Ubuntu, that’s the local DNS resolver.

does this mean that my plex server isn't using pfsense for dns resolving?

@johnpoz said in DNS_PROBE_FINISHED_NXDOMAIN sporadically for anywhere from 30secs to 10min. works flawlessly at all other times:

well lets see what happens with logging of servfail detaills.

tbc you want me to simply rerun those dig/nslookup sample tests you listed earlier right?

DNSKEY MIssing? also apparently way longer to complete




"unfortunately" i was not experiencing an outage at this time

[johnpoz]

@RickyBaker there you go - some actual useful info

So your having some sort of issue with dnssec.. I would expect that to fail with that query - that fqdn is test fqdn for making sure dnssec is working.. But we are seeing the servfail reason..

So now when normal queries fail we might get to the bottom of why your getting servfail vs an answer to what you ask for.