DHCP static mappings that don’t specify hostnames

[bp81]

What I am trying to do might not be possible.

I have my router set to use Unbound for dns resolution. I also have the dhcp server set to register dhcp client hostnames / fqdns in dns. I am also set to register static dhcp mappings in dns.

I am observing that any client that has a static mapping set but has the hostname field blank in the mapping does not get registered in dns. Non static clients will get registered as expected.

My presumption here is that the dhcp server ignores the hostname provided by clients that are statically mapped but accepts the hostname for clients that are dynamic. This is the behavior I’d like to change. I would like to create a situation where static mapped clients are assigned an IP address by the dhcp server, but the dhcp server accepts the client’s hostname.

Is this something that ISC DHCPD can do?

[Gertjan]

@bp81 said in DHCP static mappings that don’t specify hostnames:

I am observing that any client that has a static mapping set but has the hostname field blank in the mapping does not get registered in dns. Non static clients will get registered as expected.

Ask pfSense what it is doing, and it will tell us :

/usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid interface1 interface2 .....

The DHCP server config file /var/dhcpd/etc/dhcpd.conf shows me how known static leases are setup for the dhcpd process.
I guess, when creating a static based MAC lease, the info is used to create a /var/dhcpd/etc/dhcpd.conf so dhcpd knows about it, and at the same time a line is added to /etc/hosts.
/etc/hosts is read by unbound when it starts executing.

Take a look at the /var/dhcpd/var/db/dhcpd.leases file.
You will find some leases like :

lease 192.168.1.71 {
  starts 4 2022/07/21 09:10:02;
  ends 5 2022/07/22 09:10:02;
  cltt 4 2022/07/21 11:47:01;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 18:e7:b0:cc:bc:d9;
  uid "\001\030\345\260\039\005\341";
  client-hostname "iPhone-12-Jullien";
}

and other leases do not have a client-hostname at all.
Or worse, do have a client-hostname, but this name is not DNS-hostname format compatible.
Understand that the client-hostname is given to the dhcpd server by the device, using it's dhcp client. The client-hostname can be setup by the person who admins the device. If the device even has this capability. Many device have a client-hostname hard coded, or omit it.

My /var/dhcpd/var/db/dhcpd.leases file contains 276 leases, and only 12 have a client-hostname given by a device.

So : using the client-hostname given by the client is ..... not a safe solution.

@bp81 said in DHCP static mappings that don’t specify hostnames:

I am observing that any client that has a static mapping set but has the hostname field blank

There was a forum thread a while ago about this question.
Or was it : give MAC and hostname but no IPv4 in a static .... ? Don't recall.

Consider the "DNS" as a phone book.
One rule, no exception. Planet earth goes down ? Still no exceptions.
The rule is :
Phone number <=> Name.
If one of the two is missing the system goes belly up.
DNS down is bad for business (but a very popular amusement, see the forum, it''s an on going occupation for many)

So, I guess pfSense want you (forces you) to give a host name. That's the name that can be checked against DNS name compliance. That's the one being used in for DNS.

You can change this behaviour of course, no need to inform the dhcpd process with a setting. It's all 'pfSense GUI' scripted somewhere in the PHP files.

But take note : if you decide to add some script logic that uses the "client-hostname" (the name given by the client) then you need some other process that parses the /var/dhcpd/var/db/dhcpd.leases and now you have opened a can of worms. Just read the several thouands of forum post about this process :

