Local DNS not in /etc/resolv.conf with Unbound after reboot

[flushell]

• OPNSense is 10.0.0.1
• I have PiHole IP in Settings-System-General-DNS Server: 10.0.4.2
• OPNSense is DHCP server
• I have Unbound on the OPNSense box for local resolution of DHCP handed out IP's. Forwarding Mode OFF.
  Desectected: Do not use the local DNS service as a nameserver for this system in Settings-System-General, so OPNSense asks local DNS first for Aliases and so on.
• PiHole asks Unbound for local hostnames via Conditional Forwarding and talks to external DNS for all the other stuff

This works like a charm. I never see the OPNSense box in my PiHole logs asking for local hostnames.

However I had to reboot OPNSense and now I see OPNSense asking for local hostnames every 10 minutes in the PiHole log. Not a big problem, because PiHole simply asks Unbound and it is resolved via a small detour. But it is not the expected behaviour

I checked /etc/resolv.conf and noticed only the PiHole IP is there. That is the explenation of this behaviour.

When I click Save once in Settings-System-General OPNSense, the issue is resolved and I can see that now both 127.0.0.1 and my PiHole IP are in /etc/resolv.conf

This could be a bug, I think that after a reboot /etc/resolv.conf should contain 127.0.0.1 as DNS server (besides the one mentioned in Settings-System-General-DNS Server) when Do not use the local DNS service as a nameserver for this system is desleceted.

Or am I wrong?

OPNsense 20.7.7_1-amd64
FreeBSD 12.1-RELEASE-p11-HBSD
OpenSSL 1.1.1i 8 Dec 2020

[franco]

This could be a bug, I think that after a reboot /etc/resolv.conf should contain 127.0.0.1 as DNS server (besides the one mentioned in Settings-System-General-DNS Server) when Do not use the local DNS service as a nameserver for this system is desleceted.

Well, yes and no, the code to write resolv.conf is always the same and executed once at boot (not counting any dynamic reloads through WAN DHCP for example):

https://github.com/opnsense/core/blob/1a646e087d842164a1240f420768aab03a2e4b4d/src/etc/inc/system.inc#L172

To say 127.0.0.1 is omitted once but 10.0.4.2 always written is a mystery as to why that would happen since both come from the same configuration file, although stranger things have happened.

What I am trying to say is I can't easily reproduce this and do not have an idea what could be causing it.


Cheers,
Franco

[flushell]

Thanks foor looking into this.
Well, I tried this on two boxes now and it is reproducible:

• Unbound On
• Do not use the local DNS service as a nameserver for this system not selected
• Random IP in Settings-System-General-DNS Server
• Check /etc/resolv.conf and see 127.0.0.1 is there
• Reboot
• Check /etc/resolv.conf and see 127.0.0.1 is gone
• Click Save in Settings-System-General
• Check /etc/resolv.conf and see 127.0.0.1 is there

I was thinking: could it be a race condition or something in the order resolv.conf changes are carried out at boot?
Is resolvconf the only process that changes /etc/resolv.conf?
I noticed that after boot the file begins with # Generated with resolvconf, but after Save this line is gone...
It is almost as if the setting is not carried out after boot or something is removing it.

[franco]

Okay, so "something" calls FreeBSD's resolvconf program but it's not us, at least not directly. In a VM here this is impossible to reproduce with your steps alone (it's more or less a default setup for thousands of people) so it is something that is triggering this locally.

The naughty bit here being we write resolv.conf on boot but then it gets overwritten during the later boot stage, maybe also by a VPN or other service / plugin used.


Cheers,
Franco

[flushell]

Okay, so "something" calls FreeBSD's resolvconf program but it's not us, at least not directly. In a VM here this is impossible to reproduce with your steps alone (it's more or less a default setup for thousands of people) so it is something that is triggering this locally.

The naughty bit here being we write resolv.conf on boot but then it gets overwritten during the later boot stage, maybe also by a VPN or other service / plugin used.


Cheers,
Franco

Ah! Interesting. I use WireGuard. I will test this tomorrow.

[Fright]

yep. WireGuard writes resolv.conf on every (re)load if DNS is set on instance

[franco]

Ugh, does it really need to? We will coordinate with the maintainer of the plugin to solve this.


Cheers,
Franco

[Fright]

Ugh, does it really need to?

imho there is logic in this
when DNS is specified and applied in this way on the client side it should prevent dns leakage.
In my understanding, this option is a client-side, since although it can be specified on the server-side, client can always override it.
I have not seen any way to disable this behavior. can only edit wg-quick script.
(or skip this option and set\delete dns on PostUp\PostDown)

so maybe just more detailed help is enough?

[flushell]

yep. WireGuard writes resolv.conf on every (re)load if DNS is set on instance

Ah, I found this out too just know  .
Thanks for checking.

Ugh, does it really need to? We will coordinate with the maintainer of the plugin to solve this.


Cheers,
Franco

Thank you.

Ugh, does it really need to?

imho there is logic in this
when DNS is specified and applied in this way on the client side it should prevent dns leakage.
In my understanding, this option is a client-side, since although it can be specified on the server-side, client can always override it.
I have not seen any way to disable this behavior. can only edit wg-quick script.
(or skip this option and set\delete dns on PostUp\PostDown)

so maybe just more detailed help is enough?

It is a client-side thing. If I don't set DNS on the WireGuard server (Local Tab in WireGuard) and I reload WireGuard it does not call resolvconf. For me this is a solution, because I have set DNS in on my clients, so I don't need this setting there.

I still think it is usefull to contact the maintainer, like Franco said.

[errored out]

A better, but not perfect solution would be to place the DNS Server IP address option on the clients' table.  Granted the client may be able to change it. But at least it would not cause crippling issues to the firewall / DNS resolution.