Hi everybody,
honestly I am now a bit confused and need some advice.
In the past I was using unbound for DNS and ISC DHPC for DHCP.
I defined private IPV4 subnets in ISC-DHCP for my vlans.
For IPV6 i set DHCPv6 in my WAN interface (PPPOE - Deutsche Telekom) and in my LAN interfaces just tracked the WAN and set a prefix id.
Some time then, I switched to KEA for DHCPv4 (as it was supposed to be the new standard). Created my subnets there, set fixed IPs etc.
Now with Kea IPv6 and also everything in DNSMASQ: Which is the preferred setup?
Is it only DNSMASQ instead of ISC + KEA + UNBOUND?
The goal for 25.7: Dnsmasq DHCP/RA for small and medium deployments and Kea/Router Advertisements (radvd) for bigger deployments (requiring seamless HA support).
The docs are in the works, but we also need a bit more code glue for 25.7 and 26.1 to make the most of these transitions.
But TLDR: nothing changes for users. Anyone can use what they want. Even ISC for the forseeable future (2-5 years).
Cheers,
Franco
Unclear and contradictory ideas in the management of DHCP in Opnsense by the developers. Some time ago, Kea DHCP was included in Opnsense because, as they said, ISC DHCP was abandoned and Kea was its replacement. However, that inclusion was partial and is resolved today by including Kea DHCPv6, which would complete the migration. But it turns out that now Kea DHCP is also not valid, and in the near future, Dnsmasq DHCP will be used by default. The bottom line is that users no longer know what to expect on an issue that isn't even that complicated.
> Unclear and contradictory ideas in the management of DHCP in Opnsense by the developers.
That's unfair and untrue. ISC discontinued DHCPD and left everyone with Kea, but it's not as good as DHCPD still is. Period.
Cheers,
Franco
The docs are up to date with suggestions and setup examples:
https://docs.opnsense.org/manual/dhcp.html
https://docs.opnsense.org/manual/dnsmasq.html
OK, so this would mean before changing my setup waiting for 25.7. correct?
So if I understand right, then DNS would be still Unbound on port 53 and DNSMASQ on another port to answer queries for local hostnames?
And regarding ISC: I can dissable ISC for IPv4. But how does this work for IPv6? Can only view the leases there but find no further options.
You can still run your current setup for a while there is no immediate need to change it.
It's correct that you would run dnsmasq and Unbound at the same time on different ports. That's whats described in the setup example in the documentation.
OK thanks.
And just one (I think now rather stupid question).
I was always thinking, I am running a DHCPv6 server on my Opnsense.
But after a short ChatGPT consultation, I think I understood now that without the manual IPv6 configuration of the interface, I am only using router advertisement and the clients are using SLAAC to generate their IP. Is this correct?
This would explain why I cannot deactivate it and the only menu option below ISC DHCPv6 are the "Leases".
If I understood this right, I can ignore DHCPv6 in my current setup....?
In the most basic IPv6 setup you only need Router Advertisements, these will allow your clients to generate a SLAAC address, the default gateway, and you can also get a DNS server option.
DHCPv6 is when you want to hand specific addresses and options to the clients that RA cannot do.
So for you probably only RA is important.
Quote from: franco on May 08, 2025, 04:01:51 PM> Unclear and contradictory ideas in the management of DHCP in Opnsense by the developers.
That's unfair and untrue. ISC discontinued DHCPD and left everyone with Kea, but it's not as good as DHCPD still is. Period.
Cheers,
Franco
100% agree with Franco.
The comment "Unclear and contradictory ideas in the management of DHCP in Opnsense by the developers" is
not justified and rude to the development team.
The dev team tries very hard to support both personal users & large users - and each has different requirements.
ISC discontinued DHCPD; and a good choice at that time was Kea.
However, Kea is not very well suited for smaller users; and neither did Kea really develop into a full fledged dnsmasq alternative.
What we have today is a plethora of choices:
- ISC (as is)
- dnsmasq (with dhcpd now!)
- Kea (with IPv6 now!)
Unbound continues to work as is.
What could be better? Everyone has a choice ! Use whatever you fancy and whatever works best for your use case/ environment.
The fact that dnsmasq will be the default in 25.7 is really a non-issue. Everything that existed is still being supported.
Thank you @franco, @monviech(cedrik), @patrick and all contributors for this wonderful software and your hard work.
Quote from: Monviech (Cedrik) on May 08, 2025, 04:50:24 PMIn the most basic IPv6 setup you only need Router Advertisements, these will allow your clients to generate a SLAAC address, the default gateway, and you can also get a DNS server option.
DHCPv6 is when you want to hand specific addresses and options to the clients that RA cannot do.
So for you probably only RA is important.
That makes sense, I'm guessing it would work for AT&T Prefix delegation scenarios like this https://github.com/lilchancep/att-pfsense-ipv6 (https://github.com/lilchancep/att-pfsense-ipv6), right?
Prefix delegation downstream is only possible with ISC DHCPD or Kea. Dnsmasq does not have the support. Your router could still consume a PD with Dnsmasq DHCP but cannot pass a prefix on. That one of the reasons why we believe Dnsmasq works well for small and medium setups, but an alternative with Kea makes sense in these cases. It depends on the requirements in the end.
Cheers,
Franco
In that case I will have to look into at least a limited pre-defined set of vendor options for Kea ...
@gspannu I'd upvote your post if I could :)
I read this thread and I still don't understand few things.
I use Unbound as DNS and don't want to change to Dnsmasq.
I'm all in favor to drop ISC DHCP and migrate to Kea but I need Router Advertisement support for IPV6.
What are my options ?
Quote from: bugacha on May 08, 2025, 05:42:49 PMI read this thread and I still don't understand few things.
I use Unbound as DNS and don't want to change to Dnsmasq.
I'm all in favor to drop ISC DHCP and migrate to Kea but I need Router Advertisement support for IPV6.
What are my options ?
That is easy, you use:
- Services/Unbound DNS
- Services/Kea DHCPv4
- Services/Router Advertisements
You don't need a DHCP server for RA. That is covered by the router advertisement service.
See https://docs.opnsense.org/manual/dhcp.html
Quote from: Monviech (Cedrik) on May 08, 2025, 05:48:40 PMQuote from: bugacha on May 08, 2025, 05:42:49 PMI read this thread and I still don't understand few things.
I use Unbound as DNS and don't want to change to Dnsmasq.
I'm all in favor to drop ISC DHCP and migrate to Kea but I need Router Advertisement support for IPV6.
What are my options ?
That is easy, you use:
- Services/Unbound DNS
- Services/Kea DHCPv4
- Services/Router Advertisements
Apologies, I also use DHCPv6 and RA runs in Assisted mode today.
It's a standard setup, I get IPV6 prefix from ISP and I use DHCPv6 to assign IPs from one of the subnets.
Here is an updated technical overview of IPv6 in OPNsense:
https://docs.opnsense.org/manual/ipv6.html
Wait, so for Dnsmasq DHCP, are we not supposed to rely on radvd anymore and instead need to use the Dnsqmasq RA function?
No, you can mix and match these services however you want.
You can also mix dnsmasq dhcpv6 with radvd.
Quote from: Monviech (Cedrik) on May 09, 2025, 06:41:15 AMNo, you can mix and match these services however you want.
You can also mix dnsmasq dhcpv6 with radvd.
Yep, figured that out after some testing.
Unbound lookups for local hostnames is pretty broken for DHCP reservations though (https://github.com/opnsense/core/issues/8612). dnsmasq is definitely not ready for the limelight yet, at least not in opnsense.
I would not say its broken, I would say now that it is released there are more testers that find out all the edge cases that can still be improved.
Thanks for reporting something :)
Quote from: Monviech (Cedrik) on May 09, 2025, 07:25:15 AMI would not say its broken, I would say now that it is released there are more testers that find out all the edge cases that can still be improved.
Thanks for reporting something :)
Seems like a different way of saying it's broken :)
Overall, since switching, my DNS queries for local services have been extremely flakey - it almost feels like dnsmasq is crumpling under pressure or something with unbound blasting it lookup requests.
I have cache for dnsmasq disabled since it seems unnecessary (it's all local lookups anyhow), don't know if that's what killing dnsmasq. In theory it shouldn't be since unbound has its own cache, but given how strange things are with dnsmasq, who knows.
You should try to find out where your dns queries get stuck.
I think Unbound does not cache queries it forwards to other DNS servers, and Dnsmasq should not need to cache its own DNS entries because they are static.
I'm just a bit surprised because I run dnsmasq fully features like in the docs since 2 months now and did not experience anything strange. Though I also do not query local services quite as much as you might do. So saying its broken is kinda not true.
Maybe our setups are quite different.
I've been happy with KEA but I am looking forward to trying out dnsmasq with IPv4. I read the OPNsense dnsmasq docs and the examples are really helpful. However, it is not clear how to setup a subnet that has only DHCP reservations and no dynamic addresses. I assume I set up a subnet and create Hosts entries for the reservations. I setup the subnet with mode=static but starting address is a required field. What should the starting address be? I tried to enter the subnet in CIDR format but it wants an actual address.
One question regarding DHCPv6 and RA.
In my LAN interface I track my WAN interface for IPv6 and just define a prefix for my 56-subnet I get from my provider.
If I then do not select the manual configuration (Allow manual adjustment of DHCPv6 and Router Advertisements).
What are then the defaults for DHCPv6 and RA?
My challenge is that, when the "manual configuration" is not ticked, I do not even see the Service->RA or the Service->ISC-DHCPv6 settings showing up.
Quote from: julsssark on May 09, 2025, 09:54:09 AMI've been happy with KEA but I am looking forward to trying out dnsmasq with IPv4. I read the OPNsense dnsmasq docs and the examples are really helpful. However, it is not clear how to setup a subnet that has only DHCP reservations and no dynamic addresses. I assume I set up a subnet and create Hosts entries for the reservations. I setup the subnet with mode=static but starting address is a required field. What should the starting address be? I tried to enter the subnet in CIDR format but it wants an actual address.
The starting address can be anything from which point on you want to supply addresses. It cannot be a range or a subnet.
E.g. if your network is 192.168.1.0/24 and you want to supply addresses from 192.168.1.100 on, that is your starting address for the static pool.
Quote from: gstyle on May 09, 2025, 10:23:24 AMOne question regarding DHCPv6 and RA.
In my LAN interface I track my WAN interface for IPv6 and just define a prefix for my 56-subnet I get from my provider.
If I then do not select the manual configuration (Allow manual adjustment of DHCPv6 and Router Advertisements).
What are then the defaults for DHCPv6 and RA?
My challenge is that, when the "manual configuration" is not ticked, I do not even see the Service->RA or the Service->ISC-DHCPv6 settings showing up.
I have set up RA like this with dnsmasq:
Interfaces: LAN
IPv6 Configuration: Track Interface
Services -> Router Advertisements -> LAN
Router Advertisements - Disabled
Then in Dnsmasq it is just like this:
https://docs.opnsense.org/manual/dnsmasq.html#dhcpv6-and-router-advertisements
With a lot of effort due to my big number of static reservations, I have now made the shift from ISC DHCP / Unbound to DNSmasq "only". Radvd is still in effect, since I use no DHCPv6. Thanks to ChatGPT for helping me to write the programs to extract the CSVs from the configuration XML for both the static reservations plus the DNS mappings and aliases.
Cudos to Cedrik: you can even import CSVs on top of another and the "last one wins" (i.e. there are no duplicates), so you can now have a static reservation with aliases, if you import them in correct order.
Just three observations for you, @Monviech:
1. It is unfortunate that the "DHCP options" are that complex to set up. Effectively, you need at least 6 lines for every (V)LAN / subnet, which soon adds up and gets confusing:
- router/gateway
- netmask
- DNS server (which, according to the config file, has a default of 0.0.0.0, thus could be left out in most cases)
- NTP server
- DNS domain
- DNS search list
Being able to use "Any" interface and thus having a kind of inheritance could reduce the numer of entries, yet make it even more confusing (who wants to inherit a netmask setting?).
This was much easier in ISC DHCP, because often-used options like these (and some more) were summarized nicely on one page per interface. Maybe tabs for each interface would be a nice addition.
2. There are some options completely missing, without the possibility to even configure them as custom options, like:
- time-server (4)
- wpad (252)
- Unifi controller (43 with a specific format for the IP)
These options should be added to the list of available DHCP options. Also, a "custom" option like in ISC DHCP would be appreciated for cases like these.
3. I used the "log-server (7)" option with a DNS name instead of an IP address, only to find that DNSmasq would fail at that. This works with ISC DHCP by the "IP address or host" type in the custom options.
Quote from: meyergru on May 09, 2025, 10:53:01 AM2. There are some options completely missing, without the possibility to even configure them as custom options, like:
- time-server (4)
- wpad (252)
- Unifi controller (43 with a specific format for the IP)
These options should be added to the list of available DHCP options. Also, a "custom" option like in ISC DHCP would be appreciated for cases like these.
So the current state is that neither Kea nor DNSmasq support vendor options at all? That comes as a bit of a shock, because I assumed that support for these might be one reason to prefer DNSmasq.
Yes, they are absolutely necessary in production. Luckily we have almost a year to go before ISC DHCP will be retired.
Meanwhile I found this presentation by ISC:
https://www.isc.org/docs/2023kea_custom_options.pdf
It's fairly recent (2023) and it does not look to be that much of a deal to implement vendor options (43) in Kea in OPNsense. But I might be missing something. I mean, yes, that's a lot of verbiage for a seemingly simple task, but nothing that cannot be easily rendered from Jinja templates.
Kind regards,
Patrick
1. There is an interface filter which is persistent across all tabs of dnsmasq. It also auto adds the interface to new options or ranges if selected.
2.For missing options just open an issue or a PR like this here. Its very simple to add:
https://github.com/opnsense/core/pull/8613
3. Some options might have a different syntax in dnsmasq, we did not test every option. Try to search the net for hints if others have issues with option 7 like you do.
1. I saw that and still find it confusing, sorry.
2. While I could do that to amend it to the comprehensive list at https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml plus specific custom options, there is something missing here, see next...
3. My point is that the DHCP options are effectively typed, yet in the DNSmasq version, there are no types, just a string input field. For ISC DHCP, the predefined fields in the web UI can have validations and for the custom option, you can even choose the type. For example, for the Unifi option, you need a "string" value written something like: "01:04:c0:a8:06:14". So, ideally we should either be able to select a type or the predefined options should "know" what type to use. Plus, there is no way of representing binary strings at all, AFAICT.
Also, there is no way besides code changes to even have yet missing or custom options (224-254). As Patrick noted: no feature parity.
Please open issues on github that explain what is missing for you so we can evaluate if its possible to add it.
Quote from: Monviech (Cedrik) on May 09, 2025, 10:36:25 AME.g. if your network is 192.168.1.0/24 and you want to supply addresses from 192.168.1.100 on, that is your starting address for the static pool.
Thank you!
Done (https://github.com/opnsense/core/issues/8620). I think these issues are linked closely, because an ideal solution would have:
1. A tab for any subnet with the most-used options (strongly typed and with the potential to use inputs for both IPv4 and IPv6, like the DNS search list).
2. The complete range of DHCP options from https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml and its DHCPv6 counterparts with strong types, which e.g. includes the possibility to enter binary strings.
3. A means to include vendor specific options, too. in order to come closer to feature-parity with ISC DHCP.
With the dhcp options, there might also be limitations by what dnsmasq actually offers:
-w, --help
Display all command-line options. --help dhcp will display known DHCPv4 configuration options, and --help dhcp6 will display DHCPv6 options.
Right now we read known options with a script, which populates options and options6.
https://github.com/opnsense/core/blob/master/src/opnsense/scripts/dns/dnsmasq_dhcp_options.py
Effectively it does this:
dnsmasq --help dhcp
dnsmasq --help dhcp6
And it will return a list of all supported options.
A few words from me on the topic of DHCP. My introduction to OPNsense was ISC DHCP, which I've had very positive experiences with.
Today, however, I tried DNSmasq and was able to set up the appropriate domains, DHCP ranges, and DHCP options for my subnets following the OPNsense tutorial. A positive point is that the wired and wireless network devices (in different subnets) take too long for the DHCP process, whereas with ISC everything runs super quickly and smoothly.
I noticed, especially with my smartphone, that WiFi calling doesn't work with DNSmasq DHCP, but it does work with KEA and ISC DHCP. In general, I noticed that configuring DNSmasq is much more complex than with ISC und KEA and I have to agree with meyergru on that point.
Therefore, I seriously wonder whether ISC DHCP will continue to be usable despite its EOL status, albeit in the form of optional plugins? I also have the question of why HA will be mandatory for KEA DHCP in the future, or have I misunderstood something? Franco said that KEA DHCP is intended for medium to large companies, but why not simply leave HA optional so that regular users can also use KEA DHCP if they want?
In summary, the following question for @Franco:
1. Will ISC DHCP continue to be usable (via optional plugins) despite its EOL status?
2. Will KEA DHCP be usable for regular users even without HA?
3. DNSmasq is already active by default after a fresh installation of OPNsense. Will it be improved (and simplified) in the future?
I did not look at DNSmasq manual pages until now. The relevant part about and typing is this:
QuoteAn option without data is valid, and includes just the option without data. (There is only one option with a zero length data field currently defined for DHCPv4, 80:rapid commit, so this feature is not very useful in practice). Options for which dnsmasq normally provides default values can be ommitted by defining the option with no data. These are netmask, broadcast, router, DNS server, domainname and hostname. Thus, for DHCPv4 -- dhcp-option = option:router will result in no router option being sent, rather than the default of the host on which dnsmasq is running. For DHCPv6, the same is true of the options DNS server and refresh time.
Data types allowed are comma separated dotted-quad IPv4 addresses, []-wrapped IPv6 addresses, a decimal number, colon-separated hex digits and a text string. If the optional tags are given then this option is only sent when all the tags are matched.
Special processing is done on a text argument for option 119, to conform with RFC 3397. Text or dotted-quad IP addresses as arguments to option 120 are handled as per RFC 3361. Dotted-quad IP addresses which are followed by a slash and then a netmask size are encoded as described in RFC 3442.
IPv6 options are specified using the option6: keyword, followed by the option number or option name. The IPv6 option name space is disjoint from the IPv4 option name space. IPv6 addresses in options must be bracketed with square brackets, eg. --dhcp-option=option6:ntp-server,[1234::56]. For IPv6, [::] means "the global address of the machine running dnsmasq", whilst [fd00::] is replaced with the ULA, if it exists, and [fe80::] with the link-local address.
Be careful: data-type suitability for the option number sent is not checked. It is quite possible to persuade dnsmasq to generate illegal DHCP packets with injudicious use of this flag. When the value is a decimal number, dnsmasq must determine how large the data item is. It does this by examining the option number and/or the value, but can be overridden by appending a single letter flag as follows: b = one byte, s = two bytes, i = four bytes. This is mainly useful with encapsulated vendor class options (see below) where dnsmasq cannot determine data size from the option number. Option data which consists solely of periods and digits will be interpreted by dnsmasq as an IP address, and inserted into an option as such. To force a literal string, use quotes. For instance when using option 66 to send a literal IP address as TFTP server name, it is necessary to do --dhcp-option=66,"1.2.3.4".
Encapsulated Vendor-class options may also be specified (IPv4 only) using --dhcp-option: for instance --dhcp-option=vendor:PXEClient,1,0.0.0.0 sends the encapsulated vendor class-specific option "mftp-address=0.0.0.0" to any client whose vendor-class matches "PXEClient". The vendor-class matching is substring based (see --dhcp-vendorclass for details). If a vendor-class option (number 60) is sent by dnsmasq, then that is used for selecting encapsulated options in preference to any sent by the client. It is possible to omit the vendorclass completely; --dhcp-option=vendor:,1,0.0.0.0 in which case the encapsulated option is always sent.
Options may be encapsulated (IPv4 only) within other options: for instance --dhcp-option=encap:175, 190, iscsi-client0 will send option 175, within which is the option 190. If multiple options are given which are encapsulated with the same option number then they will be correctly combined into one encapsulated option. encap: and vendor: may not both be set in the same --dhcp-option.
The final variant on encapsulated options is "Vendor-Identifying Vendor Options" as specified by RFC3925. These are denoted like this: --dhcp-option=vi-encap:2, 10, text The number in the vi-encap: section is the IANA enterprise number used to identify this option. This form of encapsulation is supported in IPv6.
The address 0.0.0.0 is not treated specially in encapsulated options.
So first, you can set any option by number or by name - while it is true that there is an (incomplete) list of named options, you actually set these via numbers only, like with the dns-search-list (119):
...
dhcp-option-force=tag:igc0_vlan1,119,lan;iot;dmz;guest
...
So, obviously, as a bare minimum, any vendor-specific option could as well be specified numerically, because DNSmasq itself admittedly does know jack about the types of the parameters. I bet you can use (in fact I included that in /usr/local/etc/dnsmasq.conf.d/unifi.conf and verified it to work as expected):
dhcp-option-force=tag:igc0_vlan1,43,01:04:c0:a8:06:14
As for the missing "known" options, you could prepend the program output with missing ones in textual form, like in the dnsmasq output:
4 time-server
43 unifi-server
252 wpad-url
Matter-of-fact, the names are only used in the GUI and not carried over to the actual config.
In order to help the user with a correct type and validation, you would need a third column describing what can/should be used, like:
1 netmask netmask
2 time-offet number
3 router ip-addr
4 time-server ip-addr
6 dns-server ip-addr-list
...
43 unifi-server binary-string
...
252 wpad-url url
...
In order to support custom options, you could then just offer a table input with three columns "option-number", "option-name" and a "option-type" dropdown, which would be added to this to augment the web UI. You could also allow duplicates, e.g. option 43 is "vendor specific", so there might be other variants like " 43 vendor-xy ip-addr-list" on top of my unifi example. The option-name would be the selector for the validation, then.
Appending missing options to the output should be doable as we already do that with the captive server option.
Small tickets on github with clear scope can be worked on more efficiently.
I have problems getting ipv6 working with dnsmasq. RA is active and pool settings are set, but i don't get dnsv6 nor even a ipv6 address on my iPhone. I plan to use dhcpv6 + slaac :/
Edit: got that working by disable the general RA setting...
But now a new issue: how do i get reverse lookups working with dnsmasq?
Quote from: Monviech (Cedrik) on May 09, 2025, 09:06:55 AMYou should try to find out where your dns queries get stuck.
I think Unbound does not cache queries it forwards to other DNS servers, and Dnsmasq should not need to cache its own DNS entries because they are static.
I'm just a bit surprised because I run dnsmasq fully features like in the docs since 2 months now and did not experience anything strange. Though I also do not query local services quite as much as you might do. So saying its broken is kinda not true.
Maybe our setups are quite different.
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.
Edit: Once the query forwarding is turned off, it's able to resolve things better but obviously only for things in unbound's overrides. That said, I will be unable to test this further as I've fully abandoned dnsmasq and do not intend on returning to it in the near future, it's far too experimental for my tastes and makes my internal network communications extremely flakey.
Quote from: dMopp on May 09, 2025, 07:25:03 PMI have problems getting ipv6 working with dnsmasq. RA is active and pool settings are set, but i don't get dnsv6 nor even a ipv6 address on my iPhone. I plan to use dhcpv6 + slaac :/
Edit: got that working by disable the general RA setting...
But now a new issue: how do i get reverse lookups working with dnsmasq?
Double check to make sure you're not also running radvd (Services -> Router Advertisements) when trying to run dnsmasq's RA implementation.
Quote from: Monviech (Cedrik) on May 09, 2025, 05:42:28 PMAppending missing options to the output should be doable as we already do that with the captive server option.
Small tickets on github with clear scope can be worked on more efficiently.
I know. I created a pull request to fix two problems: https://github.com/opnsense/core/pull/8626
If someone wants to try it, you can change /usr/local/opnsense/scripts/dns/dnsmasq_dhcp_options.py and then call "service configd restart" to populate the new DHCP options.
Quote from: PhoenixRider on May 09, 2025, 04:36:58 PMIn summary, the following question for @Franco:
1. Will ISC DHCP continue to be usable (via optional plugins) despite its EOL status?
2. Will KEA DHCP be usable for regular users even without HA?
3. DNSmasq is already active by default after a fresh installation of OPNsense. Will it be improved (and simplified) in the future?
While I believe the answers to 1 and 2 are yes and yes, I will wait for Franco to confirm.
Regarding the third, I have a supplementary question. Will the documentation contain concise instructions for turning DNSmasq off in a new installation, eradicating its presence, so new installations are more easily switched to Kea? I did not see that there during a quick look.
This is of course secondary to the core functionality, but I was wondering if at some point DNSmasq and/or Kea might gain the Status, State and Lease Type columns that are present in ISC? I rather like those, especially the green/red Status indicator.
Higher priority (for me, at least) is being able to set DHCP Option 43 for my UniFi console. I appreciate that there's focus on it already in this thread :)
Quote from: franco on May 08, 2025, 03:59:38 PMThe goal for 25.7: Dnsmasq DHCP/RA for small and medium deployments and Kea/Router Advertisements (radvd) for bigger deployments (requiring seamless HA support).
The docs are in the works, but we also need a bit more code glue for 25.7 and 26.1 to make the most of these transitions.
But TLDR: nothing changes for users. Anyone can use what they want. Even ISC for the forseeable future (2-5 years).
Cheers,
Franco
I would like to have a smart migration path from ISC to xy in opnsense as I have many MAC addresses statically mapped in ISC ;-)
- maybe as ontime script from console...
There is. I just converted my system from isc to kea.
For ipv4 this tool was VERY helpfull: https://github.com/EasyG0ing1/Migration/ (https://github.com/EasyG0ing1/Migration/)
For static ipv6 I had to enter them manually, but worked fine also.
Migration took only about 15 minutes because of this manual part for v6. I only use dynamic on the guest network.
I do not use DNSmasq, I only use BIND. (Opnsense - KEA DHCP4 and DHCP6 with Router Advertisements (radvd), and for DNS - Adguard Home -> bind on opnsense)
Quote from: dMopp on May 09, 2025, 07:25:03 PMBut now a new issue: how do i get reverse lookups working with dnsmasq?
For reverse dns, I added an 2 additional forwards to Services: Unbound DNS: Query Forwarding
I use the 10.0.0.0/8 for my local addresses, so
<enabled>1</enabled>,
<domain>10.in-addr.arpa</domain>
<server>127.0.0.1</server>
<port>53053</port>
I did the same for my ipv6, redacted:
<domain>x.x.x.x.x.x.x.x.x.x.x.3.0.6.2.ip6.arpa</domain>
<server>127.0.0.1</server>
<port>53053</port>
@Issac thanks
https://github.com/opnsense/docs/issues/724
Quote from: meyergru on May 09, 2025, 10:53:01 AMWith a lot of effort due to my big number of static reservations, I have now made the shift from ISC DHCP / Unbound to DNSmasq "only". Radvd is still in effect, since I use no DHCPv6. Thanks to ChatGPT for helping me to write the programs to extract the CSVs from the configuration XML for both the static reservations plus the DNS mappings and aliases.
@meyergru Any chance you could make these scripts available via a github repo?
I am currently using ISC DHCP / Unbound myself (only v4 - no v6 at all) and I have been quite happy with it. Although the fact that ISC is no longer maintained is a pitty and makes me slightly nervous.
However, I do have a high number of static mappings (as you have). I use around 20 VLANs, but the most mappings are distributed between 3 of them. In my Unbound I have set about 18 overrides with a select few of them having 2-3 aliases. (Thus those are not that hard to recreate manually if need to be.)
One of the very few things that irked me for years has been the problem that I couldn't set a static mapping via an API call. e.g. when creating a VM via TF (or Pulumi, or whatever tickles your fancy, or even manually), it would be great to set a static mapping and when decommissioning the same VM, remove the mapping again. Afaik a lot of services got an API (kudos to the devs), but I haven't seen anything for ISC, thus moving to dnsmasq might be a good choice.
I think to remember a few years ago, the devs were suggesting to migrate to Unbound from dnsmasq (or maybe this was just for one issue in one forum topic), but it seems now it's the other way around. I don't really mind, as long as there is some workable migration. By "workable" I mean in an automated fashion that does not require me to recreate all settings, DHCP ranges, static mappings, and whatnot manually.
On the other side, if it absolutely has to be I probably can invest 5 or 6 hours to manually to do all this. The problem is that this process is rather error prone - manual work always is.
I have also noticed that some VMs (even though they are sending a hostname) get a DHCP address (no static mapping) but are not registered in the DNS. I am not sure why this is happening, but I think this started with 25.1. Either way, moving to dnsmasq might fix that as well.
Anyway, long story short, it would be great to use scripts to migrate to test dnsmasq only. If it doesn't work as I hope, it should be fairly easy to restore a backup and just use ISC/Unbound for now...
Quote from: IsaacFL on May 10, 2025, 06:06:56 PMFor reverse dns, I added an 2 additional forwards
Oh, wait. Does this mean that you cannot use dnsmasq only (for DHCP and DNS), if you want a working reverse DNS, in which case you have to use Unbound as well?
Is anyone going to fix the version typo on the title of this thread?
Quote from: Unspec on May 09, 2025, 09:31:49 PMI 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.
Quote from: tessus on May 11, 2025, 11:59:31 PM@meyergru Any chance you could make these scripts available via a github repo?
Here is the link:
https://github.com/meyergru/iscdhcp_to_dnsmasq
As for the problems: You can do one of two things:
1. Use dnsmasq as your sole DNS service - especially for the DHCP reservations and leases. While it cannot do recursive name resolution, most people do not even need that. You could just use your system name servers and that works just fine.
2. If you absolutely want to use another DNS service for resolving internet names, you will have to configure DNSmasq and Unbound on different port and point one to the other (IDK what the official recommendation for that is), but beware of using port 5353, because that is also used by the mDNS-Repeater. There fore, I use 5454 for that.
P.S.: Instead of Unbound, you can also use os-dnscrypt-proxy in order to use DoH. There is a problem with forwarding domains to other servers that do not run on port 53, but that will soon be fixed (https://github.com/opnsense/plugins/pull/4698).
The logic behind all of this is always the same: Have one DNS service do internet resolution and one for DHCP naming (the latter being DNSmasq). The one running on port 53 is the one you are querying from your LAN. It is up to you if you plainly cascade the services or if you forward your local zones to DNSmasq - both approaches work.
There were some early problems with firewall rules not being applied after enabling the checkbox, I expect a hotfix for that (https://forum.opnsense.org/index.php?msg=237303) at some point.
Quote from: franco on May 08, 2025, 03:59:38 PMThe goal for 25.7: Dnsmasq DHCP/RA for small and medium deployments and Kea/Router Advertisements (radvd) for bigger deployments (requiring seamless HA support).
The docs are in the works, but we also need a bit more code glue for 25.7 and 26.1 to make the most of these transitions.
But TLDR: nothing changes for users. Anyone can use what they want. Even ISC for the forseeable future (2-5 years).
Cheers,
Franco
So, making the switch now to Dnsmasq DHCP/RA and Unbound mite no work as we think until 25.7 I.E. missing glue.
Quote from: nautilus7 on May 12, 2025, 12:09:24 AMIs anyone going to fix the version typo on the title of this thread?
Sorry ;)
Done
I made the switch from Kea v4 to DNSMasq v4 and everything seems to be working correctly. I have a half-dozen vlans and use clients->AdGuard->Unbound for DNS. Look ups from Unbound to DNSMasq for dynamic hosts are working. I followed the configuration example in the docs. The hardest part (and it was not a big deal) was doing the export of Kea reservations and reordering/renaming the columns so that they matched the import for DNSMasq.
Thank you OPNsense team for continuing to improve this amazing software!
Quote from: meyergru on May 13, 2025, 06:54:54 PMHere is the link:
Thanks a bunch for the scripts.
Well, my DNS setup is a bit different than probably most people have:
I use a pi-hole keepalived cluster and most VLANs must use that cluster for DNS resolution (via an outbound NAT rule). The only time the Unbound DNS is used is for local address resolution via conditional forwarding on pi-hole.
My OPNsense Unbound can theoretically also forward queries to upstream servers, but I could turn that off, since I do not use Unbound, except for local addresss resolution (standard and reverse, which is however initiated from pi-hole). No machine is using OPNsense's Unbound directly - ever.
A few dedicated machines in certain VLANs are allowed to use external DNS servers directly. All others use my pi-hole cluster even if they have set external DNS servers.
As for DoH, I am not using it - for now. I might be doing so in the future though.
So my use-case is rather easy. I need my OPNsense's DNS (whatever that might be) for local address resolution only. However, I also need reverse lookup. I think I've read that I would have to add 2 forwards to DNSmasq, which in turn would require me to run Unbound as well for the reverse lookup. This makes this simple setup less simple, because I would have to run 2 DNS services on OPNsense instead of just one.
I have to look into this before I migrate to DNSmasq.
I'm a typical OPNsense user managing a home network and a small business environment. As a non-expert network engineer, I'm genuinely grateful for how reliably and efficiently OPNsense runs. Much of this is thanks to the outstanding work of the OPNsense developers and the helpful community here in the forum.
After the deprecation of ISC DHCP, I migrated to Kea. The transition was seamless, and my setup has continued to work flawlessly ever since.
Here's what my configuration looks like:
- **Clients** receive **IPv4 addresses via Kea DHCP**.
- **IPv6 addresses** are assigned via **SLAAC** using router advertisements.
- **DNS** is handled through **AdGuardHome** (for filtering), and **Unbound** for DNS-over-TLS.
Important clients in my LAN/VLANs have **static leases** via Kea, and I use those for internal DNS assignments. Since my network doesn't undergo significant dynamic changes, I don't currently require DDNS.
That said, I'm following this discussion with interest — not because I'm facing any issues now, but because I'm thinking ahead. The deprecation of ISC DHCP seems to have triggered a broader strategic discussion about the default DHCP system in OPNsense.
My concern is whether Kea will continue to be supported and actively integrated into OPNsense, or whether it will fall to a lower priority in favor of dnsmasq — even though dnsmasq itself hasn't seen much development since 2024 and may not be as future-proof.
I'm very happy with my current setup and could certainly continue using it as-is. But I wonder: why not make Kea more accessible for small environments by focusing the GUI integration on the most common use cases? For example, DDNS support could be added via a simple checkbox to enable the Kea D2 module. The user would just enter a BIND server address and a TSIG key name — no full mapping of all Kea capabilities would be needed in the GUI.
I don't know how much development effort this would take — and that may be the limiting factor — but from a user's perspective, such a step would make Kea much more approachable and clearly position it as the forward-looking standard in OPNsense.
Is it possilble to use ISC and DNSMASQ at the same time, to facilitate a migration one VLAN interface at a time?
My setup is simple with
3no [VLAN] > ISC > Unbound
1no [VLAN] > ISC > AdGuardHome > Unbound
2no WireGuard > ISC > Unbound
Would be nice to move each VLAN individually
You have to check with
sockstat -l
if dhcpd binds to just specific or all interfaces.
In dnsmasq you can set strict interface binding in the advanced general options.
I'm using Unbound as DNS server so i can sort of use it as an adblocker, and for DHCP, i migrated to KEA
Works fine here.
Following the DHCPv4 with DNS registration example in the documentation, I have migrated from ISC IPv4 to DNSmasq on a test system.
I have unbound on port 53 pointing to DNSmasq on 53053 for local name resolution, as instructed.
It does work, however, resolving and pinging hosts on the local domain by hostname lags for a long time.
The ping time from one host to another is in the .250 ms range, but it sits there for about 10 seconds thinking about it before spitting out the results.
Opening a browser and navigating to cockpit using machine-hostname.localdomain:9090 is equally as laggy.
Anyone else experiencing this sort of behavior?
For now, ISC with Unbound is working perfectly for me on the main router, so I suppose I will keep it that way for a while.
However, if Unbound pointing to DNSmasq for local domain name resolution is the future, I hope to figure it out.
Quote from: Ground_0 on May 17, 2025, 02:28:20 PMFollowing the DHCPv4 with DNS registration example in the documentation, I have migrated from ISC IPv4 to DNSmasq on a test system.
I have unbound on port 53 pointing to DNSmasq on 53053 for local name resolution, as instructed.
It does work, however, resolving and pinging hosts by hostname lags for a long time.
The ping time from one host to another is in the .250 ms range, but it sits there for about 10 seconds thinking about it before spitting out the results.
Opening a browser and navigating to cockpit using machine-hostname.localdomain:9090 is equally as laggy.
Anyone else experiencing this sort of behavior?
For now, ISC with Unbound is working perfectly for me on the main router, so I suppose I will keep it that way for a while.
However, if Unbound pointing to DNSmasq for local domain name resolution is the future, I hope to figure it out.
Unbound is not going anywhere as far as i know, so why not migrate to Kea for DHCP ?
Quote from: Ground_0 on May 17, 2025, 02:28:20 PMFollowing the DHCPv4 with DNS registration example in the documentation, I have migrated from ISC IPv4 to DNSmasq on a test system.
I have unbound on port 53 pointing to DNSmasq on 53053 for local name resolution, as instructed.
It does work, however, resolving and pinging hosts by hostname lags for a long time.
The ping time from one host to another is in the .250 ms range, but it sits there for about 10 seconds thinking about it before spitting out the results.
Opening a browser and navigating to cockpit using machine-hostname.localdomain:9090 is equally as laggy.
Anyone else experiencing this sort of behavior?
For now, ISC with Unbound is working perfectly for me on the main router, so I suppose I will keep it that way for a while.
However, if Unbound pointing to DNSmasq for local domain name resolution is the future, I hope to figure it out.
Do you have any servers defined in "System -> Settings -> General -> DNS servers" ? I noticed that I had a similar issue if I didn't have server explicitly defined there.
For me, this ended up being resolved by applying the patch at:
https://github.com/opnsense/core/issues/8614#issuecomment-2866675332
After applying the patch, I did not need explicit DNS servers defined and I no longer had any timeouts doing lookups through dnsmasq.
Quote from: TeeJayD on May 17, 2025, 05:51:17 PMQuote from: Ground_0 on May 17, 2025, 02:28:20 PMFollowing the DHCPv4 with DNS registration example in the documentation, I have migrated from ISC IPv4 to DNSmasq on a test system.
I have unbound on port 53 pointing to DNSmasq on 53053 for local name resolution, as instructed.
It does work, however, resolving and pinging hosts by hostname lags for a long time.
The ping time from one host to another is in the .250 ms range, but it sits there for about 10 seconds thinking about it before spitting out the results.
Opening a browser and navigating to cockpit using machine-hostname.localdomain:9090 is equally as laggy.
Anyone else experiencing this sort of behavior?
For now, ISC with Unbound is working perfectly for me on the main router, so I suppose I will keep it that way for a while.
However, if Unbound pointing to DNSmasq for local domain name resolution is the future, I hope to figure it out.
Unbound is not going anywhere as far as i know, so why not migrate to Kea for DHCP ?
Mainly because Kea does not register the DNS names of leases, which is one aspect of ISC DHCP that made for such a seamless UX when combined with Unbound.
Quote from: Drinyth on May 17, 2025, 09:30:14 PMQuote from: Ground_0 on May 17, 2025, 02:28:20 PMFollowing the DHCPv4 with DNS registration example in the documentation, I have migrated from ISC IPv4 to DNSmasq on a test system.
I have unbound on port 53 pointing to DNSmasq on 53053 for local name resolution, as instructed.
It does work, however, resolving and pinging hosts by hostname lags for a long time.
The ping time from one host to another is in the .250 ms range, but it sits there for about 10 seconds thinking about it before spitting out the results.
Opening a browser and navigating to cockpit using machine-hostname.localdomain:9090 is equally as laggy.
Anyone else experiencing this sort of behavior?
For now, ISC with Unbound is working perfectly for me on the main router, so I suppose I will keep it that way for a while.
However, if Unbound pointing to DNSmasq for local domain name resolution is the future, I hope to figure it out.
Do you have any servers defined in "System -> Settings -> General -> DNS servers" ? I noticed that I had a similar issue if I didn't have server explicitly defined there.
For me, this ended up being resolved by applying the patch at:
https://github.com/opnsense/core/issues/8614#issuecomment-2866675332
After applying the patch, I did not need explicit DNS servers defined and I no longer had any timeouts doing lookups through dnsmasq.
I do have servers defined there, but they are ignored, as I have Unbound pointing to servers using DoT. Just to clarify, I have no problem with name resolution on the internet, it's just slow on the local domain.
I just completed migration from ISC DHCPv4 + Unbound to Dnsmasq + Unbound (as per the example in the OPNsense Guide). Unbound is the default resolver for external domains and internal ones get forwarded to Dnsmasq.
In my case I am seeing consistent timeouts on both internal and external resolutions. They do work, but only after a few seconds.
C:\>nslookup firewall.h1.home.arpa
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
Name: firewall.h1.home.arpa
Addresses: 2601:xx:xxxx:xxxx:xxxx:xxxx:xxxx:39a0 (*redacted)
192.168.1.1
C:\>nslookup opnsense.org
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
Name: opnsense.org
Addresses: 2001:1af8:2050:a001:1::1
89.149.225.137
Unbound is using a public DoT resolver (dns.quad9.net).
I see that some patches are floating around on GitHub and I think an OPNsense update is due soon, so will try again.
I'm very confused about why the external resolutions are showing this, since those shouldn't be hitting Dnsmasq at all and Unbound itself was working fine prior to migration.
Looks like a release already dropped before I wrote that.
Updated to 25.1.7 and flushed DNS caches in OPNsense. Also flushed Windows cache and did ipconfig release/renew.
Now external domains resolve normally, but internal ones not at all.
C:\>nslookup firewall.h1.home.arpa
Server: UnKnown
Address: 192.168.30.1
*** UnKnown can't find firewall.h1.home.arpa: Server failed
C:\>nslookup opnsense.org
Server: UnKnown
Address: 192.168.30.1
Non-authoritative answer:
Name: opnsense.org
Addresses: 2001:1af8:2050:a001:1::1
89.149.225.137
I tried several and this is repeatable.
Double-checking my configs...
spoke too soon- there are intermittent timeouts still on external:
C:\>nslookup starbucks.com
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
Name: starbucks.com
Address: 23.50.66.53
EDIT: the internal ones starting working again, after several minutes. No changes on my part. Looks like there is something timing related going on (?)
C:\>nslookup firewall.h1.home.arpa
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds.
Name: firewall.h1.home.arpa
Address: 192.168.1.1
I moved my issues/observations to a separate thread. https://forum.opnsense.org/index.php?topic=47278.0
Thanks!
Ok, I am slightly confused: in certain comments people say they use dnsmasq for internal resolution and unbound for external.
Just to be clear, does this mean I can use dnsmasq for internal address resolution (including reverse lookups)? Because another comment mentioned that reverse lookups would have to be forwarded to Unbound or maybe it meant a setting in Unbound has to be set. Either way, Unbound seems to be required.
As mentioned before, I currently use Unbound only for internal address resolution.
So what is it? Can dnsmasq (when used as an ISC DHCP v4 and Unbound replacement) resolve local addresses including reverse lookups?
DNS requests come into Unbound. Unbound can then forward internal DNS and internal reverse lookups to DNSmasq. The docs were updated to show that two forwards are needed from Unbound (1 for DNS and 1 for reverse lookups). I have it configured this way it is working fine.
QuoteDnsmasq DHCP/RA for small and medium deployments
What is the definition of small and medium?
What should i use for 2000 Wi-Fi devices in a school?
�
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.
KEA + HA.
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.
Quote from: kasper93 on May 12, 2025, 02:54:32 AMQuote from: Unspec on May 09, 2025, 09:31:49 PMI 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?
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.
Quote from: meyergru on May 20, 2025, 02:13:13 PMBy 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.
Great explanation, many thanks @meyergru.
One thing I can't find for Unbound is:
Quote from: meyergru on May 20, 2025, 02:13:13 PMYou also tell it to "Do not forward private reverse lookups".
Please tell me where this setting is.
Sorry, I meant on DNSmasqs "general" tab.
Quote from: meyergru on May 20, 2025, 02:13:13 PMBy 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"?
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 (https://en.wikipedia.org/wiki/Reverse_DNS_lookup) (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 (https://en.wikipedia.org/wiki/.internal), but is not yet approved, so you can use it for your own VLAN subdomains. Formerly, .home.arpa was often used for such purposes.
Quote from: meyergru on May 21, 2025, 12:44:57 PMOpnSense 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 (https://en.wikipedia.org/wiki/Reverse_DNS_lookup) (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.
QuoteThe ".internal" TLD is an DNS TLD that has been recommended by IANA (https://en.wikipedia.org/wiki/.internal), 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?
You can use any domain you like, even .com, if you accept that this masks "real" .com domains.
QuoteOk, 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.
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.
Quote from: Ground_0 on May 21, 2025, 05:10:04 PMThank 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 !
I use home.arpa for my local domain since that was purposely set aside for home networks.
Any way between the great documentation and this thread I was able to go full ipv4 and ipv6+ra with dnsmasq and it has been working wonderfully.
Quote from: gspannu on May 21, 2025, 03:57:28 PMQuoteOk, 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.
Mind you that there can be a minor downside to using "localdomain". If you want to run your own local CA - on OPNsense or anywhere else - and you also want to use a wildcard certificate for a variety of devices that for some reason cannot use a real FQDN and Letsencrypt, then ...
- *.home.arpa will work while
- *.localdomain will not work
with current browsers. There have to be at least two dots in there.
I prefer - at work just like at home - to use a subdomain of a real domain I own.
So if I own e.g. company.com, then for the internal network I use internal.company.com. I know this will never conflict with anybody else, I do not publish this domain anywhere outside on the Internet, therefore I will not have leaks of any kind ... perfect solution but for the slightly longer FQDNs.
Also *.internal.company.com works with certificates as well as with MS Active Directory. Using your official Internet domain company.com with AD leads to all sorts of unexpected constraints.
HTH,
Patrick
Quote from: Patrick M. Hausen on May 21, 2025, 09:57:22 PMQuote from: gspannu on May 21, 2025, 03:57:28 PMQuoteOk, 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.
Mind you that there can be a minor downside to using "localdomain". If you want to run your own local CA - on OPNsense or anywhere else - and you also want to use a wildcard certificate for a variety of devices that for some reason cannot use a real FQDN and Letsencrypt, then ...
- *.home.arpa will work while
- *.localdomain will not work
with current browsers. There have to be at least two dots in there.
I prefer - at work just like at home - to use a subdomain of a real domain I own.
So if I own e.g. company.com, then for the internal network I use internal.company.com. I know this will never conflict with anybody else, I do not publish this domain anywhere outside on the Internet, therefore I will not have leaks of any kind ... perfect solution but for the slightly longer FQDNs.
Also *.internal.company.com works with certificates as well as with MS Active Directory. Using your official Internet domain company.com with AD leads to all sorts of unexpected constraints.
HTH,
Patrick
Thanks for the great tip about browsers possibly having an issue with .localdomain 👍
Quote from: gspannu on May 21, 2025, 07:35:09 PMAnyone who uses OPNsense belongs here... let no one make you think otherwise !
Thank you, brother.
I apologize if I've missed something in this thread but I'm not sure how best to implement my current IPV6 DHCP setup with Kea or dnsmasq.
My current IPV6 setup is based on this guide: https://github.com/lilchancep/att-pfsense-ipv6 (https://github.com/lilchancep/att-pfsense-ipv6)
In short, when my WAN interface is configured to run a script which requests IPV6 prefixes from AT&T to be delegated for each my my vlans. Each VLAN interface uses the "Tracking" option for IPV6 to determine its delegated prefix. I believe selecting "Tracking" means that SLAAC is used to determine addresses for each device but I may be wrong. Is there a way in Kea or dnsmasq to duplicate this functionality or is it best that I sit tight until the dust settles on the changes that are being worked on?
If it works for you right now better wait for a while. No need to change anything.
Quote from: Monviech (Cedrik) on May 22, 2025, 08:28:34 PMIf it works for you right now better wait for a while. No need to change anything.
Will do, I appreciate the feedback.
Are any plans in the documentation to include as scenario where DNSMasq is alone or it is not in best practices?
Nothing planned for the documentation, but running it alone should be pretty simple. Set it on port 53 and disable Unbound.
Only thing you need to take care of are reachable DNS servers in System - Settings - General. E.g., your ISP provided ones via the DHCP option there, or manually inserted ones like google or cloudflare.
Quote from: Patrick M. Hausen on May 21, 2025, 09:57:22 PMQuote from: gspannu on May 21, 2025, 03:57:28 PMQuoteOk, 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.
Mind you that there can be a minor downside to using "localdomain". If you want to run your own local CA - on OPNsense or anywhere else - and you also want to use a wildcard certificate for a variety of devices that for some reason cannot use a real FQDN and Letsencrypt, then ...
- *.home.arpa will work while
- *.localdomain will not work
with current browsers. There have to be at least two dots in there.
I prefer - at work just like at home - to use a subdomain of a real domain I own.
So if I own e.g. company.com, then for the internal network I use internal.company.com. I know this will never conflict with anybody else, I do not publish this domain anywhere outside on the Internet, therefore I will not have leaks of any kind ... perfect solution but for the slightly longer FQDNs.
Also *.internal.company.com works with certificates as well as with MS Active Directory. Using your official Internet domain company.com with AD leads to all sorts of unexpected constraints.
HTH,
Patrick
Hello, so that's why, because i use "localdomain", and if i leave on Macintosh IPv6 as "automatic" i get dns on IPv6 losing their signatures?
I was think was a related problem of using Suricata on an working IPv6 connection (in this case with Starlink), but since i read this and also trying to use a correct configuration, that's could be the problem, also because i was thinking a Suricata issue like reported on one of this forum FAQ's, and i tried using the IPv6 option on the Mac as "only local" the signatures was getting checked correctly.
I don't know if i should continue to try using a different "localdomain" or is just a problem as described, of suricata and should start to expect as IPv6 only workinkg before OPNsense until a new update will resolve this?
Thank you.
You should be able to determine the difference between a rejected certificate vs. DNS or IP blocking caused by Suricata vs. IPv6 misconfigurations.
The symptoms of each of those are clearly discernible.
Patrick just pointed out that certificates for wildcard domains will not work if they contain just one dot, so if you want to use those, you will have to use a domain with at least two dots in them.
Your problem is not clearly stated, but does not seem to correlate to the cited post.
Quote from: meyergru on May 31, 2025, 05:58:44 PMYou should be able to determine the difference between a rejected certificate vs. DNS or IP blocking caused by Suricata vs. IPv6 misconfigurations.
The symptoms of each of those are clearly discernible.
Patrick just pointed out that certificates for wildcard domains will not work if they contain just one dot, so if you want to use those, you will have to use a domain with at least two dots in them.
Your problem is not clearly stated, but does not seem to correlate to the cited post.
Hi, thanks for your quick reply,
Can i ask discernible how? Since the IPv6 connection is working well in OPNsense?
That's what i get for the dns's checks:
(https://ibb.co/35gp0dr6)https://ibb.co/35gp0dr6 (https://ibb.co/35gp0dr6)
I can add a domain again but i would like to know before if is something i can avoid and if i should follow this advice as reported in this topic: "https://forum.opnsense.org/index.php?topic=42985.0" :
13. I do not believe in IPSs like Zenarmor, Crowdsec or Suricata, but YMMV. At least do not use Suricata on WAN, unless you are willing to sacrifice IPv6 connectivity. This is a fine example for always having a tradeoff between (perceived) security and useability. Also: If you use IPS and experience any problems, please state that in your posting - or better, disable it and test again! The same goes for any kind of blocklists: check if they are the culprit.
Thank you.
Quote from: meyergru on September 23, 2024, 10:22:11 AM13. I do not believe in IPSs like Zenarmor, Crowdsec or Suricata, but YMMV. At least do not use Suricata on WAN, unless you are willing to sacrifice IPv6 connectivity. This is a fine example for always having a tradeoff between (perceived) security and useability. Also: If you use IPS and experience any problems, please state that in your posting - or better, disable it and test again! The same goes for any kind of blocklists: check if they are the culprit.
(BTW this post seems that was edited after the last time i did read it.)
I still do not get what your problem is or what it has to do with wildcard certificates. The problem with just one dot can only occur when you use your own CA, because official CAs will only issue certificates for "real" domains, which always have a TLD, and thus, *.domain.tld will always have at least two dots.
What are you trying to do and what happens?
And yes, I sometimes add items to the list and clarify or extend others.
I am just trying to get DNSSEC checks going pass successfully instead of fail in checks.
And in the same context understand (why i am replying to this post), if could have wrongly set something, or is Suricata over IPv6, that is know to not function properly (as reported on the quoted post).
At the moment i am just using "localdomain" without any dots, because is not a real website, and it was expected to be reliable just for the internal LAN.
I had a domain correctly set before and i can't remember if DNSSEC over IPv6 was working fine, also now i use a new DNS resolver.
It shouldn't have nothing to do in particular with wildcards and i have replied to a post at the beginning where it was explained how to get certificates being in conflict with nothing.
I haven't found an answer to my (edge-)case yet. I have a real domain on my IPv4/IPv6 address, resolvable from outside, let's say opnsenseyay.org. This points to port 80/443 points to a server in my network via firewall rules. I want my internal clients, if they ask for something.opnsenseyay.org to get a response from Dnsmasq only (via forwarding rule Unbound per the docs). If I do this, it resolves but it takes a long time. I found out that Unbound tries both: so it queries for outside (via 1.1.1.1 in my case) AND forwards to Dnsmasq. The queries from 1.1.1.1 return NXDOMAIN (because it doesn't exist) and from Dnsmasq there is a valid response via DHCP mappings. Both are technically not wrong. How to avoid Unbound from ever asking 1.1.1.1 for this domain "opnsenseyay.org". Apparently "Query Forwarding" doesn't work as I expect. Probably my bad, but how do I solve this?
EDIT: I think maybe my issue is this https://github.com/opnsense/core/issues/8708 and should be resolved in the next release?
Quote from: meyergru on May 20, 2025, 02:13:13 PMBy 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 don't think this is working like that currently, as evident by multiple reports about it. I think it is already resolved as https://github.com/opnsense/core/issues/8708 and related changes. I will try on next release.