DNS server advertisemenet via DHCP not using interface ip address anymor

[Senten]

Hi there,

I have updated my opnsense from 23.1.5 to 23.1.6(-amd64) yesterday and after that the DHCP service advertised the globally configured system dns-servers (public ones) instead of the interface ip addresses, as it used to be.

I am running AdGuardHome as the main DNS service and unbound as forwarder with a few local overrides. That means  after the update clients can resolve public names but not the ones i only use locally.

As a result I now have to manually set the interface ip addresses as the dns servers in the DHCP configuration, which i used to leave blank. In order to be able to do that for IPv6 I now have to additionally configure virtual fd00 IP aliases, which I do not need for anything else an actually would like to deconfigure again as soon as possible.

I tried rolling back a snapshot of 23.1.5 and this version does not have the problem.

Is this a bug or expected behavior? I read about some changes regarding bind hooks in the changelog but as I am not running bind I suppose that does not affect me?

Regards and thanks in advance,
Senten

[axsdenied]

Check this thread:
https://forum.opnsense.org/index.php?topic=33661.0

[Senten]

Hi and thanks for the link.

If I understand correctly the issue is with the AdGuard plugin from the mimugmail repository not being ready for opnsense 23.1.6 and the problem only exists with AdGuard being configured with Port 53.

Setting the advertised dns server ip addresses statically is one workaround.

Usind a different port for AdGuard and forwarding from Unbound/Bind to AdGuard being another one.

A third workaround seems to be using port 53 on both AdGuard and Unbound/Bind and making AdGuard listen to a dedicated virtual IP address with NAT port forward.

Let's hope the AdGuard plugin will get an update addressing this soon :-)

[Senten]

There already is a github issue for this: https://github.com/mimugmail/opn-repo/issues/153

[Senten]

A fix is mentioned in the current change log but the behaviour hasn't changed for my case.

Plugin Changelog
================

1.9

* Fix DNS settings introduced with 23.1.6
* Update to latest version

[jp0469]

A fix is mentioned in the current change log but the behaviour hasn't changed for my case.

Plugin Changelog
================

1.9

* Fix DNS settings introduced with 23.1.6
* Update to latest version

Did you enable the new checkbox in the Services > Adguard Home page?

[Senten]

Did you enable the new checkbox in the Services > Adguard Home page?

Good call! Of course I did'nt   ::)

Problem solved - thanks a lot  ;D

[Senten]

I noticed with AdGuardHome 1.9 as primary DNS only the IPv4 address is advertised correctly but IPv6 still falls back to the system default servers:

   DNS-Server  . . . . . . . . . . . : 2620:fe::fe (quad9)
                                       2620:fe::9 (quad9)
                                       10.10.0.1 (AdGuardHome)

Is that a config error on my side or was it maybe overlooked in the 1.9 release?

[franco]

The new 23.1.6 facility to provide DNS ports / primary DNS to OPNsense is address family-agnostic, which means it is something else going on here on your configuration end.


Cheers,
Franco

[Animosity]

It has to do something with AdGuard.

I retried AdGuard on a fresh install on port 53 and checked the box.

DHCP DNS for IPV6 stopped working.

Reinstalled fresh, no AdGuard. DNC DNS for IPV6 worked.

Seems easy to reproduce and test but I really have no use for AdGuard as I just use the same 2 blocklists for Unbound.

[Senten]

It has to do something with AdGuard.

I retried AdGuard on a fresh install on port 53 and checked the box.

DHCP DNS for IPV6 stopped working.

Reinstalled fresh, no AdGuard. DNC DNS for IPV6 worked.

Seems easy to reproduce and test but I really have no use for AdGuard as I just use the same 2 blocklists for Unbound.

That's interesting, because I think I found the issue on my end:

Turned out my client was not using the DHCP lease reserved for it because its' MAC-address changed due to the local Hyper-V service kidnapping the adapter ... .

For some reason my client did not pick up a different DHCP lease with its' now virtual MAC-address but was served only through SLAAC instead.

The RD daemon was not restarted yet though and this might have been the reason, why it still propagated the global system default dns servers.

After deleting the Hyper-V-virtual-switch and regaining the original MAC-address, my client accepted the reserved DHCP lease and was told to use the correct dns servers for IPv4 and v6.

After restarting the RD daemon android clients received the correct dns configuration, too.

Regards,
Senten