Slow DNS after 22.05
-
@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).
-
@lohphat said in Slow DNS after 22.05:
DNS forwarding off and DNS 'died'
And what specific did not resolve? Did you do a dig from your client, did you do a dig +trace to see where the resolving was failing?
When you have a dns problem, you need to troubleshoot what exactly is failing.. Like your above entries - that just do not resolve, issue with the parent dns, etc.
-
@johnpoz Can you recommend a log level setting other than Level 3 to catch the failures?
-
@lohphat log might not catch the failure.. Depending on what the failure is - getting back a nx isn't a failure, etc.
What specific fqdn did not resolve - what did you get back from unbound, was it refused was it nx, was it a timeout?
Saying dns didn't work is like telling the mechanic your car is broke. Without details - have no clue to what is wrong or could be wrong.
You can for sure up the log level - also you can have it log queries and replies with
log-queries: yes
log-replies: yesIn the option box, etc.
But some actual details what you specific asked for, what was the response? And then doing a dig +trace is prob going to tell you more of what is failing then in the log..
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.11 | Lab VMs 2.8, 24.11 -
@johnpoz said in Slow DNS after 22.05:
@lohphat log might not catch the failure.. Depending on what the failure is - getting back a nx isn't a failure, etc.
What specific fqdn did not resolve - what did you get back from unbound, was it refused was it nx, was it a timeout?
That's the problem, I don't have a specific FQDN but I have cases where YT thumbnails don't load in a browser on my PC or iPad or on my Roku on my TV -- other similar sites which use distributed content like linkedin.com also fail at the same time. Since the content is embedded, getting the FQDN is more of a challenge.
You can for sure up the log level - also you can have it log queries and replies with
log-queries: yes
log-replies: yesIn the option box, etc.
Thanks! Will try this.
But some actual details what you specific asked for, what was the response? And then doing a dig +trace is prob going to tell you more of what is failing then in the log..
Once I can do that I will.
-
Here we go!
One second duckduckgo.com is resolved and the SAME second it's not.
Note: Not in forwarding mode.
Jul 11 12:00:23 unbound 85415 [85415:0] info: 192.168.0.114 improving.duckduckgo.com. A IN SERVFAIL 0.015555 0 42 Jul 11 12:00:23 unbound 85415 [85415:1] info: 192.168.0.114 duckduckgo.com. A IN SERVFAIL 0.010721 0 32 Jul 11 12:00:23 unbound 85415 [85415:0] info: 192.168.0.114 external-content.duckduckgo.com. A IN SERVFAIL 0.011008 0 49 Jul 11 12:00:23 unbound 85415 [85415:1] info: 192.168.0.114 improving.duckduckgo.com. AAAA IN NOERROR 0.000000 1 121 Jul 11 12:00:23 unbound 85415 [85415:0] info: 192.168.0.114 external-content.duckduckgo.com. AAAA IN NOERROR 0.000000 1 114 Jul 11 12:00:23 unbound 85415 [85415:1] info: 192.168.0.114 improving.duckduckgo.com. AAAA IN Jul 11 12:00:23 unbound 85415 [85415:1] info: 192.168.0.114 duckduckgo.com. AAAA IN NOERROR 0.000000 1 97 Jul 11 12:00:23 unbound 85415 [85415:0] info: 192.168.0.114 external-content.duckduckgo.com. AAAA IN Jul 11 12:00:23 unbound 85415 [85415:0] info: 192.168.0.114 improving.duckduckgo.com. A IN Jul 11 12:00:23 unbound 85415 [85415:1] info: 192.168.0.114 duckduckgo.com. AAAA IN -
Even more frustrating:
Jul 11 12:06:13 unbound 85415 [85415:1] info: 192.168.0.114 duckduckgo.com. AAAA IN SERVFAIL 0.002623 0 32 Jul 11 12:06:13 unbound 85415 [85415:0] info: 192.168.0.114 duckduckgo.com. A IN SERVFAIL 0.002413 0 32 Jul 11 12:06:13 unbound 85415 [85415:1] info: 192.168.0.114 duckduckgo.com. AAAA IN Jul 11 12:06:13 unbound 85415 [85415:0] info: 192.168.0.114 duckduckgo.com. A INBut when I do a DNS query in pfsense it resolves while my client is getting can't resolve errors. Presumably due to negative caching.
Results Result Record type 52.149.246.39 A Timings Name server Query time 127.0.0.1 4 msec 9.9.9.9 15 msec 149.112.112.112 13 msec 2620:fe::fe 13 msec 2620:fe::9 14 msec -
[22.05-RELEASE][root@pfSense.localdomain]/root: dig duckduckgo.com ; <<>> DiG 9.16.26 <<>> duckduckgo.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19694 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;duckduckgo.com. IN A ;; Query time: 5 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jul 11 12:12:35 EDT 2022 ;; MSG SIZE rcvd: 43[22.05-RELEASE][root@pfSense.localdomain]/root: dig +trace duckduckgo.com ; <<>> DiG 9.16.26 <<>> +trace duckduckgo.com ;; global options: +cmd . 81871 IN NS c.root-servers.net. . 81871 IN NS g.root-servers.net. . 81871 IN NS a.root-servers.net. . 81871 IN NS d.root-servers.net. . 81871 IN NS i.root-servers.net. . 81871 IN NS l.root-servers.net. . 81871 IN NS m.root-servers.net. . 81871 IN NS e.root-servers.net. . 81871 IN NS b.root-servers.net. . 81871 IN NS h.root-servers.net. . 81871 IN NS f.root-servers.net. . 81871 IN NS k.root-servers.net. . 81871 IN NS j.root-servers.net. . 81871 IN RRSIG NS 8 0 518400 20220724050000 20220711040000 20826 . FZHYJQfCqUyzGmFm5rX40WBtbYNLRihMeE+ShEnhLJwV7XgAHidoNfh4 XAYL1BmOmBkMpZoffPF+BZ3/E4qQRPv9oMMd+uvEjAXoHMb6kI/2CMa4 ejTDy28Zr1YacUO70dk3bPF9TisNotaCzJFa1SOZ2a9WXDgzJe31DAyR rxchvGHz1/cLryangX9bgKWqu7MtE4TaXVpxYZM/L0eeUaxw1q15GXiG mM39zc+UHjA3TwjvUS7/7+6X9nvMbhDBNUUCxPMIKMMmoUUptBZ56HKU 1wQYf/iG+0XkZnH8hPVLZPoaj7EJQMbgpaGrHamDkprtmg7mRwRUPhgD jAA9kQ== ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 3 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. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20220724050000 20220711040000 20826 . T1grSYw69rtfnUYr5D/ZqBqWYSDFbiIvUaPHYidsz6jvuEgEZUDKOmPN pjsHj7hW4HuLjfa5aAfnFS0oPuWvqiz8VfYjO4DIak/XiLOwwXhzQJBW iMRiKc++RUpEoHGZDDi8ZqpOKyM6prr6jST7N1Q01OjczwYF2iWKCRgV MA77kCdPpNbMZUuOaYlWqPwTt/DS0TUz9iaVdSR2mwNwNmxzhXyiDn0q erRTago7WSxUXWRi3yulg12Lz6vLQp4NAOD4Yj9T6jcdfVhk7j9RyKyG Awv6WhOLIv7LJheQ04jjK0dsWF1Jj6HigmU6C9I+qeBEPAKOksf1/is4 n5UsYg== ;; Received 1174 bytes from 2001:500:9f::42#53(l.root-servers.net) in 16 ms duckduckgo.com. 172800 IN NS dns1.p05.nsone.net. duckduckgo.com. 172800 IN NS dns2.p05.nsone.net. duckduckgo.com. 172800 IN NS dns3.p05.nsone.net. duckduckgo.com. 172800 IN NS dns4.p05.nsone.net. duckduckgo.com. 172800 IN NS ns04.quack-dns.com. duckduckgo.com. 172800 IN NS ns03.quack-dns.com. duckduckgo.com. 172800 IN NS ns02.quack-dns.com. duckduckgo.com. 172800 IN NS ns01.quack-dns.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20220718042400 20220711031400 37269 com. OqHMj8b2ZtnK/yLvlzh6HoFolzEZKjLjE2LBlMvL/9jNZsDvr9Mw1ssx HgckOUjba4gjVFDqpSKmyakdWtDsb0HaR13wvk7B2zphtOpqtY+R3G/6 IIjyMxwtxbdwCBF2isSyWisxdm0DVNfTtr6dDrB6xf7M5SDLXK+pweCy BwFoZ3vjutI7JQ19jEqjdpSL21ngvT/XV+tBJunhefJuOQ== BN1F9K6MRAK5QR46K4F5GU46EBVE2B1H.com. 86400 IN NSEC3 1 1 0 - BN1G255EFBBQHJ10333PK7TVU3NBC6RJ NS DS RRSIG BN1F9K6MRAK5QR46K4F5GU46EBVE2B1H.com. 86400 IN RRSIG NSEC3 8 2 86400 20220716050918 20220709035918 37269 com. tTFP0jB/KOhBDfPxWqmTqiR2bIzdS3j74Nj6YRAiBhoAmpCPSGkVXOq7 hxMHQhdBts2Qg9+pdzdcnhE1N4RG4hyXBQSqgYgqjK6eaceVsu27AKWh F0T0YWVR9xL6UFCYs9y2EeGe6vh1DjQ7gbDfBSJn0N+RPSx15pfaPw9R EVDRnh4AWbEKDFTRbdzd11eCUhhxVEAxy+Z0oUbl/wUkvQ== ;; Received 943 bytes from 192.52.178.30#53(k.gtld-servers.net) in 85 ms duckduckgo.com. 200 IN A 52.149.246.39 ;; Received 59 bytes from 198.51.45.5#53(dns2.p05.nsone.net) in 17 ms
