Slow DNS after 22.05
-
@johnpoz Ok, Done. The option needs a better info text as it is it seems to imply that it needs to be on to support any DNSSEC at all.
-
@lohphat I would agree with you, should really have a note under it - If your going to forward do not set this or something like that.
-
Still getting filterdns errors with DNSSEC unchecked:
Jul 9 15:23:01 filterdns 82159 failed to resolve host steamstatic.com will retry later again. Jul 9 15:23:01 filterdns 82159 failed to resolve host steamcontent.com will retry later again. Jul 9 15:23:01 filterdns 82159 failed to resolve host steamusercontent.com will retry later again. Jul 9 15:18:01 filterdns 82159 failed to resolve host steamstatic.com will retry later again. Jul 9 15:18:01 filterdns 82159 failed to resolve host steamcontent.com will retry later again. -
@lohphat thats not a unbound problem
;; QUESTION SECTION: ;steamstatic.com. IN A ;; AUTHORITY SECTION: steamstatic.com. 1344 IN SOA ns1.valvesoftware.com. admin.valvesoftware.com. 2022041804 3600 900 24192 00 3600 ;; Query time: 84 msec ;; SERVER: 9.9.9.9#53(9.9.9.9) ;; WHEN: Sat Jul 09 14:31:06 Central Daylight Time 2022 ;; MSG SIZE rcvd: 104$ dig @9.9.9.9 steamusercontent.com ; <<>> DiG 9.16.30 <<>> @9.9.9.9 steamusercontent.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47670 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;steamusercontent.com. IN A ;; AUTHORITY SECTION: steamusercontent.com. 3600 IN SOA ns1.valvesoftware.com. admin.valvesoftware.com. 2022010300 3600 900 24192 00 3600 ;; Query time: 68 msec ;; SERVER: 9.9.9.9#53(9.9.9.9) ;; WHEN: Sat Jul 09 14:32:16 Central Daylight Time 2022 ;; MSG SIZE rcvd: 109I get same results trying to just resolve.. they seem to be having an issue.. Or that isn't meant to resolve in the first place.
-
@johnpoz said in Slow DNS after 22.05:
thats not a unbound problem
I get same results trying to just resolve.. they seem to be having an issue.. Or that isn't meant to resolve in the first place.
What's even stranger, is that the steam.exe client isn't running and it's still throwing the DNS errors hours after the client exited.
I'm still getting occasional failed lookups where I have to force reload a page for the domain to resolve.
Something is still broken.
-
@lohphat said in Slow DNS after 22.05:
force reload a page for the domain to resolve.
You sure your browser isn't doing doh? If you feel something isn't resolving - then troubleshoot it vs just thinking X is the problem. If something is taking long to resolve - why?
Your trying to access www.somedomain.tld - you sure you browser even asked your dns for that? If so why did it not resolve? Where is the delay? Your forwarding - maybe they just suck at resolving, or answering.. Maybe they are having the problem?
Did you restart the browser? Maybe its having an issue with its cache it keeps.
Vs just thinking its something wrong with unbound, find out where the trouble is.. If you ask unbound for xyz, and it goes and asks abc for xyz - did it not get an answer - how long did it take for unbound to ask abc for xyz, after you asked it?
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.03 | Lab VMs 2.7.2, 24.03 -
@johnpoz said in Slow DNS after 22.05:
@lohphat said in Slow DNS after 22.05:
force reload a page for the domain to resolve.
You sure your browser isn't doing doh? If you feel something isn't resolving - then troubleshoot it vs just thinking X is the problem. If something is taking long to resolve - why?
Some of us experiencing this problem have done a bit of testing, including from the command line. The resolution problem is not specific to browsing, it's an intermittent failure of resolution.
-
@jax said in Slow DNS after 22.05:
it's an intermittent failure of resolution.
This screams unbound restarting.. Is it?
[22.05-RELEASE][admin@sg4860.local.lan]/: unbound-control -c /var/unbound/unbound.conf status version: 1.15.0 verbosity: 1 threads: 4 modules: 2 [ validator iterator ] uptime: 457693 seconds options: control(ssl) unbound (pid 87400) is running... [22.05-RELEASE][admin@sg4860.local.lan]/:457k seconds up - whats that like 5 days? Only reason its prob not longer is testing something for some thread here, etc.
-
@johnpoz I don't know enough about these mechanisms to respond to your comment. I'd have to go hit the man pages and study more. Unless you can lay this out for me.
-
@jax look in your log - is unbound restarting, if it is - hard to resolve something if its not actually running or just started up couple of ms ago, etc.
You can validate how long its been up with that command..
Again to the root of the problem, if your having issues - why.. Unbound just doesn't say eh I don't feel like resolving that right now ;)
So either it is having a hard time finding what you asked for, or maybe it in the middle of restart why that specific query failed, etc.
Its a long running issue - register dhcp, unbound restarts - this can be quite often depending on the number of dhcp clients, the length of the lease, etc. When unbound restarts, cache is lost, etc
With pfblocker - the length of time for unbound to restart can be much longer than normal, etc.
If you ask unbound for www.domain.tld - and you don't get the answer you want - the question is why? There is almost always a logical explanation to why..
-
@johnpoz For one thing the behavior is new since 22.01 to 22.05 and it's happening with common websites using different apps, not just FF.
I have DoH/DoT disabled in both 22.01 and 22.05 but the incidence of failed lookups since the upgrade is consistent over the last two days.
-
@lohphat said in Slow DNS after 22.05:
is new since 22.01 to 22.05
On 22.05 went from 22.01 - not seeing any such issue.. Have had zero issues resolving stuff.
If your having an issue - the logical thing to do is is troubleshoot why, not oh something wrong with version X vs Y.. Maybe there is nothing wrong with Y, but some other variable has been introduced. Like maybe whatever you doing now, unbound is taking longer to restart - maybe on your system it use to restart in like .3 seconds, and now its taking 30.. So before you never noticed, but now you do.
-
@johnpoz As soon as I get I lookup error, I go and look at logs and find nothing out of the ordinary. I have DHCP registration disabled as I know it restarts unbound and with pfB-dev that's a non-starter.
I just can't find a smoking gun yet other than it's still happening and others are reporting it too.
-
In any case, things are currently working for me as follows:
- DNS Resolver enabled
- DNS Forwarder disabled
- DNS Server Override checked "Allow"
- DNS Servers set to 8.8.8.8 and 8.8.4.4
And not experiencing any slowness nor intermittent failures.
-
@jax so your pointing your clients to 8.8.8.8 ? Doesn't matter what dns you put into pfsense general tab, or allow from dhcp on wan, etc..
If unbound is running, dhcp would point to pfsense IP for dns (unless you told it something else in the dhcp server dns section) - unbound would resolve.. 8.8.8.8 would never come into play, other than pfsense itself looking up something if unbound stop working..
Clients would always use unbound, and never use 8.8.8.8, etc.. Those would only be for pfsense itself, not clients asking unbound..
You not having any issues - unbound working how its set to work out of the box (resolver).. So how is dns slow after 22.05??
Here is the thing, out of the box unbound is a resolver.. What settings you have in general have zero to do with unbound, and clients asking unbound on pfsense lan IP, etc.
Any servers you have in general are only for pfsense own use, if unbound is off or failing, etc. You know checking for an update, checking package list, etc. Zero to do with clients on your network asking unbound to lookup www.google.com
The only time servers you have listed in general could ever come into play for clients, is if you have unbound in forwarder mode.
-
Hey!
Since a few month I´m using a Netgate 3100 in my home network. I´ve had no issues with the Firewall itself or with the DNS Resolver on previous versions, except that the domain override hasn´t really worked.
With installing the Ver. 22.05, and no other changes were mady by the configuration, I also got problems to load webpages. It takes some seconds to react on the client, but then it will load normaly. My first thought: DNS problem!
I´ve been testing the on or other thing reading in this thread in the DNS Resolver and in the General Tab. Sometimes it feels better for the moment, but after a little time the behaviour is again like before. I got this on all devices in my network, so it doesn´t matter if it is a desktop computer (tested with Windows and Mac OSX an different webbrowser), or a mobile device (Smartphones and Tablets with iOS and Android). Without telling my wife I asked her if she figured out something about the internet, she also told me about "slow websites".For testing I´ve installed a DNS Resolver on my Synology NAS and set it up to the clients by the DHCP Settings. The clients all got normal behaviour with a quick reaction by looking up for DNS and loading the content.
In my opinion the problem have to be something with the Firewall, the DNS Resolver and the Version 22.05, because it just came up on the same day of the update. Maybe it´s, like someone supposed in the thread earlier, really only on some Hardware versions like the ones with the ARM - Processor.
Greetings,
Markus
PS: I hope I was able to tell my thoughts rightly, because my native speech is german.
-
@lohphat said in Slow DNS after 22.05:
I'm getting a lot of these in the DNS Resolver log with pfBlockerNG-devel uninstalled, DNS forwarding and DNSSEC enabled:
Jul 9 12:43:02 filterdns 82159 failed to resolve host steamusercontent.com will retry later again. Jul 9 12:43:02 filterdns 82159 failed to resolve host steamstatic.com will retry later again. Jul 9 12:43:02 filterdns 82159 failed to resolve host steamcontent.com will retry later again.Why did you ask 'filterdns' to pre resolve these domains ?
Take one for yourself :
[22.05-RELEASE][admin@pfSense.mypfsense.net]/root: host steamcontent.com steamcontent.com mail is handled by 10 us-smtp-inbound-2.mimecast.com. steamcontent.com mail is handled by 10 us-smtp-inbound-1.mimecast.com.You saw the word 'smtp' in the domain name ?
These domain names point to a host that is supposed to be a mail server. No web, no other service.
Are your firewall filtering using aliases that allow/forbid these hosts ?
Are you sending a lot of mail to these guys, using their mail facilities ?
smtp server nearly always have very static IP, as dynamic IP for a smtp server is a pure nightmare.Also, these domain names imply that they are present on the domain name server "mimecast.com" : that's a casting DNS server so very accessible.
And still unbound has troubles resolving it ??
Your issue goes deeper as a 'filterdns' issue : it a DNS issue.
I advice you to stays away from any 'user' (== you) added DNS settings. Use the dafault Netgate DNS settings, and you'll be fine.Keep in mind : 8.8.8.8 is only needed if you have to give
them your DNS requests ;)
Internet, DNS, etc, was working just fine even before 8.8.8.8 (and 1.1.1.1 etc etc) existed.No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
This post is deleted! -
P pajinha referenced this topic on
-
In drilling down to where the log errors are coming from, they are part of a firewall alias list used in a single f/w rule which is disabled.
My new question is why the alias being resolved used while the test rule I use the alias in, isn't being used at all.
I assume it's to support dynamic rules which may activate at any time. I removed the FQDN names from the aliases to remove them from generating log errors.
-
It happened again. DNS forwarding off and DNS 'died' within 24 hours in a way which mostly affects CDN content (i.e. YouTube). Nothing interesting in the logs.
Enabling DNS forwarding apparently solves the problem. pfBlocker-devel doesn't seem to be part of the issue (yet).
