Unbound Resolver - failed to resolve host
-
@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. -
@johnpoz I don't remember where I got it from. Maybe some issue I had and reading around (not saying on these forum and much less implying you were the one saying it).
So I have to ask this: Is it better to leave only localhost, or is it ok to have localhost + WAN1 and WAN2 selected?
I wonder if before 23.05 the pfBlocker VIP would simply be ignored or not used by unbound, and some change had it included?
-
@maverickws said in Unbound Resolver - failed to resolve host:
So I have to ask this: Is it better to leave only localhost, or is it ok to have localhost + WAN1 and WAN2 selected?
Localhost is how I would setup mine - but without details I have no idea for you, maybe you don't nat to one of those wans?
If your going to directly select wan1, 2 etc. not sure what selecting localhost would get you? Unless if there was some other interface that you nat too like a wan3 that you would normally just route to and nat to get to some NS you want to talk to.
To be honest - if you do not understand why selecting specific makes sense for your setup, then all is prob where you should leave it..
I am not really sure where that came from - but to be honest it should of never been used, even if was selected. unless that is suppose to be IPv6 address of something, and your unbound was trying to talk to IPv6 - causing delays/issues?
Was it some other thread were you were also saying unbound was broken where you were having issues talking to some IPv6 in a trace?
I on purpose disable IPv6 in unbound.. with do-ip6: no in my custom options. Because I see no point in using it for my resolving.. I use a HE tunnel for my ipv6, and makes no sense to route traffic out that tunnel, unless I specifically need to, you know to get to a IPv6 address. Well there is nothing in dns that is not available on ipv4, for sure anything I would ever want/need to get to - so why should I use IPv6 for my day to day dns resolving?
Think I mentioned that in some other post and showed using -4 in the trace so IPv6 is not use, because in one of the traces I did I was having issues talking to IPv6 for one of the ns.. Maybe they block HE ipv6 space?
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 -
@maverickws said in Unbound Resolver - failed to resolve host:
I wonder if before 23.05 the pfBlocker VIP would simply be ignored or not used by unbound
Not that I can recall.
On the other hand, not having it show on the selection seems trivial enough and therefore not having the ability of selecting seems like a reasonable choice when compared having the ability to select (maybe). playing more now.
-
the issue is I've been using pfSense for a while, my setup here at home using pfSense has undergone so many changes ... different ISP's, the upgrade from single WAN to multi-WAN, etc etc.
I can't actually remember all the issues I've gone through ... for one my memory is not the best ... another is I go through so many IT problems each day, I end up forgetting some details after problems have been dealt with.I'm not sure what you mean by "maybe you don't nat to one of those want?" could you explain this a little more so I can answer? But anyway, I'll try to lay how's this set up:
WAN1 is one ISP and have a fiber modem that converts to ethernet and I get a public IP here
WAN2 is another ISP have a docsis modem converting to internet and also a public IP on this interface hereLocally ... all devices are nat'ed on the IPv4. I have a gateway group for IPv4 with WAN1 tier1 and wan2 tier 2. Apart from this, I route some traffic from specific clients through WAN2 only.
@jrey I believe it shows there because you can have a VIP being used for traffic and you could in some situations want to use that as outgoing interface I guess. It's pfSense that doesn't discern if that is a regular VIP or a pfBlocker VIP.
-
@maverickws said in Unbound Resolver - failed to resolve host:
my setup here at home using pfSense has undergone so many changes
I can't actually remember all the issues I've gone through ... for one my memory is not the best
You know what can help with that ... setup a personal wiki on a small local system or docker.
Then document your changes... and anything else you may need details on in the future.
For example, I've already documented this while I test the change and decide what to do with it. Yes, it currently lives as a custom patch on my system. Not that I ever would have selected the option, now i know I never can, not even by accident, because it is not on the list!
Even if I never actually use it, I'll know what I did, step by step.
Want to go back to say a Windows XP box, I can look in the "Legacy OS Toys" page, and have it up and running in minutes. thought I should check.. LOL
yup still got it (but why...)
wow, now there are a couple I haven't fired up in a while
A Debian 11 system - Hosting Raspberry Pi Desktop - Hosting PiDP
Always fun!
or how about a good old
"Welcome to SCO Xenix System V"
