DNS and DHCP -> using different domains for each network - Bug #1819 - $150
-
Found another Thread with a user experiencing the same type of issue:
https://forum.pfsense.org/index.php?topic=122409.msg676047#msg676047
So say you have DHCP servers on LAN and OPT1, with domains in the DHCP server set as lan.internal and opt1.internal, and the domain in general settings is pfsense.internal. Your problem is that DHCP clients are being registered on the pfSense's internal DNS as pc1.pfsense.internal instead of pc1.lan.internal?
(Important to note that the domain in DHCP is only intended for searches. So if you run
ping foo
you're going to ping either foo.lan.internal or foo.opt1.internal. It's working fine, you're just looking for it to do more than it currently is.) -
Found another Thread with a user experiencing the same type of issue:
https://forum.pfsense.org/index.php?topic=122409.msg676047#msg676047
So say you have DHCP servers on LAN and OPT1, with domains in the DHCP server set as lan.internal and opt1.internal, and the domain in general settings is pfsense.internal. Your problem is that DHCP clients are being registered on the pfSense's internal DNS as pc1.pfsense.internal instead of pc1.lan.internal?
(Important to note that the domain in DHCP is only intended for searches. So if you run
ping foo
you're going to ping either foo.lan.internal or foo.opt1.internal. It's working fine, you're just looking for it to do more than it currently is.)Yes, whatever domain is set in the general settings of pfSense, that is the domain that DHCP clients will get assigned to them. I am looking for the ability to have the DHCP server assign (and register correctly with the pfSense DNS) a completely different domain per network (LAN, vLan, etc).
-
Found another Thread with a user experiencing the same type of issue:
https://forum.pfsense.org/index.php?topic=122409.msg676047#msg676047
So say you have DHCP servers on LAN and OPT1, with domains in the DHCP server set as lan.internal and opt1.internal, and the domain in general settings is pfsense.internal. Your problem is that DHCP clients are being registered on the pfSense's internal DNS as pc1.pfsense.internal instead of pc1.lan.internal?
(Important to note that the domain in DHCP is only intended for searches. So if you run
ping foo
you're going to ping either foo.lan.internal or foo.opt1.internal. It's working fine, you're just looking for it to do more than it currently is.)Yes, whatever domain is set in the general settings of pfSense, that is the domain that DHCP clients will get assigned to them. I am looking for the ability to have the DHCP server assign (and register correctly with the pfSense DNS) a completely different domain per network (LAN, vLan, etc).
Isn't that what the "DDNS Domain" option is for?
-
Found another Thread with a user experiencing the same type of issue:
https://forum.pfsense.org/index.php?topic=122409.msg676047#msg676047
So say you have DHCP servers on LAN and OPT1, with domains in the DHCP server set as lan.internal and opt1.internal, and the domain in general settings is pfsense.internal. Your problem is that DHCP clients are being registered on the pfSense's internal DNS as pc1.pfsense.internal instead of pc1.lan.internal?
(Important to note that the domain in DHCP is only intended for searches. So if you run
ping foo
you're going to ping either foo.lan.internal or foo.opt1.internal. It's working fine, you're just looking for it to do more than it currently is.)Yes, whatever domain is set in the general settings of pfSense, that is the domain that DHCP clients will get assigned to them. I am looking for the ability to have the DHCP server assign (and register correctly with the pfSense DNS) a completely different domain per network (LAN, vLan, etc).
Isn't that what the "DDNS Domain" option is for?
Can you show us how to let the DNS Resolver or Forwarder to give a key to allow the zones to be updated?
-
I am not a php developer, but I think I have figured out where the change needs to be.
https://github.com/pfsense/pfsense/blob/0a031fc76cdf0070db61ef93e1ccd692e9223cfa/src/etc/inc/system.inc#L635mwexec("/usr/local/sbin/dhcpleases -l {$g['dhcpd_chroot_path']}/var/db/dhcpd.leases -d {$config['system']['domain']} -p {$g['varrun_path']}/{$dns_pid} {$unbound_conf} -h {$g['etc_path']}/hosts");
When the leases are being given, the command is hardcoded to use the system domain when writing to the resolver/forwarder dhcp entries list.
Again, I am not a php dev, but it seems that if we could change the -d option then the correct domain will be given to dhcpleases. However, due to the way these are generated, it seems there can only ever be 1 domain. The dhcpd leases file holds ALL leases, not per interface. So either we need a different way to get the leases from dhcpd, or a different way to generate the domains. -
I think there is some misconception here about what the domain-name parameter (Option 15) is supposed to do.
It sets the DNS domain as opposed to the DNS search list set by the domain-search parameter (Option 119).
There is also the host-name parameter (Option 12) that can be used to set the host name. According to my research this parameter is only really effective if configuring a system at boot - such as in conjunction with PXE.
macOS 10.13.3 does not request that the server respond with option 12 - at least when it renews. The server, as expected, does not respond with an Option 12 setting.
From the dhcpd.conf man page:
It should be noted here that most DHCP clients completely ignore the host-name option sent by the DHCP server, and there is no way to configure them not to do this. So you generally have a choice of either not having any hostname to client IP address mapping that the client will recognize, or doing DNS updates. It is beyond the scope of this document to describe how to make this determination.
-
@ Derelict,
I agree that dhcpd is not designed to fulfil the requirement. The issue is that ubound is registering all dhcpd leases under the same general domain name (see DHCP Registration).
The community (and me), would like to see an option where ubound takes the dhcpd domain-name parameter (Option 15) instead of the System > General Setup > Domain Name.
DHCP Registration
Register DHCP leases in the DNS Resolver If this option is set, then machines that specify their hostname when requesting a DHCP lease will be registered in the DNS Resolver, so that their name can be resolved. The domain in System > General Setup should also be set to the proper value.
-
Looks like this was pushed out to 2.4.5.
Bounty is still out there.
-
I agree with you, same issue on my side with different dns domains on different vlan interfaces and I hope there will be an option available in an upcoming version.
As a workaround you can set static dhcp mappings, it's not comfortable but it's working;) -
Yeah, I am using static mappings, but it is painful. I have even considered kicking the bounty up a little, but not sure what it'd take to get some traction.
-
I've also run into this issue.
In digging, I believe the main fix for this needs to be added to the dhcpleases support app.
https://github.com/pfsense/FreeBSD-ports/blob/ea7549839ac5657e8d1f119ff45a79b7682cc97e/sysutils/dhcpleases/files/dhcpleases.c
While I can understand the main gist of the code that is there, I don't rate my coding skills in C that highly. I'm not sure I have enough time to try and polish them up to get this done.
How I would go about fixing it would be to create a new function in that utility which reads in the dhcpd config file and parses it into a list of IP pools and their DNS domain setting (if set). Then, when an individual DHCP lease is parsed, the code should loop over the list of IP pools and find the pool it belongs to and then attach the corresponding DNS domain, if there is one, instead of the default domain_suffix.
In PHP you have access to the DHCP pool information through the pfSense config data, however this utility needs to pull it from somewhere and I think the best place might be the dhcpd.conf file. I could be wrong, but the dhcpleases app looks to be restarted whenever the dhcp server is restarted, so the dhcp.conf config data should be able to just parsed in once at the start.
Most of the time would be spent writing a parser for the dhcpd.conf to bring in the required information.
-
Just curious why does it take 8 years to resolve this bug ?
-
The only thing I know to do is just keep pinging them here and in the red mine issue here. https://redmine.pfsense.org/issues/1819
-
If the pfSense DHCP server does not meet your needs use a different DHCP server.
-
@Derelict said in DNS and DHCP -> using different domains for each network - Bug #1819 - $150:
If the pfSense DHCP server does not meet your needs use a different DHCP server.
Wow, that's a pretty crummy answer. Sadly I am having to use a different DHCP server because pfSense has neglected this 8 year old bug. This sort of shows the attitude of the "new pfsense' since the whole negate change a few years back.
-
@CubedRoot yeah run in the same problem during evaluation and after googling was surprise to find that it's been reported 8years ago.
-
@Derelict Thank you for such comprehensive answer, it really helps to understand complexity of the problem on netgate side and timeline for resolution.
-
This post is deleted! -
Bumping this to let devs know a fix would be very much appreciated.
-
+1 I have quite a few SG1100 around at remote customer sites. It would simplify my usecase considerably if this quite natural way automation between DHCP and DNS was implemented.