How to facilitate "hostname.local" name resolution with pfSense?
-
@princ3ssa said in How to facilitate "hostname.local" name resolution with pfSense?:
and has a static ip set on it (not static through the DHCP server on pfsense)
well sure you can get anything to resolve, you could resolve www.google.com to 192.168.1.100 if you wanted to. But if you do not have dhcp reservation for it through pfsense, even if not being leveraged then no it wouldn't show up in pfsense dns. Unless you create a host override.
So you have to easy methods to get server1.whatever.tld to resolve. either create a static reservation for it in the dhcp server, be it that actual client uses that reservation or not.
Or just host override in the unbound dns section.
-
I wonder: is there a way to set up the host overrides from ssh commands to pfsense maybe? That might make the situation more palatable and easy to update instead of working so hard to make some hostnames autopopulate in some other way or even installing some mdns client/server/whatever on each host?
-
@princ3ssa not sure why setting up a dhcp reservation would be so hard, its a one time thing.. I mean it is way better than setting static on a device.
With a reservation the client will always have the same IP, unless you at some point want to change. It also allows you to update stuff like dns or ntp, etc.
I wouldn't setup a static on a device ever, unless it was some iot sort of device that had no support for for dhcp at all.
How many devices are you talking - you know you could load in either host overrides or even dhcp reservations via editing of the xml file.
This is normally a one and done sort of thing.. Not like something you have to change very often, only time would be normally adding a new device.
-
It's not a one time setting if you're setting up docker and other containers pretty frequently.
-
@princ3ssa said in How to facilitate "hostname.local" name resolution with pfSense?:
It's not a one time setting if you're setting up docker and other containers pretty frequently.
And how exactly are you doing your dockers - mine all use the host IP, they do not have a unique IP on the network, they have unique ports sure. But again, setting a dns entry via host override literally takes all of 3 seconds.. ;)
I currently only have 3 different dockers that I access via fqdn, just simple host override for whatever name I want to use to point to the IP of the host.
-
So outside of docker containers, LXCs with their own dedicated IPs and other various VM servers. Lots of complexity in the way of dedicated IP addresses go.
Yeah, no. I don't like doing things with a gui when I can set up a reliable scripted method. I don't really care about the 3 seconds when it can be basically a script call and an ip or a script call from the host and get the ip with the script and voila.
-
@princ3ssa pfsense is all about the gui.. not really meant for cli sort of commands. But you could prob script something up. But if you setup a reservation for the IP, the fqdn would be there already..
I would have to look if there some way you could do that all from a cli command, never looked into doing something like that since I have never ran into needing something like that.
-
@princ3ssa said in How to facilitate "hostname.local" name resolution with pfSense?:
I don't like doing things with a gui when I can set up a reliable scripted method.
My understanding is pfsense is designed to be principally controlled via it's GUI. Doing so ensures modifications are checked, and changes are applied it the intended locations and order.
While it is perfectly possible to control the underlying FreeBSD 12.3 directly, doing so risks that if a program is not used as designed it by not behave as expected.
-
@princ3ssa said in How to facilitate "hostname.local" name resolution with pfSense?:
working so hard to make some hostnames autopopulate
Hard ??
All you managed to do, using the same time, is "breaking your DNS". ;)In a perfect world (IMHO) :
When you buy a device, like a phone, printer desktop PC or even a server type device like a NAS, file server, etc, you do not change its network settings.
That's very long for : do nothing, leave it toe the always default "DHCP" (client mode).
Done.
Now comes the "admin" mission.
Connect the device to your pfsense lan network.
Look aththe DHCP server log on pfsense, and see what new device just asked for a DHCP lease : copy the MAC
Or even better : locate the new lease on the Status DHCP Leases page :
and click on the + symbol (the inner white one).
Now, on the page that comes up, give it a "Client identifier" (a network name) like "nas", an IPv4 (outside of the DHCP server pool of that nework) and a DNS host name, like 'nas'.
Done. No need to do more.Because you chose the dns name, it won't have a stupid name like
Ping from any device to this new "nas.local.lan" right ,now and it will work out of the box, right away, forever.
That wasn't hard - right ?It will work because :
You have kept all LAN device on "DHCP", so they will obtain an IP, a network, a gateway, a DNS ( !!) server ( it will be the pfsense lan address )
Because every LAN device will ask 'pfsense' to resolve a fqdn, and pfsense (unbound) knows all about local known devices fqdns, it will know about "nas.local.lan".
If the fqdn isn't "local.lan", then unbound knows it has to ask 'above' : it goes out resolving for you.All 'naming' should be done and kept on a DNS server, pfSense/unbound in this case, that's how the Internet works.
That's how your local network should work.Btw : nice side effect : all your 'important' devices will always have the same IPv4.
Phones and other BYOD do not need a static MAC DHCP lease, you can keep them in your DHCP pool, random IPv4 will get used.Making static leases is important as you probably really want to know about all this before your network start using IPv6. Working with IPv6 is the real pain, so better get your DNS act together before things get serious.
@patch said in How to facilitate "hostname.local" name resolution with pfSense?:
My understanding is pfsense is designed to be principally controlled via it's GUI. Doing so ensures modifications are checked, and changes are applied it the intended locations and order.
While it is perfectly possible to control the underlying FreeBSD 12.3 directly, doing so risks that if a program is not used as designed it by not behave as expected.Yep. Why bother with a GUI ? Download FreeBSD, install it, and you'll have all the tools onboard to do firewalling, routing, DHCPd some DNS, etc.
You'll be editing config files. Now you will obtain what's being called 'hands on experience'. You can even sell your mouse, as (native, without some GUI package) FreeBSD is keyboard only. -
Snarkydy snark snark doesn't do much good in this world in real communiques. Let's try to keep it sincere and real instead of being so passive aggressive, k?
-
Aggressive where ?
Your 'hard' word was related to your name resolution issue.
Some explanation and examples how everything is related might have helped (I thought).
Was trying to convince you. No one knows everything.
