Setup DHCP clients without domain
-
When setting up pfSense I was forced to give it a name and a domain. But now all my PCs are something"."domain
Instead of pinging "pc1", now I have to ping "pc1.domain".
Is there any way to remove this?
-
Maybe I haven't explained correctly :)
If there are any doubts, please ask.
-
Yes any device on a network should have a FQDN (fully qualified domain name) to be honest a single label domain was not a very good choice ;)
something like psense.local.lan might have been better. So your pc1.local.lan
pinging pc1 was never resolved via dns since that is not a fully qualified name. Was most likely resolved via broadcast or a host file, etc.
If you want to be able to ping by host name only, you just need to have your domain search suffix correct.. example
C:>ping storage
Pinging storage.local.lan [192.168.1.8] with 32 bytes of data:
Reply from 192.168.1.8: bytes=32 time=1ms TTL=128
Reply from 192.168.1.8: bytes=32 time<1ms TTL=128see I did not put in the local.lan part and storage was resolved via is fqdn.
So if you sniff the traffic while I do that command you see the dns query for the fqdn even though I only put in storage at the cmd line, you see the response - then the arps to find the mac, and then the ping and reply.
If you don't have dns setup, you can still find it - would just be via broadcast or maybe llmnr depending on your clients and network setup, etc.
So second example I turn off my dns server. And found it via LLMNR – this is a multicast dns where the actual client would respond.. See where the answer came from. Didn't come from psense 192.168.1.253 but actually from the storage machine at 192.168.1.8
if I turn off my dns, and disable llmnr on my client - then it would resort to broadcast. See the broadcast out to 192.168.1.255 and then actual storage box answering the query.
Understanding name resolution is key!!
-
Yes any device on a network should have a FQDN (fully qualified domain name) to be honest a single label domain was not a very good choice ;)
something like psense.local.lan might have been better. So your pc1.local.lan
pinging pc1 was never resolved via dns since that is not a fully qualified name. Was most likely resolved via broadcast or a host file, etc.
If you want to be able to ping by host name only, you just need to have your domain search suffix correct.. example
C:>ping storage
Pinging storage.local.lan [192.168.1.8] with 32 bytes of data:
Reply from 192.168.1.8: bytes=32 time=1ms TTL=128
Reply from 192.168.1.8: bytes=32 time<1ms TTL=128see I did not put in the local.lan part and storage was resolved via is fqdn.
So if you sniff the traffic while I do that command you see the dns query for the fqdn even though I only put in storage at the cmd line, you see the response - then the arps to find the mac, and then the ping and reply.
If you don't have dns setup, you can still find it - would just be via broadcast or maybe llmnr depending on your clients and network setup, etc.
So second example I turn off my dns server. And found it via LLMNR – this is a multicast dns where the actual client would respond.. See where the answer came from. Didn't come from psense 192.168.1.253 but actually from the storage machine at 192.168.1.8
if I turn off my dns, and disable llmnr on my client - then it would resort to broadcast. See the broadcast out to 192.168.1.255 and then actual storage box answering the query.
Understanding name resolution is key!!
Well, the issue I was having is that I was trying in Windows Explorer to access \PC1 and it would not do anything. I tried pinging it and it did not reply. I pinged PC1.domain and then it replied. I tried \PC1.domain and that did work perfectly.
That was a few days ago when I started this thread.
Today, I read your post about it being able to be resolved via broadcast or a host file and now I can ping "PC1" and access "\PC1"
I didn't do anything to most host file so then broadcast? The strange thing is that this network configuration has been up for weeks now; Surely it would have broadcasted its host name by now, right?
Well, anyways, at least, it works now…..
And yeah, my domain name is horrible :( I just set that because I honestly did not know what to even set it as!
Since this is a pretty easy change (and doesn't affect anything currently in my network) I might as well change it now.
Right now, I have {hostname}.esxi From your post, a FQDN such as {hostname}.esxi.lan would be better, correct?
Im not a fan of using {hostname}.esxi.lan because it would seem that ALL my LAN devices are virtualized with esxi so {hostname}.local.lan might be better....
Thank you........as always ;)
-
whatever domain you want to use, you can use single label if you want pc1.locadomain - I just am not a fan of it..
As to why something didn't answer broadcast, firewall comes to mind. if wireless AP isolation comes to mind or just dropped traffic.
pc1.riahc3.mydomain works as well.. The possibilities are pretty much endless.
doing \pc1 should work just fine - again understanding name resolution is the KEY!! To troubleshooting such issues you might run into. Most clients will use different methods be it windows, os x, linux, bsd, beOS, etc. etc. You just need to understand what order and which ones your clients use when you want to resolve host names.