[/usr/local/sbin/dhcpleases -c /usr/local/bin/php-cgi -f /usr/local/sbin/prefixes.php -l /var/dhcpd/var/db/dhcpd.leases

This process is activated when you select this option :

This process stops and unbound (your local DNS !) every time a DHCP lease comes in, or gets renewed.

Now you know why I strongly advice to disable this option :

for every device that you have to know by hostname, pick an easy DNS hostname, and make a static MAC lease.
I know this isn't the perfect solution, but it's the one that works, is easy to maintain, and unbound will restart far less often, so DNS keeps on working, and the cache gets build and stays valid.

This one :

is 'harmless' as /etc/hosts only gets read when unbound starts.

[bp81]

@gertjan said in DHCP static mappings that don’t specify hostnames:

@bp81 said in DHCP static mappings that don’t specify hostnames:

I am observing that any client that has a static mapping set but has the hostname field blank in the mapping does not get registered in dns. Non static clients will get registered as expected.

Ask pfSense what it is doing, and it will tell us :

/usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid interface1 interface2 .....

The DHCP server config file /var/dhcpd/etc/dhcpd.conf shows me how known static leases are setup for the dhcpd process.
I guess, when creating a static based MAC lease, the info is used to create a /var/dhcpd/etc/dhcpd.conf so dhcpd knows about it, and at the same time a line is added to /etc/hosts.
/etc/hosts is read by unbound when it starts executing.

Take a look at the /var/dhcpd/var/db/dhcpd.leases file.
You will find some leases like :

lease 192.168.1.71 {
  starts 4 2022/07/21 09:10:02;
  ends 5 2022/07/22 09:10:02;
  cltt 4 2022/07/21 11:47:01;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 18:e7:b0:cc:bc:d9;
  uid "\001\030\345\260\039\005\341";
  client-hostname "iPhone-12-Jullien";
}

and other leases do not have a client-hostname at all.
Or worse, do have a client-hostname, but this name is not DNS-hostname format compatible.
Understand that the client-hostname is given to the dhcpd server by the device, using it's dhcp client. The client-hostname can be setup by the person who admins the device. If the device even has this capability. Many device have a client-hostname hard coded, or omit it.

My /var/dhcpd/var/db/dhcpd.leases file contains 276 leases, and only 12 have a client-hostname given by a device.

So : using the client-hostname given by the client is ..... not a safe solution.

@bp81 said in DHCP static mappings that don’t specify hostnames:

I am observing that any client that has a static mapping set but has the hostname field blank

There was a forum thread a while ago about this question.
Or was it : give MAC and hostname but no IPv4 in a static .... ? Don't recall.

Consider the "DNS" as a phone book.
One rule, no exception. Planet earth goes down ? Still no exceptions.
The rule is :
Phone number <=> Name.
If one of the two is missing the system goes belly up.
DNS down is bad for business (but a very popular amusement, see the forum, it''s an on going occupation for many)

So, I guess pfSense want you (forces you) to give a host name. That's the name that can be checked against DNS name compliance. That's the one being used in for DNS.

You can change this behaviour of course, no need to inform the dhcpd process with a setting. It's all 'pfSense GUI' scripted somewhere in the PHP files.

But take note : if you decide to add some script logic that uses the "client-hostname" (the name given by the client) then you need some other process that parses the /var/dhcpd/var/db/dhcpd.leases and now you have opened a can of worms. Just read the several thouands of forum post about this process :

[/usr/local/sbin/dhcpleases -c /usr/local/bin/php-cgi -f /usr/local/sbin/prefixes.php -l /var/dhcpd/var/db/dhcpd.leases

This process is activated when you select this option :

This process stops and unbound (your local DNS !) every time a DHCP lease comes in, or gets renewed.

Now you know why I strongly advice to disable this option :

for every device that you have to know by hostname, pick an easy DNS hostname, and make a static MAC lease.
I know this isn't the perfect solution, but it's the one that works, is easy to maintain, and unbound will restart far less often, so DNS keeps on working, and the cache gets build and stays valid.

This one :

is 'harmless' as /etc/hosts only gets read when unbound starts.

In short, it appears it is not possible to create the behavior I'm looking for. It's not terribly important to us, it just would've been nice.

The background on our infrastructure is that we have a mixed environment administered by Active Directory and Windows DNS. We have Windows workstations, laptops, and servers, but we also have some Linux and FreeBSD systems, as well as some IoT devices. Hostname resolution of Windows machines in Windows DNS is easy; Active Directory joined workstations have a group policy set to register their hostnames in Windows DNS.

To get non-Windows systems registered in DNS, we are using some scripting to read the dhcp leases file and dhcp config file from dhcpd, then doing some filtering to determine which leases belong to non-Windows devices and dynamically register those in Windows DNS. This is being done with a powershell script. The end result being that we now have resolution by hostname for every single device provisioned by DHCP in our network (and that is ALL devices at this point. We don't do manual IP address assignment on any system at this point). The scripting based solution works very nicely, it just would've been nice if we had the option to assign an IP address via DHCP static reservation without having to assign a hostname in the static reservation. That creates a condition where, when I create static reservations, I have to remember to leave the hostname field blank for Windows machines (which will register their DNS hostnames directly with AD DNS) but specify hostnames in the reservations for non-Windows systems.

It's not really that big of a deal, it would just be more convenient to be able to write my DHCP reservations in a consistent manner for all entries rather than having one kind of entry for Windows systems and a different kind of entry for non-Windows systems.