Messages

If you use the above linked software, you don't have to worry about any of the above concerns.

It will also automatically take care of local PTR/A resolution for all your LAN hostnames (through discovery via arp, mdns, ptr probes and DHCP leases file parsing), and you can delegate queries from subnets, MAC addresses or for custom TLDs to your local unbound instance if you want this.

Or do it the other way around and keep running unbound on UDP 53, and use ctrld as the upstream although you will lose the device identification data in this mode.

It does all the automatic DHCP registering with PTR as well? I didn't read that in the documentation, that is neat!

But still it requires manual CLI configuration for host overrides, aliases and other manual config, right?

I decided to use Unbound exclusively and setup DNS over TLS towards NextDNS. No hostnames but it works flawlessly with all the benefits that won't work with the other setups.

Could you please check with dnscheck.tools if you experience any dns leaks? Maybe also try it several times, sometimes I see only NextDNS server but most of the time I can also see cloudflare as well as opendns servers... I am not sure about if I have something misconfigured. I have created a post here in the forum but so far no one responded. Since you are using NextDNS exactly as I did I would be interested to see if this behaviour like me. Thanks!!

Impossible because I "catch & redirect" DNS through a NAT rule back to OPNsense. Unless some client (like mobile devices) connects through "secure DNS", basically DNS over TLS or HTTPS. I'm not sure if I could catch those but my own devices don't do that so its only guest devices and I don't care enough.

I'm not very lucky with this project ...

https://github.com/ansibleguy/collection_opnsense/issues/41

Thanks. Yes they do keep a valid IP. In their own logging its just the usual dhcpcd logging.

I can try the tool, but I am wondering. After deployment the guests are turned off. I turn them back on to start configuration and at that point some of them already do not resolve so there is no way for me to even start the dhcpdump tool.

After config (if they do resolve), I can install the tool and start it in a terminal. However, at that point I need to leave it open for I-dont-know-how-long. It seems intermittend I cannot predict which ones are going to have an issue.

Since I am already automating things I might just make a dhcp reservation via API. I feel that is less work than troubleshooting the guests.

This is a new issue for me I have not seen before. I searched but I only seem to find issues about other issues concerning leases.

So what is happening is that I install a few new Rocky Linux systems (automated on ESX). They boot up with a kernel option "ip=dhcp". This required because during boot, it needs to pick up a kickstart file for silent install from an https-address.

The servers install, and reboot. They all get their lease and register their hostnames. But after short time (like, within an hour or so), some of the leases expire and their hostnames become unresolvable because they are also removed from Unbound (register dhcp clients). What I see in DHCP leases list is that the IP is still there and showing online, but expired. The host is reachable on IP and everything else seems to work fine (no connection issues).

The installations are mostly defaults, I only change the hostname, partitioning and I create a user with ssh key via the silent install script. I make no changes to network settings, I only tell it to use DHCP.

In debug logging in the dhcp server, I only see the requests and replies. I see reuse unaltered entries, but nothing about expiring or removing leases.

I also searched Unbound logging but that logs so much I might have missed something. I didn't find information about registrations being removed due to expired leases or something.

I tried increasing and changing some lease times like minimal and max, but the leases seem to expire anyway.

Basically I'm at a loss and I'm unsure what else to check? If anyone has an idea I would appreciate it!

Thanks!

For me the issue with replacing Unbound would be that it doesn't provide a gui for easy configuring of things like host aliases, overrides and fixed hostname registration. Its all done through CLI which requires login to opnSense every time a change is required. In my mind that does not make things easier. Also, if using opnSense API to register DNS or make changes to it, this won't work anymore.

There is however another way. Also not perfect.

You can run Unbound on a non-default port, say 5353. Select only a single interface (not all). Set NextDNS to listen to 53 instead.

Then in /usr/local/etc/nextdns.conf you can configure forwarders like so:
forwarder internal.yourlocaldomain.net.=127.0.0.1:5353

Do that for each subnet you're running.
Make a reverse forwarder like so:
forwarder 0.0.10.in-addr.arpa.=127.0.0.1:5353

I have never managed to make ipv6 forwarders work, I think they would like something like this:
forwarder 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.1.2.3.a.4.5.b.1.2.c.4.ip6.arpa.=127.0.0.1:5353

