Unbound Resolver - failed to resolve host

[jrey]

@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

[maverickws]

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, about dns_reply.log that'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.

[jrey]

@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)

[maverickws]

@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.

[jrey]

@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 requests

The DNSBL will works independent of that setting.

[maverickws]

@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.

[jrey]

@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

[maverickws]

@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).

[jrey]

@maverickws

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.

[Gertjan]

@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 ?

[maverickws]

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".

[jrey]

@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.

[johnpoz]

@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.

[jrey]

@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.

[johnpoz]

@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.

[maverickws]

@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?

[johnpoz]

@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?

[jrey]

@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.

[maverickws]

@johnpoz

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 here

Locally ... 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.

[jrey]

@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"