register dhcp leases - dns issue

grosphus · Apr 19, 2019, 1:05 PM

Hello!

I have recently migrated my home GW/FW from an R7000 running Advanced Tomato to an APU4C4 running pfsense 2.4.4-RELEASE-p2. Everything seems to be working as expected except for one thing I've noticed.

The R7000 was running dnsmasq and would register any/all dhcp leases in dns. In the 2 years I ran this setup, There was never a name resolution problem with any of my containers, VM's, or bare metal machines utilizing dhcp.

On the APU4, I have enabled/configured dhcp server and dns resolver. The option "Register DHCP leases in the DNS Resolver" is enabled and seems to work about 80% of the time. However, there are some clients that are getting an IP from dhcp, but do not seem to register their hostname with the dns resolver. On the 'Status --> DHCP Leases' page, the 'Hostname' field for these clients is blank and their names do not resolve via dns.

These same clients that I am having trouble with worked fine on the R7000/Tomato setup as far as dns/dhcp is concerned. Is there something I am missing with my pfsense configuration? Perhaps someone here can direct me towards the correct path for troubleshooting this?

Thanks in advance for any insight or advice you may be able to provide.

johnpoz · Apr 19, 2019, 1:47 PM

@grosphus said in register dhcp leases - dns issue:

Perhaps someone here can direct me towards the correct path for troubleshooting this?

Simple thing to do would be to sniff(packet capture) on pfsense while this client gets its dhcp lease.. Do you see it report its name? Open up the capture with say wireshark

example..

If you have problem boxes - simple solution is to just create a dhcp reservation so they always get the same IP from dhcpd, and put a name on the reservation, or create a host override for these hosts, etc.

grosphus · Apr 19, 2019, 3:49 PM

@johnpoz

Thank you for your response.

After some investigation with Wireshark, I have noticed that the difference between a 'working' and 'not working' client with regard to dns is that:

resolvable client's DHCP Discover packet contains "Option: (12) Host Name"
non-resolving client's DHCP Discover packet contains "Option: (81) Client Fully Qualified Domain Name"

So since this was working fine with my previous GW/FW configuration and the exact same clients, then perhaps there is some sort of configuration that can be modified for the pfsense dns resolver to utilize both types of identification coming from dhcp clients. If at all possible, I'd rather not modify the client configuration and possibly maintain a bit of flexibility on the server side.

johnpoz · Apr 19, 2019, 4:03 PM

do you have an example client that his reporting fqdn for hostname so I could try and duplicate.. hostname should only be host name off the top of my head reporting fqdn could end up with something this if used

host.domain.tld.pfsensedomain.tld

edit: oh your using 2 different dhcp options - not sure if dhcp will use that option 81

edit2: again the quick fix for such issues is to just create a reservation for the host and then you can use whatever name you want for that host.pfsensedomain.tld

Or you could create any host override you want for that hosts reservations IP of anyname.anydomain.tld

grosphus · Apr 19, 2019, 6:54 PM

@johnpoz

If you're asking about the types of machines these non-resolvable clients are, then a couple examples would be:

2 systemd-nspawn containers running ubuntu 16.04, attached to bridge interface to LAN
LXC container running ubuntu 18.04, attached to bridge interface to LAN

Both of these examples are running on ubuntu 18.04 hosts.

I will try to investigate further why these particular clients are using the FQDN in their DHCP requests instead of just the hostname. I have other containers that are very similar if not exactly the same and they seem to use the 'Host Name' option.

I'm guessing that there was some sort of default configuration within dnsmasq on the previous setup that made this work even if the clients were sending somewhat incorrect DHCP requests. The other aspect of that would be that both DHCP and DNS were handled by one application instead of two separate ones.

Your solution is valid in that I could potentially just wait for these trouble clients to pop up and create reservations for them. However, I have a few different forms of automation for provisioning different types of containers and virtual machines. I would like to be able to spin up resources and have them available by name immediately while also using dhcp for ip allocation.

grosphus · Apr 24, 2019, 1:59 PM

After some research into the IANA dhcp standards and looking around a bit in the pfsense dhcp server settings, it seems dhcp option 81 could possibly be enabled with the correct string in place. At the very least from looking at Services-->DHCP Server-->Additional BOOTP/DHCP Options, it appears that the behavior can be modified. I haven't figured out the correct string to use yet, but I will experiment a bit more to see what I come up with.

On the client side I have discovered that (with systemd/linux) if you set an fqdn as the hostname, it seems that systemd-networkd's built-in dhcp client will interpret that to mean you want to use option 81 and not option 12. A change to the hostname and restart of the service seems to be a quick fix for this.

EDIT:clarification/details

Gertjan · Apr 24, 2019, 2:24 PM

@grosphus : For these devices, use an "DHCP Static Mappings" on the DHCPv4 server page.
This way you can override their host name - whatever they provide.

I tend even to advise you to use "DHCP Static Mappings" entry for every permanent device on you network.
Your DNS cache on pfSense - and you - will thank you for this.
At the end, you should remove the check on this option :

Btw : devices on a LAN that comes up with a FDQN seems strange to me. A device hands over its hos name. The upstream router, the one that handles that network segment knows the 'domain', does the DNS thing, etc, enters the hostname.domaine(.tld) in a local host table. The same local DNS (pfSense) will resolve "hostname" only or "hostname.domaine(.tld)" just fine afterwards.

grosphus · Apr 27, 2019, 10:41 PM

@Gertjan

Thanks for the info/advice. As far as what you were saying about the clients providing their own FQDN, its not the norm in most environments, but it is a standard option as part of the IANA definitions of DHCP functionality:

https://tools.ietf.org/html/rfc4702

https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

I think it would be interesting to get this working at some point but for now I will simply adjust my automation for spinning up VM's and containers to utilize hostname only. There are too many transient nodes on my network all the time for static mappings to make sense from a management perspective.