Hi,
when I initially started using OPNsense, I had pretty severe issues with Unbound (not important), so I switched to using Dnsmasq. After using this for a while I switched back to Unbound.
While using Dnsmasq, I was able to have aliases for local hosts just with their local name (f.ex. 'nextcloud'). After switching back to Unbound, these no longer worked and I have to put in their FQDN (f.ex. 'nextcloud.mydomain.tld') having to edit every single local alias. This was particularly unfortunate since I then also switched my locally used domain from 'home.arpa' to a real 'mydomain.tld', and I had to edit all aliases a 2nd time.
To be clear, yes of course the 'mydomain.tld' is set as the local domain for OPNsense, and name resolution (for example in an SSH session) also works just fine with just 'nextcloud', correctly resolving it as 'nextcloud.mydomain.tld' to the corresponding IP.
Is there anything I can do to make aliases work with local names (and implicit domain) again even when using unbound?
Thanks!
Creat
Your clients are supposed to add the domain to any plain hostname before querying the DNS server. They can be told the domain via DHCP.
Yes! Use both. Unbound as main DNS server and Dnsmasq for DHCP and internal DNS. Unbound asks Dnsmasq (which is running on a different port) for local domains in this scenario, works with a real domain too, have the same setup. Guide here: https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration
Note1: To make local dns resolution work for static IP's even when a client hasn't had contact with the DHCP server: you have to fill in both a Host and a Domain under Dnsmasq DNS & DHCP-Hosts
Note2: Do not forget to Check Do not forward to system defined DNS servers under Dnsmasq DNS & DHCP-General (it's in the guide too).
if you use your own BIND, and have alias doing internal resolution, and also have Overrides setup for say Unbound...
then OPNSense will use Unbound's data for the hosts you have overridden, the rest will resolve via your BIND
this is both a curse and a gift, if you have infra that needs to come up on boot, you can have the OPNSense Unbound Overrides fill-in for those parts, then the rest will come up and be completely automated...
you can API the aliases... and I'll bet you can API to Unbound's settings but I have not explored that yet
Quote from: Patrick M. Hausen on June 15, 2025, 09:16:47 PMYour clients are supposed to add the domain to any plain hostname before querying the DNS server. They can be told the domain via DHCP.
Yes I'm aware of this, and the local domain is correctly distributed to all clients (who can all resolve local names without the full TLD just fine). But it's not a client problem, but a difference in behaviour when using Dnsmasq vs. Unbount just inside OPNsense, and more specifically how aliases are being resolved. As far as I can tell, the local domain name is used correctly in all other places (as it's of course set in OPNsense, which is where DHCP gets the value from as well), like the examples I gave in the 2nd paragraph starting ith "to be clear".
It might be (and this is my guess) that OPNsense looks up anything written in an alias directly and without potentionally appending it's own 'local' domain (as a 'ping' or 'nslookup' would do). Dnsmasq might just imply the local domain when it receives just a flat name and tries to resolve that as well, while Unbound does not.
Quote from: flushell on June 15, 2025, 09:17:37 PMYes! Use both.
I really don't want to complicate my DNS setup even more by involving two DNS servers. Also, if my above guess as to why the two servers behave differently is correct, this wouldn't even help as the request would never reach that 2nd name server: If the request doesn't include 'mydomain.tld' and only consists of 'nextcloud', it wouldn't hit the forwarding rule to the secondary server that is contingent on it.
Additionally, I actually need queries to "mydomain.tld" to be forwarded to the external DNS servers (or resolved through public recursion) if the local lookup fails. This has to do with how I am currently handling IPv4 and IPV6.
Quote from: jonny5 on June 16, 2025, 03:17:17 AMif you use your own BIND, and have alias doing internal resolution, and also have Overrides setup for say Unbound...
No overrides are involved, as the IPs aren't static. That's the whole point of having aliases as DNS names, so I can properly use them in the firewall. They already do resolve correctly in all places BUT the aliases of OPNsense (and also resolve there if using Dnsmasq as DNS), hence this request.
Edit: sorry for the late reply to my on question, for some reason I wasn't opted into automatic reply notifcations for my own created topic, which I have now fixed. Again, apologies.
If you can "drill/dig -x <ip_address>" (drill or dig, whichever you have installed) or "drill/dig <hostname>.<localdomain>.<tld>" and get expected values back, then yes your hosts are getting DNS set correctly and your OPNSense 'should' be able to resolve these via the Alias system
If that isn't working, you might want to make sure that your OPNSense is using the DNS you are, you can tell the OPNSense not to use its internal DNS system and use whatever you have set in System -> Settings -> General by check marking the "Do not use the local DNS service as a nameserver for this system" option on that page. In short, I'm not really sure why your host can resolve hosts on your network but the OPNSense seems to be struggling there for you - I do know that I've found IPv6 to be skipped a fair amount by OPNSense Reverse and by some accounts even Forward resolution. To fix this, I setup my own BIND and have both IPv4 and IPv6 getting updated into it via both the DHCPv4 server and a Python script that scrapes all the sources of IP data and updates my BIND as necessary.
https://github.com/j0nny55555/homelabdnsupdater (https://github.com/j0nny55555/homelabdnsupdater)
Please feel free to detail a bit more about what is replying your host resolutions correctly inside your network (is it the OPNSense, or something else?), and remember, you can dig/drill @ip_address so you can specify who you ask about a local DNS resolution...
drill myhost.homelab.home AAAA @ns02.homelab.home - Forward Lookup (specifically IPv6 - quad-A)
drill -x 192.168.0.12 @ns02.homelab.home - Reverse Lookup
I don't think I'm explaining the actual issue well enough, let me try to add as much detail as I can:
This isn't a general nameserver problem. It's only a a problem for aliases inside OPNsense, specifically a discrepancy between Dnsmasq and Unbound (with Unbound being the only unexpected one). The DNS setup works correctly on all hosts and the OPNsense, as far as I know and/or can tell, but ONLY the alias resolution is "weird".
First some answeres to your setup questions:
- OPNsense and all clients use the same DNS server, which is currently Unbound running on the OPNsense
- local domain is set for OPNsense via System-Settings-General-Domain
- local domain is set for all clients using DHCP (ISC; option "DNS Server" left empty; defaulting to globally set domain above)
- Upstream DNS servers are set in System-Settings-General-DNS servers, if I want to use them in the DNS
- The option "Do not use the local DNS service as a nameserver for this system" is disabled, so 127.0.0.1 SHOULD be used
- OPNsense seems to correctly use 127.0.0.1 for DNS requests
- Currently Unbound is in use as the DNS resolver, as I recently switched from Dnsmasq
- Unbound option "Register DHCP Static Mappings" is enabled and works correctly
- IPv6 isn't the problem, or even involved. The hostname(s) I'm talking about are in an IPv4 only part of the network.
- Edit: no aliases in unbound or dnsmasq are relevant or used, only hostname registration from DHCP and/or reservations
I don't have much experience with drill/dig (bit too verbose for me usually), but only the classic/old nslookup. Here are some results from various tools.
ALL results are identical between running on a client system or run on OPNsense in an SSH session, unless where otherwise noted.
- ping <hostname> works
- ping <hostname>.<localdomain>.<tld> works
- nslookup <hostname> and nslookup <hostname>.<localdomain>.<tld> work and produce identical output:
Server: <opnsense-ip>
Address: <opnsense-ip>#53
Name: <hostname>.<localdomain>.<tld>
Address: <actual-ip-of-hostname>
** server can't find <hostname>.<localdomain>.<tld>: NXDOMAINWhen run on OPNsense via SSH, <opnsense-ip> is instead 127.0.0.1 of course - nslookup <actual-ip-of-hostname> returns <hostname>.<localdomain>.<tld> correctly
- dig -x <actual-ip-of-hostname> also returns <hostname>.<localdomain>.<tld> correctly
- drill -x <actual-ip-of-hostname> returns <hostname>.<localdomain>.<tld> correctly on clients, but not on OPNsense *
- drill -x <actual-ip-of-hostname> @<opnsense-ip> works correctly (everywhere)
- dig <hostname>.<localdomain>.<tld> returns correct results
- dig <hostname> does NOT return the result, but I assume this is normal?
- drill <hostname> does NOT return the result, but I assume this is normal?
- drill <hostname>.<localdomain>.<tld> works on clients, but not on OPNsense *
For the items with *: For some reason I don't understand, using drill (and ONLY drill) will use the upstream nameservers, and not the local nameservers. No other tool behaves like this, they all correctly use 127.0.0.1 (ping, nsslookup, dig).
Now for the actual description of the problem case again:When creating an alias of type "Host(s)" in the firewall that contains one or more <hostname>, they do not resolve correctly when using Unbound. When dnsmasq is used as the DNS server/resolver, they do work like that just fine. Again, the only change is the locally running DNS server/resolver. Again: no other host in the network is involved in any way in this either. And when using <hostname>.<localdomain>.<tld> in the alias, both DNS servers resolve them just fine, proving that the correct DNS is in use, or they wouldn't be resolvable either.
Unfortunately I can't trivially switch back and forth as the OPNsense is in production use, and I can't just randomly break (or at least interrupt) the network.