In your opnSense DHCP, you need to configure these options for DHCP clients:
gateway
domain
nameservers
ntp servers

Basically, any config your clients would get automatically when Unbound is running on 53, will no longer work so you need to manually set these. See this change for more info.
I made a request for NextDNS to support this, which got declined without further info.

Depending on your use you may run into other issues.

Personally, I have forgone the idea that I need client names to register. It seems handy at first but after a while you'll never look at it and when you actually need to troubleshoot a client, you'll find its not required at all.

I decided to use Unbound exclusively and setup DNS over TLS towards NextDNS. No hostnames but it works flawlessly with all the benefits that won't work with the other setups.

Sorry! My bad! :-[

Too many things going on! I had cleared the fields in DHCP after making unbound the main resolver at port 53, but I shouldn't have cleared the domain field.

I read:
https://forum.opnsense.org/index.php?topic=24084.0

Found the linked (and closed) github issue.

I read everything twice and searched again to make sure I didn't miss something obvious  :P.

So I think this should be solved and working now? I have several VLANs in their own domain, but my hosts from each of them are registered under the system domain in unbound.

I read in the link above there isn't a setting and should 'just work', but it isn't in my case.

Any ideas please what I am missing?

Thanks!

I incorrectly assumed that the fact that a DHCP lease is not registered in Unbound was caused by unbound not listening on that interface.

One host is still not registering, so I'll investigate that and if I need help, open a new post for that.

Wanted to clarify in case someone comes here, reads my OP and thinks the solution solved that too.

https://forum.opnsense.org/index.php?topic=33634.msg180318#msg180318

Awesome! Thank you!

When I set unbound to listen to all internal interfaces, it seems this causes unbound to randomly return an interface address when I query opnsense hostname.

My opnsense GUI is (should be) only accessible on what I call LAN. I have several other networks with VLANs on them for different purposes. None of these should be able to access the webGUI. However, all of these networks should have access to opnsense as a gateway, DNS and NTP.

Unbound is set to listen to all internal networks
Unbound is listening on 53 as the main resolver (so it registers for DHCP defaults)
Each network has DHCP enabled.

When I am on LAN, and I ping opnsense, I often get an IP returned that does not belong to LAN network (ie, one of the other VLAN interface addresses). I cannot open the webGUI because its not accessible on that IP.

When I change unbound to listen to only on LAN interface, it now seems that hosts in other than LAN network no longer resolve, as if they do not get registered because Unbound is not set to listen on those interfaces?

I've been trying to catch what happens in the logs of unbound, but the GUI is slow (large logs?) and when searching, the window never shows a result (it just sits there searching infinitely).

Please ask if you're missing information, I hope I can solve this soon with a bit of help!

Thanks!

Maybe its not related to the this but since I enabled IPv6 on the interface udp broadcast relay is enabled, it started failing to start. In the logs it just says:

Code Select Expand

2023-11-12T17:42:55 [Notice] root /usr/local/etc/rc.d/os-udpbroadcastrelay: WARNING: failed to start osudpbroadcastrelay

What can I do to troubleshoot this? I tried some different settings, like clearing and setting 1.1.1.1 or 1.1.1.2 but nothing seems to matter, it always fails to stat.

Any ideas please?

I wouldn't know .. it was enabled on my ipv4 gateway as well.

I also disable gateway monitoring on single gateways its pointless IMO.

It should. There's a bunch of threads here about possible track interface and PPPoE issues.

It the WAN v6 gateway shown as up and running? Also try restarting the dpinger service.

Awesome. Like I said in my opening post, it must be something obvious.

The IPv6 gateway was there (I had checked it), but, the tickbox for upstream gateway was not ticked.

In the end so much trouble for such a small thing haha! 8)

Thanks for the help, all working now!

PS. I removed the ::/0 from the router advertisements and removed all the any-any rules.

You are missing the default route there.

Code Select Expand

# netstat -rn6 | grep default
default                           fe80::e681:84ff:fec3:3734%pppoe0 UG    pppoe0


Shouldn't that be set automatically?

I mean, I can set it manually but that shouldn't be required?