dnsmasq and query forwarding

[cinergi]

@cinergi I understand why this is a problem. :-) So it looks like a bug. Maybe open an issue on github.

I don't use DNSmaq and probably never will. Kea and Unbound it is for me. I do not understand the motivation to bring in this piece of software, to be honest.

The only reason (for me) is to enable local DNS resolution, since Unbound does not integrate with Kea.  That's the only reason why I've been trying to make DNSmasq work.  Otherwise I would happily use Unbound for DNS and Kea for DHCP.

[Patrick M. Hausen]

Unbound and Kea do support resolution for static leases. I do not need dynamic ones unless it's finally implemented via the proper protocol as it (IMHO) should.

[stumper]

1. Reverse lookups: dig -p 53053 @192.168.31.1 -x 192.168.31.20
your reverse resolution forward entries in unbound are probably wrong: I guess you wanna change *.198.* to *.192.in-addr.arpa . Furthermore your are probably better off with a single 168.192.in-addr.arpa. as I doubt you want to individually configure this on host level in your setup.

@medivh: thanks for pointing out my mistake (case of tired eyes on my part), everything working as expected with that correction.

2. Short name resolutions - I also realized, after stepping away for a bit, that short name digs were not going to work no matter what.

3. With the patches applied and the Unbound query forwarding address correction, I have not received any intermittent resolution errors in the past hour.

@Patrick: Having Dnsmasq as an available option is good thing, at least for my needs - once it is stable here, my goal is to retire Unbound and rely only on Dnsmasq for DHCP and DNS, with DNS blackhole capabilities added in (coming from an Asuswrt-Merlin home setup, I have been using Dnsmasq blackhole functionality for many years successfully and comfortably).

Thank you to all who have responded and provided very useful information!!

[cinergi]

@Monviech has changed the scheme on how to determine the "local" domains by his latest patch once again. It requires the user to mark at least one DHCP host entry from each forwarded domain to be marked as "local" (a new flag introduced by the commit).

But still: that commit is also not yet part of any release and you have to apply both previous patches in order first, therefore I am not showing how to do it. Just keep your patience and hope it will work. I have switched back to ISC DHCP / Unbound for the time being as I was struck by the same problem.

If I understand correctly, that latest patch adds a checkbox in the DNSmasq DHCP static host entries list enabling the host's configured domain to be designated as Local.  But if I look in the DNSmasq configuration file /usr/local/etc/dnsmasq.conf, my local domain (I only have one) is already present there even without enabling that checkbox: local=/home.lan/  So I don't see how this patch would help in my case.  There must be something else going on.

I've reverted to Unbound + ISC until the Unbound + DNSMasq solution is stabilized.

[OPNenthu]

I do not understand the motivation to bring in this piece of software, to be honest.

coming from an Asuswrt-Merlin home setup

Bingo.

This is twice now I've seen recent comments referencing prior familiarity with some *WRT derivative as an argument for preferring Dnsmasq.  We are likely sorting ourselves into camps: those favoring more professional setups, and those favoring home routers / embedded appliances.

I was debating with myself if maybe Dnsmasq was a play for smaller, resource constrained applications.  Now I think it makes sense that it's more about familiarity and convenience (integration), because after all OPNsense runs a FreeBSD base on x86 hardware with (usually) multiple gigabytes of RAM.  A resource constraint argument makes less sense here as compared to an embedded router OS.

[cinergi]

Bingo.

This is twice now I've seen recent comments referencing prior familiarity with some *WRT derivative as an argument for preferring Dnsmasq.  We are likely sorting ourselves into camps: those favoring more professional setups, and those favoring home routers / embedded appliances.

I was debating with myself if maybe Dnsmasq was a play for smaller, resource constrained applications.  Now I think it makes sense that it's more about familiarity and convenience (integration), because after all OPNsense runs a FreeBSD base on x86 hardware with (usually) multiple gigabytes of RAM.  A resource constraint argument makes less sense here as compared to an embedded router OS.

I would prefer a Kea + Unbound setup, since I see Kea as more robust and professional than DNSmasq.  However, the Kea implementation in OPNsense lacks certain features that are important to me including support for custom DHCP options and registration of static and dynamic DHCP hostnames in Unbound.  The pfSense folks seem to have done it already - see https://docs.netgate.com/pfsense/en/latest/services/dhcp/kea-settings.html.  To the OPNsense folks - please, please consider doing the same!

[grind]

