25.1.6 - DNS/DHCP best practice

[Monviech (Cedrik)]

The dnsmasq upstream documentation states the expected setup size without issues is 1000 clients, and with some tweaks a bit higher because they are conservative.

Though I would choose KEA if its a big school with lots of clients.

[Patrick M. Hausen]

KEA + HA.

[meyergru]

Still Kea is missing most of the IANA DHCP options at this time - at least in the GUI. There are some that are needed, like WPAD or vendor option 43 for Unifi. Also, some others for VoIP. You cannot "add" them via add-on config files, like with ISC DHCP, but only create your own, "full" manual configuration.

ISC DCHP and DNSmasq offer those in OpnSense, via the GUI.

[kasper93]

I believe it's unbound because when running a nslookup on my windows machine to a host that is in unbound's overrides, it times out twice before finally succeeding, suggesting unbound is choking on...something because it's a local lookup to unbound.

I'm seeing the same thing. I think current documentation is incomplete in a way of setting up this unbound to dnsmasq forward. And in fact I don't even see how it suppose to work in practice. Symptoms are like @Unspec described, timeouts and generally instability, it sometimes works, other times does not. It queries unbound multiple times, also with host.lan.internal.lan.internal.

If you think about it, unless I'm missing something it is lucky it even manages to return anything sometimes, breaking recursion.

If dnsmasq dns is set on alternative port, it will forward queries back to unbound which is main dns server. Unbound then sees that this query should be forwarded (back) to dnsmasq, which ask unbound again... and we get infinite recursion. I hope I missed something in configuration, because as it stand now it hardly can work like that.

I'm still confused about this one. Can someone explain how should a infinite recursion of dns resolution between unbound and dnsmasq prevented?

[meyergru]

By doing it like so:

1. Unbound is your main DNS resolver. It either resolves internet DNS by itself, working as a resolving DNS or you configure it to use an upstream server, like 8.8.8.8 via normal DNS or DNS-over-TLS. You also tell it to "Do not forward private reverse lookups". The import part is that you instruct it to forward specific domains, namely, you private domains, to 127.0.0.1:53053. This includes the reverse domains, say "168.192.in-addr.arpa".

2. You configure DNSmasq to run on port 53053 and set it up to resolve your internal domains, it will use the system name servers as upstream servers. These do not even have to use 127.0.0.1 (Unbound).

Thus, regular queries go to Unbound first and are either forwarded to DNSmasq (if they match fordwarded domains) or resolved by Unbound.
Because the forwarded, local domains can be resolved by DNSmasq, you will either get an IP or an NXDOMAIN. And since DNSmasq is only ever asked for internal domains (by Unbound only), its upstream server will never get used, even if it is Unbound by accident.

[cookiemonster]

By doing it like so:

1. Unbound is your main DNS resolver. It either resolves internet DNS by itself, working as a resolving DNS or you configure it to use an upstream server, like 8.8.8.8 via normal DNS or DNS-over-TLS. You also tell it to "Do not forward private reverse lookups". The import part is that you instruct it to forward specific domains, namely, you private domains, to 127.0.0.1:53053. This includes the reverse domains, say "168.192.in-addr.arpa".

2. You configure DNSmasq to run on port 53053 and set it up to resolve your internal domains, it will use the system name servers as upstream servers. These do not even have to use 127.0.0.1 (Unbound).

Thus, regular queries go to Unbound first and are either forwarded to DNSmasq (if they match fordwarded domains) or resolved by Unbound.
Because the forwarded, local domains can be resolved by DNSmasq, you will either get an IP or an NXDOMAIN. And since DNSmasq is only ever asked for internal domains (by Unbound only), its upstream server will never get used, even if it is Unbound by accident.

I've been watching this thinking how I'll be going when the time comes. So far I'm settled on continuing how I am i.e. ISC + Unbound (no IPv6).
This succint overview is very helpful, should make it to the docs. Thanks @meyergru for such a good explanation.

[RutgerDiehard]

Great explanation, many thanks @meyergru.

One thing I can't find for Unbound is:

You also tell it to "Do not forward private reverse lookups".

Please tell me where this setting is.

[meyergru]

Sorry, I meant on DNSmasqs "general" tab.

[Ground_0]

By doing it like so:

This includes the reverse domains, say "168.192.in-addr.arpa".

Here's a stupid question (from a not-so-smart-person).
This is one point that the documentation is not completely clear about. I realize that in-addr.arpa is a domain associated with reverse lookups, but are you (and the documentation) offering it as a theoretical example, or should one actually enter it verbatim according to the docs?
For instance, the docs suggest using 1.168.192.in-addr.arpa as well as lan.internal..
I have been using the name of my actual local domain in these fields.
So are in-addr.arpa and/or lan.internal actually recognized by OPNsense as "the local, internal network"?

[meyergru]

OpnSense does not "recognize" those in that they do anything special with them, Deciso just follows the standards in their recommendations.
The DNS software underlying OpnSense will do so as well. So, if you follow these recommendations, it will most probably work.

The .arpa TLD explicitely has in-addr.arpa defined for the purpose of reverse lookups (just google it). Thus, this is a standard. However, which sub-domain you delegate is mainly dependend on what RFC1918 subnets you use. You can also delegate to 168.192.in-addr.arpa if you use multiple /24 subnets or 2.168.192.in-addr.arpa if you use only 192.168.2.0/24.

The ".internal" TLD is an DNS TLD that has been recommended by IANA, but is not yet approved, so you can use it for your own VLAN subdomains. Formerly, .home.arpa was often used for such purposes.

[Ground_0]

OpnSense does not "recognize" those in that they do anything special with them, Deciso just follows the standards in their recommendations.
The DNS software underlying OpnSense will do so as well. So, if you follow these recommendations, it will most probably work.

The .arpa TLD explicitely has in-addr.arpa defined for the purpose of reverse lookups (just google it). Thus, this is a standard. However, which sub-domain you delegate is mainly dependend on what RFC1918 subnets you use. You can also delegate to 168.192.in-addr.arpa if you use multiple /24 subnets or 2.168.192.in-addr.arpa if you use only 192.168.2.0/24.

Thank you, this is very clear to me now.

The ".internal" TLD is an DNS TLD that has been recommended by IANA, but is not yet approved, so you can use it for your own VLAN subdomains. Formerly, .home.arpa was often used for such purposes.

Ok, I find myself confused about this, again.
If I have no VLANs and I am simply using the OPNsense default ".localdomain" for my LAN, would you recommend I be using .localdomain or lan.internal?

[meyergru]

You can use any domain you like, even .com, if you accept that this masks "real" .com domains.

[gspannu]

Ok, I find myself confused about this, again.
If I have no VLANs and I am simply using the OPNsense default ".localdomain" for my LAN, would you recommend I be using .localdomain or lan.internal?

You can use either of the two... both will work.

[Ground_0]

Thank you meyergru and gspannu for the straightforward answers, they help immensely for my style of connecting the dots.
And, thank you for your patience; I do realize I don't really belong here and I appreciate your kind assistance.
Although I can gather facts and knowledge, I freely admit that I lack the level of intelligence for a deep insight into networking.
Trying not to be a help vampire.

[gspannu]

Thank you meyergru and gspannu for the straightforward answers, they help immensely for my style of connecting the dots.
And, thank you for your patience; I do realize I don't really belong here and I appreciate your kind assistance.
Although I can gather facts and knowledge, I freely admit that I lack the level of intelligence for a deep insight into networking.
Trying not to be a help vampire.

Anyone who uses OPNsense belongs here... let no one make you think otherwise !