pfSense resolver stops working

maverickws

@gertjan I'm assuming for the same reason that it doesn't choke on my soho setup and it does on the datacenter:

At home I have a valid ipv6 wan connection, so I'm assuming it does some resolving via IPv6 link to the world. So at home, since there's a valid WAN IPv6 link, no problems.

At the DC, the IPv6 is only enabled locally, this setup does not have external IPv6 connectivity. And I'm assuming this is the exact point that makes the difference.

Gertjan

@maverickws said in pfSense resolver stops working:

the IPv6 is only enabled locally, this setup does not have external IPv6 connectivity.

Imagine :
All local devices see IPv6 on their network interface, and all (modern) OS will prefer IPv6 over IPv4, so DNS requests will be 'AAAA' first, and will unbound collects all the AAAA info, gives the result back to the local devices, who will initiate a IPv6 to the (remote) host.
Nothing comes back, the connection will time out, and after a while, everything restarts, this time using classic A requests to get an A for the host.
Take note : unbound knows that there is no IPv6 available, and will ask for AAAA over a IPv4 UDP or TCP connection. That's not an issue.
IMHO : Informing your local LAN that the DNS/Gateway doesn't 'speak' IPv6 should accelerate overall network fluidity.
The local devices can very well talk 'IPv6' among them on their local LAN, that ok.

You could also add IPv6 to your DC, he.net IPv6 Tunnel Broker offers you a free static /48 and is rock solid, easy to implement with pfSense. I'm using their services for years already.

johnpoz

@gertjan the do-ip6 has nothing to do with AAAA or A, it has to do with unbound using IPv6 to make the query or answer the query.

   do-ip6: <yes or no>
          Enable or disable whether ip6 queries are  answered  or  issued.
          Default  is yes.  If disabled, queries are not answered on IPv6,
          and queries are not sent on IPv6 to  the  internet  nameservers.
          With  this option you can disable the ipv6 transport for sending
          DNS traffic, it does not impact the contents of the DNS traffic,
          which may have ip4 and ip6 addresses in it.

if your goal is not returning to the client AAAA when they asked for it for say google.com you can use the option

private-address: ::/0

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.