There have already been efforts to have dynamic registration in unbound for KEA DHCP leases: https://github.com/opnsense/core/issues/7475

Unfortunately opnsense has closed this without any reason. Maybe the opnsense team can think again about this, because this whole KEA/dnsmasq/ISC situation is kind of frustrating and introduces more confusion than clarification both for long time and new users. IMO the standard should be KEA as the ISC successor, including dynamic host registration and dnsmasq should be optional as it always was.

[Monviech (Cedrik)]

Most small to medium business environments I have seen so far (in germany) use Microsoft, which includes a dynamic registering DHCP/DNS combination with HA capabilities as standard server roles. Microsoft devices even have their own commands to register their DNS name inside active directory integrated DNS servers.

For businesses who use these technologies, running Kea with scripts that update some other DNS server, or even with a KEA plugin that enables RFC2136 to update a server with zones like bind, should be a less preferable solution (also because it is pretty new, the reports about KEA are not quite positive yet, and other combinations are more battle tested).

For dynamic registration, this is something more specific to the home user environment. In a business environment, you shouldn't even want random dynamic updates because they cannot be as safely controlled as static leases.

This means, KEA + Unbound with static leases could work for businesses if they want a different DHCP server + DNS server combination. (As it exists right now)

For home users, Dnsmasq could be the preferable choice, even as single DNS/DHCP server that just forwards to e.g., google or cloudflare or the ISP DNS servers.

The choices are there, everybody can take what they think is the better one.

In my home network with quite some vlans and homelab, I run dnsmasq dhcpv4+dhcpv6+RA and all DNS features since 3 months and have peace and quiet.

Sometimes its just personal preference that clouds the correct answer. I am leaning a bit more towards dnsmasq though since it makes more sense to me.

Please note that this complete post is my own personal opinion.

[grind]

I agree with these widespread MS AD Setups, but: MS is considering on-prem AD as legacy and urges people to get rid of it and moving to entra id. So in the next years, this scenario is going away and businesses need an answer for that. While dynamic registration is not so much relevant in normal usage, it is when doing debugging. In Entra ID case, the hostname is well defined, because the device is managed by intune. So the admin can see the proper reverse dns name while running i.e. a tcpdump. Depending on the size of the business, there are various options like commercial ones like fortigate, unifi or opensource solutions with optional commercial support like opnsense. I'm sure that opnsense is considered often, but if the set up is not so straight forward anymore, it could be the case that an admin who isn't so much "in the game" as many users here, will consider another solution which "just works".

Regarding dnsmasq: Dnsmasq is IMHO fine when there is no need for a real recursive DNS server. But many people are running unbound for various reasons and do not want to use an upstream recursive DNS. Now there are 2 options, either bind unbound or dnsmasq to port 53 and forward either everything or just specific zones, depending which server is running on 53. Both work, but both have their caveats and are more a workaround than a proper solution.

The ISC solution with the script that feeds unbound with the dynamic leases has been a proper solution for the last years. It just worked, there haven't been much complaints. So why re-inventing the wheel here when we just could do the same with KEA?

[Monviech (Cedrik)]

The setup with two dns servers is not even that uncommon, check out what pihole recommends for example (its a dnsmasq + unbound combination)

https://docs.pi-hole.net/guides/dns/unbound/

[Patrick M. Hausen]

This means, KEA + Unbound with static leases could work for businesses if they want a different DHCP server + DNS server combination. (As it exists right now)

It does for me at home and will do @work once we get the unifi option 43 issue solved. I am indeed quite satisfied with Kea, needs only minor improvements.

Kind regards,
Patrick

[Monviech (Cedrik)]

Do you really need option 43? Ive read some discussion on reddit where somebody assumed they needed it, but what made it work the whole time was resolving the unifi inform endpoint via DNS.

It looks like unifi gear has several fallbacks and/or different ways to find each other.

https://www.reddit.com/r/opnsense/s/hWyYrkYmN7

[Patrick M. Hausen]

I wasn't aware of that. We have Unifi gear in two office locations with the controller placed in our data centre, so routed connection. I have been using option 43 ever since we started to use Unifi.

So I could add a host override for "unifi." in Unbound ...

Anyway Kea in OPNsense needs a procedure to introduce selected custom options we agree on. I'll give it a try.

[meyergru]

Yes, a DNS resolution for "unifi" works, too: https://help.ui.com/hc/en-us/articles/204909754-Remote-Adoption-Layer-3

[julsssark]

I use DNS resolution for Unifi and have never used option 43.