Windows Work PC Can't Resolve Local DNS without FQDN

striker-pl

I'll start off by saying that this is probably an issue with my Windows PC and not pfSense config, but i'm hoping someone may have some insight on what is wrong.

I have a local LAN setup with several VLANs which i'm just starting to utilize. I'm slowing going through the process of migrating devices into the various VLAN's and setting up the appropriate rules to govern the flow of traffic. Until I get things right, I also have a basic allow anything rule on each VLAN so it is still essentially operating like a flat network until I can get things the way I want.

One thing that I have noticed, is that my work computer (Windows 10 based) is having issues resolving DNS outside of its own VLAN when I try to ping other computers on my network if I don't use a FQDN. However it has no issue pinging devices over my work VPN without using FQDN.

Other computers in the same VLAN have no issue pinging without using FQDN, so the issue is specific to the work computer as far as I can tell.

I have my local LAN domain suffix assigned via DHCP in the Domain Search List and I can see it listed under connection specific domain suffix search list when I run an ipconfig /all.

Everything looks like it's setup properly, but it isn't working. Any thoughts on how I might be able to fix this?

Thanks for taking the time to read and hopefully respond! :)

striker-pl

So, as an update to this, it is definitely an issue with the PC.

If I modify the registry key:

HKLM\SOFTWARE\Policies\Microsoft\Windows
NT\DNSClient

To add my local domain to the DNS search list and then run an IPCONFIG /REGISTERDNS from an elevated prompt, things start working the way they should. Of course this gets overwritten by GPO.

Anyone know of a permanent fix for this that doesn't involve harassing my IT department to modify their GPO?

Bob.Dig

Recently had this problem too and it is completely gone now. I think the solution was to delete everything in:

/var/dhcpd/var/db

striker-pl

@bob-dig so I found three files in that folder, it appears to be a cache of all of my DHCP leases. I renamed all three files as:

dhcpd.leases -> dhcpd.leases.bk
dhcpd.leases~ -> dhcpd.leases~.bk
dhcpd6.leases -> dhcpd6.leases.bk

I then ensured that my temporary settings on my Windows workstation were reversed and I tested with nslookup.

When querying hostname I got:

c:\nslookup hostname
Server: Unknown
Address: 10.0.110.1

*** UnKnown can't find hostname: Non-existant domain

When querying hostname.domain I got:

c:\nslookup hostname.domain
Server: Unknown
Address: 10.0.110.1

Name: hostname.domain
Address: 10.0.100.92

So this did not resolve the issue. I have renamed the files back to their original names so I can retain my DHCP lease info.

Thanks for the suggestion!

Bob.Dig

@striker-pl Did you reboot? I did.
But I also wanted to use only static mappings in the first place.
Is your ARP-Table "clean"?

striker-pl

@bob-dig no, I did not reboot after the changes. I've got 11 days of uptime, last rebooted to upgrade to the latest build.

I would like to use a mix of static and dhcp assigned mappings.

I'm not sure what you mean by "clean"? How would you suggest I verify that?

Bob.Dig

@striker-pl said in Windows Work PC Can't Resolve Local DNS without FQDN:

I'm not sure what you mean by "clean"? How would you suggest I verify that?

If you have this problem.

striker-pl

@bob-dig OK, I did see some IP addresses in the hostname column of the ARP table, so I cleared the entire ARP table, cleared the DHCP leases, and rebooted pfSense.

Still no improvement in the name resolution from my work PC.

Bob.Dig

@striker-pl To bad. I faced the similar problem, but it is gone here, don't know why. For me it started when I used pfSense 2.5.

striker-pl

@bob-dig thanks anyway for taking the time to read and respond!

Bob.Dig

@striker-pl One last thing, maybe it helps you, didn't helped me though, but it is the same topic: 2.5 connecting via hostname not working across interfaces

But notice that I changed topic after the gap of "24 Days later", where an ACL in Unbound was the problem, not related to the original problem anymore.