Trailing dot on DHCP DNS entries from Windows clients

dataradical

Hi

After moving to pfSense 2.7.2 and migrating from ISC to KEA, I noticed that Windows DHCP clients (Windows 11 mostly, plus a Brother printer) suddenly had their DNS entries listed with a trailing dot, resulting in DNS lookup not working.

So a client asking for hostname windows11 ends up with an entry named windows11. in the DHCP leases, and if I configure the client with a domain (foo.bar) the DHCP leases entry becomes windows11.foo.bar.

The DHCP server does give out an IP and registers the name as if all went well, but due to the trailing dot, neither forward nor reverse lookup works.

This is different behavior from ISC, and only happens on Windows clients. Other DHCP clients running Linux or MacOS do not have this issue.

It looks like the Windows clients request a DNS entry to the DHCP server with a trailing dot, both without a domain name defined and with a domain name defined, so it's definitely triggered by the client.

Any idea on how to fix this, either on the client or by configuring KEA to behave like ISC who skipped the trailing dot ?

johnpoz

@dataradical said in Trailing dot on DHCP DNS entries from Windows clients:

The DHCP server does give out an IP and registers the name as if all went well,

Huh where did you get the idea that KEA registers anything?

https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#rn-2-7-1-kea

dataradical

@johnpoz You got a point there. Thanks for the reference. My bad due to not reading the 2.7.1 notes but just 2.7.2.

So I had to switch back to ISC for the moment as I need this functionality.

The interesting part is that it also differs in the KEA dhcp4.leases file compared to the ISC dhcpd.leases file, so without any connection to dynamic/static DNS updates not functioning in KEA (yet).

When running ISC DHCP, I had a client-hostname entry in dhcpd.leases without the trailing dot, while in KEA dhcp4.leases I have this :

[2.7.2-RELEASE][admin@pfSense.foo.bar]/var/lib/kea: grep -i windows11 dhcp4.leases | tail -1
192.168.40.194,3e:9e:0e:e4:b1:fb,01:3e:9e:0e:e4:b1:fb,7200,1705979093,4,0,0,windows11.foo.bar.,0,,0

So KEA picks up the trailing dot there already, while with ISC there no trailing dot.

johnpoz

@dataradical said in Trailing dot on DHCP DNS entries from Windows clients:

So I had to switch back to ISC for the moment as I need this functionality.

Yeah unless your just handing IPs to clients and that is it, KEA not really ready for anything else that this point.. I validated that it works, ie it does hand out IPs to dhcp clients. But I use options and register reservations, etc. I will continue to use isc until such time that the kea integration is complete, or at least much farther along than it is now.

I also don't like the logging in kea.. currently - from the quick read over I did of the kea docs, it looks quite feature rich etc.. But just needs work on integrating it into the pfsense is all.

Gertjan

@dataradical said in Trailing dot on DHCP DNS entries from Windows clients:

DNS entries listed with a trailing dot

Host name are known like "foo.bar", but that's just for us, human.
Technically correct is "foo.bar." - "foo.bar" isn't.
The trailing dot means : go ask the root servers with this question : "List me the TLD server == "bar"".
( and then, after questioning one of the TLDs that handles "bar", you will get two are more domain name servers that handle "foo", and then you ask this domain server : what is the A record "www" etc)

When you activate full DNS query details :

you will see (look at the resolver logs, that's where the answers are ) that your typical LAN device will ask :
What is "foo.bar." and, if needed, also "what is "foo.bar"

So, trailing dot or not, not an issue for the common mortals, our resolver will handle the good and bad host names.

Example :

I launch nslookup on my PC :

Serveur par defaut :   pfSense.bhf.net
Address:  2a01:dead:907:a6eb:92ec:77ff:fe29:392c

> foo.bar
Serveur :   pfSense.brit-hotel-fumel.net
Address:  2a01:dead:907:a6eb:92ec:77ff:fe29:392c

Nom :    foo.bar

So, a request without the trailing dot.

This shows up in my (other) DNS log - the one pfBlockerng :

At first the resolver adds ( !!) the local domain == bhf.net.
So the request becomes foo.bar/bhf.net.
No (local) answer was found.

Then (second two lines) the resolver resolver goes upstream (talking to the root servers etc) - but that was also a fail == no answer.

DNS-reply,Jan 23 09:33:19,local,A,Unknown,Unk,foo.bar.bhf.net,2a01:dead:907:a6eb::c7,Unknown,unk
DNS-reply,Jan 23 09:33:19,local,AAAA,Unknown,Unk,foo.bar.bhf.net,2a01:dead:907:a6eb::c7,Unknown,unk

DNS-reply,Jan 23 09:33:20,reply,A,SOA,3600,foo.bar,2a01:dead:907:a6eb::c7,SOA,unk
DNS-reply,Jan 23 09:33:20,reply,AAAA,SOA,3600,foo.bar,2a01:dead:907:a6eb::c7,SOA,unk

When I ask for foo2.bar. (note the trailing dot)

DNS-reply,Jan 23 10:12:34,reply,A,SOA,3600,foo2.bar,2a01:dead:907:a6eb::c7,SOA,unk
DNS-reply,Jan 23 10:12:34,reply,AAAA,SOA,3600,foo2.bar,2a01:dead:907:a6eb::c7,SOA,unk

the resolver contacts right away the root servers without looking for a local solution (it won't add the local domain name).

dataradical

@Gertjan Understood. The issue here was not whether the trailing dot was valid in DNS (it is). The problem was in the end that Kea (at the moment) doesn't update the DNS records at all, so the name I was looking for with nslookup/dig was not there but solely in the DHCP lease file, and I was assuming (not having read the 2.7.1 release notes) that Kea would dynamically update the DNS records just like ISC.

As soon as I switched back to ISC, all worked again, dots or no dots in the DHCP lease file.

Draco

@johnpoz said in Trailing dot on DHCP DNS entries from Windows clients:

So I had to switch back to ISC for the moment as I need this functionality.
Yeah unless your just handing IPs to clients and that is it, KEA not really ready for anything else that this point.. I validated that it works, ie it does hand out IPs to dhcp clients. But I use options and register reservations, etc. I will continue to use isc until such time that the kea integration is complete, or at least much farther along than it is now.

Oh wow so that is the cause? KEA not handing out the suffix set in the General menu (or overridden in the DHCP Server menu)? This has been driving me crazy because all of my internal server references were to "home.arpa" (e.g. "printer.home.arpa") with the "home.arpa" suffix appended by pfSense/ISC. And my self-signed certificates now blow chunks too because the DNS name registered for it is "printer.home.arpa" and the browser does not like it being referenced as just "printer".

Netgate, please fix this in KEA! Note that I did submit a Redmine bug against this issue.

blueh2o

I have a laptop with a mapping for both the wired and wireless MAC, but when it gets a lease, instead of, for example, "laptop" as the client ID, it is "laptop." and gets a pool address instead, even though the MAC matches the reservation. Very annoying.