Poor performance with 2.4.1
-
Resolver works fine.
I just tried again and resolver does not work. Forwarder does. I have been using resolver almost since I started using pfSense 1.5 years ago but it now fails.
-
In my case, I think its something in the network at this one place giving unbound trouble. I haven't seen this anywhere else. Since in my case, its just for testing I didn't worry about it much. However in this 1 location both opnsense and pfsense had resolver issues, so I turned it off.
Went with dnsmasq on opnsense and forwarder on pfsense and suddenly it all worked. I think its something strange going on with the machine hosting the VMs in my case because this only happened in one place.
The only things odd about this install is its in vmware and the IP on the WAN is private. Like I said… For testing only, so no public on this one. Other than that, its vanilla as can be.
-
No problems with resolver here..
Prob timeouts with its ULA address.. Because your RA failed and its using your "backup" plan of ULA addresses..
How about some info on how its failing.. So you do a query for www.domainx.com and it doesn't walk down from roots? You looked in the cache of unbound for how it would look up this domain, what it has in its cache, etc. You sniffed on wan and don't see this, but there is nothing in the logs?
example
unbound-control -c /var/unbound/unbound.conf lookup forum.pfsense.org The following name servers are used for lookup of forum.pfsense.org. ;rrset 1279 2 0 7 3 pfsense.org. 1279 IN NS ns2.netgate.com. pfsense.org. 1279 IN NS ns1.netgate.com. ;rrset 1279 1 0 8 0 ns1.netgate.com. 1279 IN A 192.207.126.6 ;rrset 84078 1 0 1 0 ns1.netgate.com. 170478 IN AAAA 2610:160:11:3::6 ;rrset 1279 1 0 8 0 ns2.netgate.com. 1279 IN A 162.208.119.38 ;rrset 84078 1 0 1 0 ns2.netgate.com. 170478 IN AAAA 2610:1c1:3::108 Delegation with 2 names, of which 0 can be examined to query further addresses. It provides 4 IP addresses. 2610:1c1:3::108 not in infra cache. 162.208.119.38 rto 328 msec, ttl 840, ping 4 var 81 rtt 328, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 2610:160:11:3::6 rto 376 msec, ttl 840, ping 0 var 94 rtt 376, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. 192.207.126.6 rto 347 msec, ttl 840, ping 7 var 85 rtt 347, tA 0, tAAAA 0, tother 0, EDNS 0 probed. [2.4.1-RELEASE][root@pfsense.local.lan]/root:
Is there anything in the log for unbound? Did you up the verbosity of what it logs, etc..
Resolver does not work… Like telling your mechanic - car is broke..
-
For me, I wasn't all that worried because I was more interested in stepping through the menues and comparing menues, options, features of two firewall distros than anything. I need to move several older machines to something else when the AES-NI requirement kicks in.
I wonder what unbound would do if you turned off DNSSEC/hardening? I'm going to try because I suspect for me it could be an ISP issue.
-
I tried changing quite a few things in unbound but nothing works. This isn't specific to pfsense either. For these test VMs, I'm fine with forwarder. Done fooling with it.
-
"Done fooling with it."
Well from what you posted that's all you were doing with it anyway. I see no info from you either on what is not actually working? Nothing from logs, nothing from how it would look up anything. No checking to see if actually sends query to roots, and then walks down the tree, etc..
Does a dig +trace work from a client.. This would simulate walking down tree like unbound would do, etc.
example - I got rid of the dnssec info so it was cleaner looking trace
> dig forum.pfsense.org +trace +nodnssec ; <<>> DiG 9.11.2 <<>> forum.pfsense.org +trace +nodnssec ;; global options: +cmd . 502339 IN NS e.root-servers.net. . 502339 IN NS f.root-servers.net. . 502339 IN NS l.root-servers.net. . 502339 IN NS b.root-servers.net. . 502339 IN NS i.root-servers.net. . 502339 IN NS k.root-servers.net. . 502339 IN NS m.root-servers.net. . 502339 IN NS g.root-servers.net. . 502339 IN NS a.root-servers.net. . 502339 IN NS j.root-servers.net. . 502339 IN NS d.root-servers.net. . 502339 IN NS c.root-servers.net. . 502339 IN NS h.root-servers.net. ;; Received 239 bytes from 192.168.3.10#53(192.168.3.10) in 3 ms org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS b2.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. ;; Received 448 bytes from 192.203.230.10#53(e.root-servers.net) in 14 ms pfsense.org. 86400 IN NS ns1.netgate.com. pfsense.org. 86400 IN NS ns2.netgate.com. ;; Received 93 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 33 ms forum.pfsense.org. 300 IN A 208.123.73.18 pfsense.org. 300 IN NS ns1.netgate.com. pfsense.org. 300 IN NS ns2.netgate.com. ;; Received 141 bytes from 162.208.119.38#53(ns2.netgate.com) in 37 ms
I don't get this thought process… I clicked some stuff.. Not working.. Well just use forwarder then... Do you not want to know why something is not working? Could be something completely broken in your firewall causing the problem.. Could be your isp is intercepting your dns traffic, and while you think your forwarding to X.. Your really just getting whatever your ISP wants to send you.. Some simple testing would tell you why your having a problem with resolving.. Maybe your isp just blocks outbound to 53 and only allows their NS or specific NS, etc.??
-
I think its something strange going on with the machine hosting the VMs in my case because this only happened in one place.
I'm not running pfSense in a VM. It's a bare metal install on a computer.
-
Resolver does not work… Like telling your mechanic - car is broke..
Well, prior to 2.4.1, resolver worked fine but failed immediately on the upgrade and I hadn't changed anything else. Sure sounds like a resolver issue to me.
I don't get this thought process… I clicked some stuff.. Not working.. Well just use forwarder then... Do you not want to know why something is not working? Could be something completely broken in your firewall causing the problem.. Could be your isp is intercepting your dns traffic, and while you think your forwarding to X.
While I would like to know what caused the problem and how to fix it, having a working network is more important. Switching to forwarder does that. I think it's extremely unlikely that my ISP would change things at the precise time I upgraded to 2.4.1.
-
Yep - I'm just mashing random buttons on this thing… Like a monkey with a keyboard.
I will figure it out eventually. It isn't anything simple. -
; <<>> DiG 9.11.2 <<>> forum.pfsense.org +trace +nodnssec
;; global options: +cmd
;; connection timed out; no servers could be reachedWhen I find something helpful I will post it. This just isn't informative. I'm still trying to get past "it brokted"
I'm wondering if the ISP can somehow break this? -
Just as another data point, I upgraded from 2.4.1 to 2.4.2 a few days ago and started noticing these symptoms.
My connection is fine, I'm able to ping the gateway and monitoring shows no degradation in quality (no packet drops).
DNS lookups using the resolver however, will occasionally fail for many seconds before returning a result. This includes internal lookups (static entries and DHCP lookups).
I switched to the forwarder and everything seems fine.
-
I think that ISPs can impact the reliability of resolver. I don't really care what anyone thinks about that.
I think some ISPs are living in the 80s and 90s and just havent dropped some bad practices, like blocking all dns other than their own.