pfSense resolver stops working

Gertjan

@johnpoz said in pfSense resolver stops working:

it has to do with unbound using IPv6 to make the query or answer the query.

@gertjan said in pfSense resolver stops working:

Take note : unbound knows that there is no IPv6 available

should be : no IPv6 over WAN available.
I was convinced that a :

still permitted local IPv6 :

[22.05-RELEASE][root@pfSense.my-local-mess.net]/root: sockstat -l | grep ":53"
unbound  unbound    60716 3  udp4   *:53                  *:*
unbound  unbound    60716 4  tcp4   *:53                  *:*
unbound  unbound    60716 7  udp6   *:53                  *:*
unbound  unbound    60716 8  tcp6   *:53                  *:*

I redid the test.
The manual and you are right.
I see now :

[22.05-RELEASE][root@pfSense.getting-better.net]/root: sockstat -l | grep ":53"
unbound  unbound    47871 3  udp4   *:53                  *:*
unbound  unbound    47871 4  tcp4   *:53                  *:*

johnpoz

@gertjan said in pfSense resolver stops working:

knows that there is no IPv6 available

You know what ticks me off dns clients... There is no IPv6 on my psk network, where my rokus sit.. Yet they still ask for AAAA, why you asking for an IPv6 address when you don't even have an IPv6 address?? Well it has a link-local address, but come on!!

maverickws

I figure doing the IPv6 lookup makes sense on the local network considering local IPv6 is enabled.
let's say web-server1 and db-server1 are using the ipv6 link locally. they still need to ask the resolver who that host is, and it will return the A and AAAA records. Since IPv6 takes precedence, it makes sense locally.

Now what really is the issue here is that unbound is unable to differ from local link connectivity and wide-network connectivity, so I'm assuming it tries to query the root servers with IPv6, where no IPv6 connection to that destination is available.

In the end I bet if looked closely those issues will all be related to this (as local ipv6 connectivity is enabled by default iirc) where users don't have IPv6 wan.

What would be interesting to understand as well is why has this behaviour changed from previous versions of unbound to the current state. Clearly some sort of logic was present before preventing this from happening, where now is gone.

johnpoz

@maverickws yeah I guess

But come on, these streaming boxes don't normally do anything locally. If you do not have a GUA Ipv6 address, why waste cycles asking for AAAA

maverickws

@johnpoz but in my case they aren't streaming boxes. They're application servers, database servers and alike. the webserver/dbserver was an accurate example of local connections here. We never connect to the web server using IPv6, but the web server does connect to services internally using ipv6. or used to, I guess.

johnpoz

@maverickws sorry I might of gotten a bit off topic, I was just bitching about IPv6 dns clients in general...

To me if you don't have a GUA, or at least ULA - there is zero point to asking for AAAA, sure ok maybe you have link local, but link local addresses don't belong in DNS..

https://www.ietf.org/rfc/rfc4472.txt
Operational Considerations and Issues with IPv6 DNS

Section 2.1

Link-local addresses should never be published in DNS (whether in
forward or reverse tree), because they have only local (to the
connected link) significance [WIP-DC2005].

lohphat

@maverickws said in pfSense resolver stops working:

I don't think it's memory related (could be wrong ofc) but I've never seen the pfSense be nowhere near it's limits either of memory or CPU.

It's related to memory allocation unbound uses internally for its local data, not the entire memory on the appliance running out.

See earlier post regarding unbound release 1.16.0 github notes

maverickws

Hi guys I have an update on this, will update if it goes the other way:

I was doing some changes on my home pfsense (where I have pfblockerng etc) and all of the sudden dns went a-wire.
Ended up having to add the do-ip6: no option but that really wasn't making sense as I had updated in ages and haven't had issues so far. PLUS I have IPv6 here working well.

So in the end I remembered I had enabled the Experimental Bit 0x20 Support option.
Disabled it, haven't had issues since. A couple of hours.
So I'm wondering how's your setups and what conflict could it be.

johnpoz

@maverickws Have had that enabled for YEARS.. zero issues with it.

maverickws

@johnpoz

i know i have it enabled at the pfsense on service and honestly thought it was so as well with the home pfsense. crossed my eyes on it, saw it was disabled, never gave it a thought, enabled. so far all ok since i disabled it again, let's see

Erutan409

@maverickws Did that end up fixing your issue?

maverickws

@Erutan409
Hi there,

From what I remember it solved my issue then, but I'm having another issue now I'll be making another topic for it.

maverickws

@Erutan409 See if this means anything to you please

https://forum.netgate.com/topic/183918/unbound-resolver-failed-to-resolve-host

Erutan409

@maverickws Yeah, it also seems to be happening more frequently with me, too, all of a sudden.