Unbound Resolver - failed to resolve host
-
@maverickws said in Unbound Resolver - failed to resolve host:
Actually let me put my DNS Resolver config here.
Would you mind also posting the settings you have on the General Settings page view as well?
Also I don't remember seeing in any of the threads you are active in for this subject, if you are running pfBlockerNG or not. Are you?
I like @johnpoz has mentioned in some of the other threads. have never had a problem with DNS Resolver, hanging, not resolving etc but my DNS setup is also a bit unique.
Thanks
-
@jrey another good question would be if registering dhcp.. When unbound restarts constantly you could have all kinds of issues that seem odd. Even if the restart is almost instant, it still flushes cache for everything..
I am not on 23.09 yet, so its not out of the realm of possibility that something odd with unbound with 23.09, but has even changed versions - yup quick look and "Changed: Update Unbound to 1.18.0"
I will most likely update to 23.09 this weekend.. So will be able to see if start having the same sort of issues.. But I tend to lean not on that.. If there was something inherently wrong with unbound 1.18 I would think it would be big news.. I was looking over the release notes since 1.19 just dropped the yesterday, and nothing jumped out to me any sort of bug fix or anything that would cause any sort of major problems with 1.18 resolving stuff.
-
@maverickws said in Unbound Resolver - failed to resolve host:
Today I couldn't make it into login.live.com
[23.09-RELEASE][admin@pfs-fw]/root: date && ping login.live.com
Thu Nov 9 13:37:28 WET 2023
ping: Unknown host
[23.09-RELEASE][admin@pfs-fw]/root: date && ping login.live.com
Thu Nov 9 13:40:27 WET 2023
PING www.tm.v4.a.prd.aadg.akadns.net (20.190.177.23): 56 data bytes
64 bytes from 20.190.177.23: icmp_seq=0 ttl=115 time=29.112 ms
^C
--- www.tm.v4.a.prd.aadg.akadns.net ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 29.112/29.112/29.112/0.000 msIf I was pinging a host like "login.live.com" and "Unknown host" came back, I would :
Saying to myself : "well, why not - it even happened to facebook ones"
But then I would look up in my "what's unbound actually doing" list (the pfBlockerng dns_reply.log is great for this) and look up what happened with the question "what is the A of "login.live.com" ?
I'm resolving, so, if there was no answer, I would know that all ( !! ) the domain name servers Microsoft were down. I would be calling right away fox fox.news or msnbc (take your pick) and you'll, and Microsoft, will be hot news.
The 13 DNS root servers can't be down, as that means that the "Internet is down" for everybody.Or are you forwarding ? Great. call them.
I do presume that you took care of all the unbound settings, and that you know it isn't restarting all the time, as during a restart, DNS request are lost.
If you've done your home work, your unbound restart not that often. So here for what happens on my pfSense. Last week looks a bit messy : was was putting 23.09 trough its passes.
Know example about how not to do thing : check this one :
and you have a first class ticket for DNS-h*ll.
Or : the next best : ask pfBlockerng to update all the DNSBL feeds every hour or so.
Or : your LAN(s) and/or WAN(s) interfaces disconnect/re connect often.
Etc.Still, " login.live.com" not resolving, I would tell me something is not done very well.
Keep always in mind that the close to perfect solution isn't far : fire the current admin, take a new one, reset pfSense to default, add/change only the admin password, do not add anything (anything in big red capitals here) and .... no more DNS issues
( if still issues, in this order : change ISP, change government, change country ) -
I am on 23.09 but did not have a problem on prior versions either.
I can't comment on the impact of DHCP, and restarting Resolver. I do have DHCP in the network. DHCP is NOT handled on the NetGate.
My DNS Resolver on the Netgate, almost never restarts. Except on Reboot or when I tell it to. pfBlocker does not restart all the time either (normal IP type lists will not cause a restart, as we know they change load Alias and impact the rules not the resolver. DNSBL list updates and only when there is an update, that will cause a restart)Certainly from the point of view unbound just starting/restarting I can often go days,
The 6th and 7th are a result of me (rebooting)
the 9th is a result of the DNSBL getting and update so of course the is expected, and is usually the most common reason for a restart)
- and before anyone gets too excited about the :30 time stamp, I have my pfBlocker cron job offset by 30 minutes, so any schedule updates run 30 minute mark not the top of the hour 00. ie it didn't take 30:43 to update it took 43 seconds. LOL
-
Ok, your unbound is doing fine - is not the issue.
Because you have pfBlockerng : go here :
now clear your local - on your device - DNS cache.
Stop unbound - and start it : pfSense (unbound) DNS cache gone.Goto live.com, and then have a look at the logs (refresh the page).
Did it handle the request for live.com ? -
@Gertjan said in Unbound Resolver - failed to resolve host:
Ok, your unbound is doing fine - is not the issue.
You seem confused by responding specifically to me. I'm not the one with the issue.
No issues with DNS Resolver or pfBlocker, or anything else here on the network side for that matter.
The original OP @maverickws seems to have a problem, I'm just trying to put another set of eyes on his issue.
Cheers
-
Ok so lots of interactions all of the sudden, let me go over this and try to get all the questions:
To take one off the table, yes I have pfBlockerNG-devel running.
@jrey asking for the general settings config
@Gertjan
Yeah I'm calling Fox or MSNBC saying "freaking unbound resolver failing and no one seems to actually address the issue" that's what I'd be saying right?
Cause apparently the thing is so fragile an hiccup blows it away.
Anyway, aboutdns_reply.logthat's empty[23.09-RELEASE][admin@pfs-fw]/root: cat /var/log/pfblockerng/dns_reply.log [23.09-RELEASE][admin@pfs-fw]/root:No, I'm not forwarding. This has been clear like water from the start.
And about the DHCP Registration option, that got me going around for a while, but the news here are: If you enable KEA DHCP backend, that option goes away. It was not ticked anyway.I don't have flapping interfaces,
My pfBlockerNG config already checks for DNSBL feeds every hour or so. (EDIT: checked, I have 4 DNSBL lists, three update every 2h, one every 4h)
I have dual-WAN. I'm not commenting on the "change country bit" because its just starting to get ridiculous like some parts of your comments I didn't really appreciate, but moving on...@johnpoz
here's the start/stop log entries for unbound for the last three days
And:
[23.09-RELEASE][admin@pfs-fw]/root: unbound-control -c /var/unbound/unbound.conf lookup . The following name servers are used for lookup of . ;rrset 31141 13 1 11 5 . 31141 IN NS a.root-servers.net. . 31141 IN NS b.root-servers.net. . 31141 IN NS c.root-servers.net. . 31141 IN NS d.root-servers.net. . 31141 IN NS e.root-servers.net. . 31141 IN NS f.root-servers.net. . 31141 IN NS g.root-servers.net. . 31141 IN NS h.root-servers.net. . 31141 IN NS i.root-servers.net. . 31141 IN NS j.root-servers.net. . 31141 IN NS k.root-servers.net. . 31141 IN NS l.root-servers.net. . 31141 IN NS m.root-servers.net. . 31141 IN RRSIG NS 8 0 518400 20231121210000 20231108200000 46780 . Dez3g0tBHaJpwK0mSw4kEhBGlITDUeu4+IDZ3Wtjp4tgc+ZfaQlqVcsbUWw+bjkWkFz81UGpl6Ru+JZQUT3Tg3K2h14KUzOexBWPoiOH4QnjU3QiVnkPQjW7y5ywx7AtsDHYH1L+fwf6UXu87z+xBQ9KwMzOMTQ9sk0qJDZV4+4pFH64xY8AmsxFVaKjP+RF3TiAnpQ8Re+CdsP5mxGeTlPqjrslb0KGKFVYyJ54zZ9mIOHAxM1BTMKN9IpEWSTtNHltCzjRUzN3y2BqsZOTUXeIkKAsKqeSEr458sgvGY2qUZr2/msO+tDnlUx7ccVKmj1fjNN05g9GlehxgYal5w== ;{id = 46780} ;rrset 81667 1 0 8 3 m.root-servers.net. 81667 IN A 202.12.27.33 ;rrset 31141 1 0 3 3 m.root-servers.net. 31141 IN AAAA 2001:dc3::35 ;rrset 81665 1 0 8 3 l.root-servers.net. 81665 IN A 199.7.83.42 ;rrset 81666 1 0 8 3 l.root-servers.net. 81666 IN AAAA 2001:500:9f::42 ;rrset 81664 1 0 8 3 k.root-servers.net. 81664 IN A 193.0.14.129 ;rrset 82306 1 0 8 3 k.root-servers.net. 82306 IN AAAA 2001:7fd::1 ;rrset 81648 1 0 8 3 j.root-servers.net. 81648 IN A 192.58.128.30 ;rrset 81648 1 0 8 3 j.root-servers.net. 81648 IN AAAA 2001:503:c27::2:30 ;rrset 81635 1 0 8 3 i.root-servers.net. 81635 IN A 192.36.148.17 ;rrset 81635 1 0 8 3 i.root-servers.net. 81635 IN AAAA 2001:7fe::53 ;rrset 31141 1 0 3 3 h.root-servers.net. 31141 IN A 198.97.190.53 ;rrset 81745 1 0 8 3 h.root-servers.net. 81745 IN AAAA 2001:500:1::53 ;rrset 31141 1 0 3 3 g.root-servers.net. 31141 IN A 192.112.36.4 ;rrset 82305 1 0 8 3 g.root-servers.net. 82305 IN AAAA 2001:500:12::d0d ;rrset 31141 1 0 3 3 f.root-servers.net. 31141 IN A 192.5.5.241 ;rrset 31141 1 0 3 3 f.root-servers.net. 31141 IN AAAA 2001:500:2f::f ;rrset 81736 1 0 8 3 e.root-servers.net. 81736 IN A 192.203.230.10 ;rrset 81736 1 0 8 3 e.root-servers.net. 81736 IN AAAA 2001:500:a8::e ;rrset 81731 1 0 8 3 d.root-servers.net. 81731 IN A 199.7.91.13 ;rrset 31141 1 0 3 3 d.root-servers.net. 31141 IN AAAA 2001:500:2d::d ;rrset 81730 1 0 8 3 c.root-servers.net. 81730 IN A 192.33.4.12 ;rrset 82312 1 0 8 0 c.root-servers.net. 82312 IN AAAA 2001:500:2::c ;rrset 82311 1 0 8 0 b.root-servers.net. 82311 IN A 199.9.14.201 ;rrset 82312 1 0 8 3 b.root-servers.net. 82312 IN AAAA 2001:500:200::b ;rrset 81689 1 0 8 3 a.root-servers.net. 81689 IN A 198.41.0.4 ;rrset 81689 1 0 8 3 a.root-servers.net. 81689 IN AAAA 2001:503:ba3e::2:30 Delegation with 13 names, of which 0 can be examined to query further addresses. It provides 26 IP addresses. 2001:503:ba3e::2:30 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 198.41.0.4 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 2001:500:200::b expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 199.9.14.201 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 2001:500:2::c expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 192.33.4.12 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 2001:500:2d::d expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 199.7.91.13 expired, rto 3613192 msec, tA 1 tAAAA 0 tother 0. 2001:500:a8::e expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 192.203.230.10 expired, rto 3613192 msec, tA 1 tAAAA 0 tother 0. 2001:500:2f::f expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 192.5.5.241 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 2001:500:12::d0d expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 192.112.36.4 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 2001:500:1::53 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 198.97.190.53 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 2001:7fe::53 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 192.36.148.17 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 2001:503:c27::2:30 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 192.58.128.30 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 2001:7fd::1 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 193.0.14.129 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 2001:500:9f::42 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 199.7.83.42 expired, rto 3613192 msec, tA 1 tAAAA 0 tother 0. 2001:dc3::35 expired, rto 3613192 msec, tA 0 tAAAA 0 tother 0. 202.12.27.33 expired, rto 3613192 msec, tA 1 tAAAA 0 tother 0. -
@maverickws said in Unbound Resolver - failed to resolve host:
general settings config
seems you have
pointing to (::10.10.10.1 ) selected, was that recommended somewhere?
Seems wrong to have it selected given the description of the Outgoing Network Interface
"Utilize different network interface(s) that the DNS Resolver will use to send queries to authoritative servers and receive their replies. By default all interfaces are used."by the way my entry on that field does not show the :: in front
The address is actually (normally) from this setting (a web server on a virtual IP)
-
@jrey the
::come from IPv6 being in use. It's automatically added, had no part in it.
I don't remember why that interface is selected but I vaguely remember reading somewhere it should be used. (Well, I'm thinking, if it's not selected, how can the DNSBL filters work? maybe I'm wrong here).What I have selected is:
On the Inbound, I have only local interfaces selected.
On the Outbound, I have only those two (and also why I focused that bit on the screenshot).Under pfBlockerNG DNSBL Webserver Configuration the entry is exactly like yours, with the
10.10.10.1. -
@maverickws said in Unbound Resolver - failed to resolve host:
@maverickws said in Unbound Resolver - failed to resolve host:
the :: come from IPv6 being in use
Sorry I missed you have IPv6 running
if it's not selected, how can the DNSBL filters work?
has nothing to do with DNSBL filters, has to do with
"Rejected DNS Requests will be forwarded to this VIP (Virtual IP)"- poorly worded, I'l give you that, but your browser will be directed to this VIP Webpage when a request if blocked by DNSBL.Meaning when a DNS Lookup fails because of the DNSBL , it will display a "Web Page" saying you are blocked. (if you are setup that way, there are options to prevent even this was well)
There is no way that IP can respond as a
"DNS Resolver will use to send queries to authoritative servers" type requestsThe DNSBL will works independent of that setting.
-
@jrey in regard to the requests blocked by the DNSBL I get forwarded to the error page and everything in that aspect seemed like it was working fine.
But for debugging purpose I've removed the selection from the pfBlockerNG VIP. Let's see how this goes.
-
@maverickws said in Unbound Resolver - failed to resolve host:
requests blocked by the DNSBL I get forwarded to the error page
and it would, all that shows is you are running the webpage.
You can easily test that - hit a page you know is blocked by DNSBL, still get the page? you should.
The change on the resolver setting, will only stop the resolver from trying to talk to that IP as a DNS server which it is not.
I'm not sure at this point if you might need to force a Resolver restart, or it may have done one already. check the log for a restart, if you don't see one, do one.
This wording in the DNS Resolver documentation is also suspect
"it will source the query from whichever interface and IP address is closest to the target server from a routing perspective."is 10.10.10.1 (even selection is wrong) closer than another root/authoritative server. I would think the answer is yes. Which them implies most of your DNS queries are going there first. (seems closer) Then will be trying to figure out what that response it likely didn't get really was (ie timeout) , followed by who's next on the list if there is still time.
Cheers
-
@jrey yeah testing that is easy as I have blocks for loads of google shaite and if I do a google search the sponsored results (that go through
googleadservices.com) are all blocked. They were and still are, after that change in the config.Also I confirm that unbound restarted upon making those changes.
Nov 9 17:18:14 unbound 11622 [11622:0] info: start of service (unbound 1.18.0). Nov 9 17:18:14 unbound 11622 [11622:0] notice: init module 1: iterator Nov 9 17:18:14 unbound 11622 [11622:0] notice: init module 0: validator Nov 9 17:17:51 unbound 35100 [35100:0] info: 1024.000000 2048.000000 2 Nov 9 17:17:51 unbound 35100 [35100:0] info: 256.000000 512.000000 1 Nov 9 17:17:51 unbound 35100 [35100:0] info: 32.000000 64.000000 14 Nov 9 17:17:51 unbound 35100 [35100:0] info: 16.000000 32.000000 106 Nov 9 17:17:51 unbound 35100 [35100:0] info: 8.000000 16.000000 520 Nov 9 17:17:51 unbound 35100 [35100:0] info: 4.000000 8.000000 1446 Nov 9 17:17:51 unbound 35100 [35100:0] info: 2.000000 4.000000 3911 Nov 9 17:17:51 unbound 35100 [35100:0] info: 1.000000 2.000000 5744 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.524288 1.000000 4982 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.262144 0.524288 4715 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.131072 0.262144 2855 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.065536 0.131072 2035 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.032768 0.065536 1874 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.016384 0.032768 861 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.008192 0.016384 541 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.004096 0.008192 386 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.002048 0.004096 661 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.001024 0.002048 156 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.000512 0.001024 8 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.000256 0.000512 1 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.000128 0.000256 2 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.000032 0.000064 1 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.000000 0.000001 5834 Nov 9 17:17:51 unbound 35100 [35100:0] info: lower(secs) upper(secs) recursions Nov 9 17:17:51 unbound 35100 [35100:0] info: [25%]=0.0452352 median[50%]=0.43522 [75%]=1.44916 Nov 9 17:17:51 unbound 35100 [35100:0] info: histogram of recursion processing times Nov 9 17:17:51 unbound 35100 [35100:0] info: average recursion processing time 1.249175 sec Nov 9 17:17:51 unbound 35100 [35100:0] info: server stats for thread 1: requestlist max 52 avg 3.97564 exceeded 0 jostled 0 Nov 9 17:17:51 unbound 35100 [35100:0] info: server stats for thread 1: 76301 queries, 39643 answers from cache, 36658 recursions, 2792 prefetch, 0 rejected by ip ratelimiting Nov 9 17:17:51 unbound 35100 [35100:0] info: 256.000000 512.000000 1 Nov 9 17:17:51 unbound 35100 [35100:0] info: 32.000000 64.000000 4 Nov 9 17:17:51 unbound 35100 [35100:0] info: 16.000000 32.000000 45 Nov 9 17:17:51 unbound 35100 [35100:0] info: 8.000000 16.000000 309 Nov 9 17:17:51 unbound 35100 [35100:0] info: 4.000000 8.000000 926 Nov 9 17:17:51 unbound 35100 [35100:0] info: 2.000000 4.000000 2634 Nov 9 17:17:51 unbound 35100 [35100:0] info: 1.000000 2.000000 3763 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.524288 1.000000 3239 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.262144 0.524288 3085 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.131072 0.262144 1965 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.065536 0.131072 1291 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.032768 0.065536 1297 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.016384 0.032768 593 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.008192 0.016384 340 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.004096 0.008192 274 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.002048 0.004096 484 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.001024 0.002048 116 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.000512 0.001024 10 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.000256 0.000512 1 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.000128 0.000256 1 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.000032 0.000064 1 Nov 9 17:17:51 unbound 35100 [35100:0] info: 0.000000 0.000001 3304 Nov 9 17:17:51 unbound 35100 [35100:0] info: lower(secs) upper(secs) recursions Nov 9 17:17:51 unbound 35100 [35100:0] info: [25%]=0.0528975 median[50%]=0.44607 [75%]=1.46804 Nov 9 17:17:51 unbound 35100 [35100:0] info: histogram of recursion processing times Nov 9 17:17:51 unbound 35100 [35100:0] info: average recursion processing time 1.117983 sec Nov 9 17:17:51 unbound 35100 [35100:0] info: server stats for thread 0: requestlist max 39 avg 2.58599 exceeded 0 jostled 0 Nov 9 17:17:51 unbound 35100 [35100:0] info: server stats for thread 0: 56393 queries, 32710 answers from cache, 23683 recursions, 2483 prefetch, 0 rejected by ip ratelimiting Nov 9 17:17:49 unbound 35100 [35100:0] info: service stopped (unbound 1.18.0). -
but is there a resolution to the problem of resolution?
by the way, earlier today I rigged up a monitor on several of the sites you indicated as failing either by ping or dns lookup
Not so much as a burp here.
Although on the ping -- Microsoft, spiked (longer response) for about 30 minutes a little over an hour ago. spiked = 4x their avg. But still zero failure.
-
@maverickws said in Unbound Resolver - failed to resolve host:
This log snippet, shown when you restarted unbound :
... Nov 9 17:17:51 ......info: server stats for thread 1: 76301 queries, 39643 answers from cache, 36658 recursions, 2792 prefetch, 0 rejected by ip ratelimiting ... Nov 9 17:17:51 ......info: server stats for thread 0: 56393 queries, 32710 answers from cache, 23683 recursions, 2483 prefetch, 0 rejected by ip ratelimiting ...this tells me : unbound did received a whole bunch of DNS requests from the local LAN networks, did give a lot of answer right out of the unbound cache, did do a lot of dns lookup doing its thing = resolving.
Sorry for the "calling fox". Undoing this :
(10.10.10.1 and Localhost are the upstream DNS servers)
will point unbound to 10.10.10.1 which doesn't have any DNS facilities, and 127.0.0.1 points to itself.
Selecting "All" here, or selecting outgoing, typically WAN interface, is mandatory for unbound to work.
( That's why it is set to All by default )@maverickws said in Unbound Resolver - failed to resolve host:
I have dual-WAN. I'm not commenting on the "change country bit" because its just starting to get ridiculous like some parts of your comments I didn't really appreciate, but moving on...
I need to explain :
If you have upstream DNS issue, like not being able to use DNS servers like you've shown above, you can't do anything yourself. Not your fault, neither pfSense. This can happen.
Now, don't feel offended again : this actually (nearly) never happens. Most of the "Unbound resolver doesn't resolve" questions will boil down to this : undo setting 'X' and case solved.
An example : More and more often ISPs enable IPv6 support, and pfSense, unbound will prefer IPv6 over IPv4. If the IPv6 implementation is 'not RFC compatible', as many ISP make it up with their own sauce, then IPv6 traffic becomes 'bad'. This will impact unbound ... thus DNS.
Changing for a 'better' ISP', one that support IPv6 with prefixes etc could be a solution. Or tell unbound not to use IPv6 ...Something to test : are you using the new DHCP server KEA ? What happens when you go back to ISC ?
Your pfBlockerng settings looks like this :
With these settings, unbound will loop every DNS request through pfBlocker. Every requests wind up in the dns_reply file.
This one is special :
@maverickws said in Unbound Resolver - failed to resolve host:
Unable to resolve acb.netgate.com - it also seems here people are not addressing the real issue.
I'm seeing that one also, once or so per month : my pfSense can't "call home" (to upload the config to abc).
What I also see, several times the last couple of days / a week : the entire negate.com becomes unreachable. So no more forum and other netgate resources. I guess this is related to the host or the route to the hosts that Netgate uses. Or the huge impact on their servers as a new version was released ? -
HIya all,
@jrey I don't believe it's the places failing, I appreciate the monitor but I'm positive the issue is local. Some whatever that is making the resolver not working so well.
I believe that having the pfBlockerNG VIP there was in fact the culprit.For example, now I look at the log where it would show me the failed to resolve errors, and I haven't had one since I changed that setting.
@Gertjan
I don't have ALL interfaces selected because a few years back there was some issue with the DNS resolver and I remember someone mentioning on the forum to only select 127.0.0.1.
And it worked by the way. Actually, right now, after removing the selection of the pfB VIP, the errors seem to have been overcome, so far.
In the meanwhile I went a little further and, considering the description on the outbound network interfaces, I also selected my two WAN interfaces.
(interface(s) that the DNS Resolver will use to send queries to authoritative servers and receive their replies) so I have now selected Localhost, WAN1 and WAN2. If I keep "All" it will still try and use the pfB VIP sometimes, I'm figuring some sort of round-robin through the interfaces selected or something?These resolution issues started happening not so long ago (actually I believe since 23.05) but got more frequent after the last update (much more, made me come here and talk about it and the need to find the problem).. And since they were happening on the latter version (before KEA) so I figure the DHCP backend was irrelevant.
I understand now that my selection of the pfBlocker VIP was just wrong, but I also vaguely recall that was encouraged by some answer either here or reddit not totally sure. But won't fall for that again.
I don't have the python module enabled on unbound resolver, DNSBL is on plain "Unbound mode".
-
@maverickws said in Unbound Resolver - failed to resolve host:
Actually, right now, after removing the selection of the pfB VIP, the errors seem to have been overcome, so far.
In the meanwhile I went a little further and, considering the description on the outbound network interfaces, I also selected my two WAN interfaces.Sounds like you are resolving. Those are good choices.
-
@maverickws said in Unbound Resolver - failed to resolve host:
only select 127.0.0.1.
Yeah - localhost works for outbound.. "::10.10.10.1 (pfb dnsbl)" not so much..
selection of the pfBlocker VIP was just wrong, but I also vaguely recall that was encouraged by some answer
I have stated multiple times that localhost as outbound is valid choice, it would then nat to where your trying to go via any wan interface that is being used, etc.. This allows for unbound to come up when a wan side interface is not yet up, or a vpn interface for example.. If a wan interface goes down, it wouldn't cause a blip in unbound, etc.
But where you got some odd ball vip by pfblocker being the same as localhost, that sure didn't come from any of my posts.. And would love to see where you read any such thing, because its blatantly a horrible idea, and where ever its posted it should be pointed out how bad of an idea that is to whoever posted such a thing.
I have been using localhost only for my outbound interface for years.. But depending on what your doing you may need to select other interfaces to talk to where your wanting to talk. But the pfblocker vip would never be one of those.
-
@johnpoz said in Unbound Resolver - failed to resolve host:
because its blatantly a horrible idea
Sadly, I've seen many people select it either individually or via the "ALL" recommendation which certainly includes it as well .. at which point it is a random. But selecting it and something else only would certainly make the resolver go there more often than not.
Documentation page on Outbound Network
"By default the DNS Resolver utilizes all interfaces for outbound queries so it will source the query from whichever interface and IP address is closest to the target server from a routing perspective."10.10.10.1 is pretty close ;-) but also wrong.
Myself I've never seen a recommendation written anywhere to select this address as an option when the user is not using ALL or selecting other appropriate "NAMED" interfaces as may be required for some use cases.
At the very least for most people following the "ALL" recommendation, that should imply everything except that. So a user could just not select "ALL", and then select individually everything except that (or other) VIP if any exist.
Also sounds like a bug report (change request) in the making ?
Although technically an "INTERFACE", it is a single IP that has no DNS capability.
should be an easy fix simply by not adding it to the selection list in the first place. -
@jrey said in Unbound Resolver - failed to resolve host:
should be an easy fix simply by not adding it to the selection list in the first place.
Yeah I have no idea when some vip used for pfblocker would come into play for unbound?
But that vip would for sure never be used for some outbound dns query by unbound that is for sure.. So yeah why would it ever be an option I have no idea.. it sure isn't like that in mine..
Wondering if that is from the Placeholder IP Address?
For IPv6 '::' will be prefixed to the placeholder IP.
