DNS and DHCP -> using different domains for each network - Bug #1819 - $150

[CubedRoot]

One use case for me with pfSense is using it to service several functions in my lab.  I have a server co-located in a datacenter with a /28 of public IP's.  I have a pfSense appliance that is connected to the ISP at the datacenter that serves as my router, firewall, certificate server, DNS, DHCP, and several other functions for my lab.

My pfSense appliance has 7 additional physical nics that are connected to my hosts.  I have a separate network defined in pfSense for each of these physical nics, and the hosts will sometimes be KVM servers hosting quite a few VM's.  My network configuration looks like this (IP's and hostnames/domains sterilized for safety) :

Again, this is just a sample of how I have my lab setup, but the important parts are there.  I need the ability to use the DHCP server settings and set a hostname for each DHCP server in each of those LANs to provide my guests with the proper domain as outlined in the graphic above.  In the current state, pfSense will use whatever is set for the system domain name as what it provides to DHCP clients requesting it.  In my example above,  all of my DHCP clients would get a hostname of gitlab.mydomain.com  instead of what I want them to get (gitlab.infra.example.com).  There is a setting in the DHCP configurations to provide a domain name, but it doesn't work.

Likewise, I would want the DNS entry to be made on pfSense so that my DHCP clients have their properly desired FQDN entered into the DNS resolver for other clients on the network (my pfSense appliance is my main source of DNS for all machines attached to it).  In my desired state, any machine could resolve the DHCP client of gitlab.infra.example.com to its IP address of 172.16.1.110.  In the CURRENT state, pfSense will resolve that to gitlab.mydomain.com with IP 172.16.1.110

There is a Bug filed in Redmine that is eerily similar, and has been out there for SIX YEARS:  https://redmine.pfsense.org/issues/1819
I think this is very similar or exactly what I am running into.

It looks like there have been similar requests:
https://forum.pfsense.org/index.php?topic=119717.msg662371
https://www.reddit.com/r/PFSENSE/comments/5hj7r0/subdomain_per_interface/
https://www.reddit.com/r/PFSENSE/comments/7lpr5z/set_subdomain_depending_on_subnet/

I would be willing to start the bounty with $150, and hope others would kick in a little as well. 

[CubedRoot]

Found another Thread with a user experiencing the same type of issue:

https://forum.pfsense.org/index.php?topic=122409.msg676047#msg676047

[miken32]

@CubedRoot:

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.)

[CubedRoot]

@miken32:

@CubedRoot:

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).

[miken32]

@CubedRoot:

@miken32:

@CubedRoot:

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?

[dpsi]

@miken32:

@CubedRoot:

@miken32:

@CubedRoot:

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?

[dpsi]

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#L635

mwexec("/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.

[Derelict]

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.

[glego]

@ 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.

[CubedRoot]

Looks like this was pushed out to 2.4.5.

Bounty is still out there.

[snow]

@CubedRoot

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;)

[CubedRoot]

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.

[stevenb]

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.

[crond]

Just curious why does it take 8 years to resolve this bug ?

[CubedRoot]

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

[Derelict]

If the pfSense DHCP server does not meet your needs use a different DHCP server.

[CubedRoot]

@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.

[crond]

@CubedRoot yeah run in the same problem during evaluation and after googling was surprise to find that it's been reported 8years ago.

[crond]

@Derelict Thank you for such comprehensive answer, it really helps to understand complexity of the problem on netgate side and timeline for resolution.

[Derelict]

This post is deleted!