OPNsense Forum
Archive => 21.1 Legacy Series => Topic started by: ctrlbrk on July 26, 2021, 08:58:00 pm
-
I am having the same issue as this 3 year old post:
https://forum.opnsense.org/index.php?topic=7983.0
I have multiple VLANs. Each VLAN running its own interface DHCP on OPN. The domain name is different for each VLAN.
The problem is that the dhcpleases.conf generated by Unbound has only the "main" domain name picked up from System > Settings > General > Domain name.
This ends up creating a resolution problem.
Help :)
-
its all in help text for unbound settings:
DHCP Domain Override: The domain name to use for DHCP hostname registration. If empty, the default system domain is used. Note that all DHCP leases will be assigned to the same domain. If this is undesired, static DHCP lease registration is able to provide coherent mappings.
-
its all in help text for unbound settings:
DHCP Domain Override: The domain name to use for DHCP hostname registration. If empty, the default system domain is used. Note that all DHCP leases will be assigned to the same domain. If this is undesired, static DHCP lease registration is able to provide coherent mappings.
Would you look at that. RTFM :)
I didn't have full help toggled so missed that apparently.
OK, but you might guess my next question --- while I have a small number of static DHCP leases, the overwhelming majority are not. So what is the proposed solution or workaround?
It seems like this is a fairly major limitation if I am understanding correctly. Isn't it pretty standard to have multiple DHCP servers on more than one subnet/VLAN with unique domain naming convention?
I would be willing to accept a command line solution if necessary.
Appreciate your help.
-
It seems like this is a fairly major limitation
agree but
I have not looked at the code (yet) but I suspect that if this is still not implemented, then it is not so easy to do.
first obstacle i can think about is the lack of domain info in dhcpd leases db-file.
although its possible to try to read the config and match the lease range->domain
(these are only guesses so far)
-
Yes, no link between leases and interfaces exists unless:
(1) DHCPD services are split between interfaces each producing a separate lease file.
(2) Python code responsible for lease file parsing gains insight into lease ranges and their interfaces.
I would assume (2) is more favourable than (1), but it's still serious work that won't be done for no pressing reason since the limitations are known and haven't been a hindrance in the open source scope so far.
Cheers,
Franco
-
Why does unbound generate the DHCP leases config in the first place? ISC dhcpd can perfectly well serve multiple subnets with different options for each. I'm surprised this is not reflected into the UI.
-
@pmhausen
sorry, don't quite understand. dhcpd lease config is generated by dhcpd.inc script, not unbound afaik.
unbound scripts only try to change records in zones in accordance with changes in the leases db
(and the lack of "leased" domain name in the db does not help in this)
@franco
also like the second option better
-
Yes, a background daemon writes the dynamic leases to Unbound. The shortcoming in the straightforward implementation is the lack of domain information in the dhcpd leases file.
I created a ticket for 22.1: https://github.com/opnsense/core/issues/5118
Cheers,
Franco
-
@pmhausen
sorry, don't quite understand.
dhcpd supports configuration like this:
# my first VLAN
subnet 192.168.1.0 netmask 255.255.255.0
{
option subnet-mask 255.255.255.0;
option routers 192.168.1.1;
option domain-name "first.do.main";
option domain-name-servers 192.168.1.1;
}
# my second VLAN
subnet 192.168.2.0 netmask 255.255.255.0
{
option subnet-mask 255.255.255.0;
option routers 192.168.2.1;
option domain-name "second.do.main";
option domain-name-servers 192.168.2.1;
}
And I just wondered why the configuration in the UI does not reflect that. I would always try to mirror the underlying service structure as much as possible in any config tool. Too much magic going on between global system settings, unbound, and DHCP for my tastes.
-
I think you are confusing static leases with dynamic/automatic leases. :)
Cheers,
Franco
-
Not quite. dhcpd has got a concept of options per subnet and will apply the domain matching the subnet to dynamic and static leases alike if the static lease does not further specify the domain.
-
The difficulty is how do you put runtime lease information from the leases file into proper Unbound records without looking at a separate piece of configuration? The current implementation uses the lease file and nothing else. So this isn't a bug or a design fail... it's just a design choice leading to a quick implementation that fulfils a requirement for a particular group of users.
Cheers,
Franco
-
Doesn't Unbound support ddns updates from dhcpd like BIND does? But I get your point.
-
I think you need bind for that after all, i.e.
https://forums.freebsd.org/threads/does-unbound-not-support-dynamic-dns-update.66954/
Cheers,
Franco
-
Doesn't Unbound support ddns updates from dhcpd like BIND does? But I get your point.
Does this imply that replacing Unbound with BIND on OPN would solve this issue?
Because if yes, then possibly a workaround for me would be to *add* BIND to the mix, on another port, and I can then configure by implementation to query BIND for local PTR resolution, while leaving Unbound untouched.
Or maybe just replace Unbound? I have to admit, it's been years since I used BIND.
-
It can technically be done with ISC DHCP and BIND but the OPNsense framework and UI doesn't support it, if I am not mistaken.
Possibly there are hooks in place for custom configuration that will survive reboots and updates.
-
Also looked at dnsmasq in OPN and found this language (this time I RTFM)
The domain name to use for DHCP hostname registration. If empty, the default system domain is used. Note that all DHCP leases will be assigned to the same domain. If this is undesired, static DHCP lease registration is able to provide coherent mappings.
So I guess dnsmasq also out.
-
@pmhausen
GUI contains ddns parameters (click Advanced button on Dynamic DNS parameter) that generates plausible directives in .conf. I use internal dhcp-s, so I did not check it
-
Well, Dnsmasq used the same tool as Unbound a while back so it's not unnatural for it to have the same limitation anyway. ;)
https://github.com/opnsense/core/issues/5119
Cheers,
Franco
-
GUI contains ddns parameters (click Advanced button on Dynamic DNS parameter) that generates plausible directives in .conf. I use internal dhcp-s, so I did not check it
Good to know, thanks. So it's only the BIND plugin that lacks a bit in options, here. Improvements always welcome. ;)
-
So it's only the BIND plugin that lacks a bit in options, here. Improvements always welcome.
at first (!) glance everything is not so scary with unbound:
small changes in dhcpd.inc generates 'dhcp pool'->'domain-name' file that i can try to use in unbound_dhcpd.py to change 'domain' to one from pool settings ("lease ip -> pool -> pool domain" if any).
but I have no way to test this on real clients.
maybe there are utilities emulating clients with a complete process of obtaining a lease? (nmap only sends a DHCPINFORM afaik)
-
My point is that dhcpd and named actually share a common standard protocol for dynamic updates so nobody would need to code "lease update magic" at the file level. Dhcpd can send named all the info whenever a lease is issued or renewed.
-
Bind was removed from BSDs and replaced with Unbound for security reasons. Now we want to bring Bind in to fill a small gap because it already has this implemented? Sounds like going in circles. :)
Cheers,
Franco
-
I'd say it was removed because it was not considered worth to keep up with upstream patches for just a local cacheing recursive NS. But it's still in ports and well supported.
I'll look into the BIND plugin, possibly this can be added as an option.
-
Fair enough, it would help those who can/want to run a Bind server locally quickly.
Thanks,
Franco
-
From GitHub, it looks like this has been solved? How can I test the new version?
-
I can post test instructions tomorrow after giving it a try.
Cheers,
Franco
-
From GitHub, it looks like this has been solved? How can I test the new version?
I may have gotten lost in the conversation of the original problem and the talk of DDNS. Are you saying Unbound handling multiple domain names on different VLANs has been fixed?
I'm fully updated and have the same issue as the OP. Wondering if there is a solution coming or not. It's not a huge deal, just easier to understand what device I'm looking at on a rDNS lookup (pi-hole stats).
-
It's in the development version but wasn't cleared for release just yet. It might be in 21.7.3 next week given that it works fine.
So far, however, lots of "want want want" but no feedback on the actual implementation.
This is business as usual but makes us question if it was really that important. ;)
Cheers,
Franco
-
Again, forgive me as I'm not a developer and such...
Thanks for the update on that. I'm not sure what you would like for implementation feedback, just testers or what settings should be placed in the UI?
I wouldn't say it is necessarily "important"? but I don't believe it is expected behavior to query unbound and have it come back with a default domain when a machine is on a different vlan with different domain. That's how I wandered into this thread. More than likely users just don't care or don't do rDNS lookups often? No idea.
Really appreciate the work on OPN, I've been pretty happy with it overall. This isn't a sticking point where I would go through the work of switching or putting my USG (shudder) back in place.
-
Ha, no worries, I just try to explain the situation.
Thanks for the update on that. I'm not sure what you would like for implementation feedback, just testers or what settings should be placed in the UI?
There are no settings. The thing works on the development release as opposed to not working on the community release just yet.
Getting a simple "yes it works now" would be a larger step forward in getting this included quickly.
As for "expected": it is properly documented and a longstanding limitation of the implementation. Expectations have been managed for years so it should also be common knowledge by now, at least if you ask the forum memory. :)
Cheers,
Franco