Local hostname resolution not working

jappish

I found a few posts here on the forums with the same issue, but not sure what I'm missing since I can't get any hostnames resolved locally.

I have the domin set to home.l under "System - General" tab

Under DNS Resolver I have these options set:

DHCP Registration checked Register DHCP leases in the DNS Resolver
Static DHCP checked Register DHCP static mappings in the DNS Resolver
OpenVPN Clients checked Register connected OpenVPN clients in the DNS Resolver

Looking at the arp table I have plenty of clients with hostnames that I manually set during while adding static mappings and I can ping the hostnames using "server.home.l" but trying to access my clients through chrome or edge simply returns a websearch.

What do I need to do to be able to access my servers using local hostname resolution?

johnpoz

@jappish said in Local hostname resolution not working:

my clients through chrome or edge simply returns a websearch.

This would suggest they are using doh vs your local dns, ie pfsense.

If you do a cmd line query for server.home.L (which is a bad choice for a domain) Why would you not just use the recommended home.arpa as your domain?

Use either nslookup, dig or host to do the query.

jappish

Thanks for the reply and for bearing with me.

Not sure what "doh" referes to but I'm guessing not pfsense configured ones.

I've changed the domain to home.arpa now and nslookup seems to return the expected response:

PS C:\Users\user> nslookup webswitch.home.arpa
Server:  pfSense.home.arpa
Address:  192.168.1.1

Name:    webswitch.home.arpa
Address:  192.168.1.236

I've tested with multiple hosts and all return corresponding responses

EDIT:

What I specifically wanna achieve is to be able to connect to my devices with server.local. I can see that .local is discouraged from within pfsense config but my main goal is to get this running because many of the services I use often refer to this and I find myself often needing to change server.local to ip:port for the services to work properly

johnpoz

@jappish .local is horrible tld to use. This is a tld that is used in mdns resolution where no dns is in use.

What you should use to access anything on your system is the fqdn, like your example webswitch.home.arpa

If this resolves to IP where the service is hosted that is all that is needed, if some port is required to be specified then you would use the url say http://webswitch.home.arpa:port

doh is dns over http, and many browsers are defaulting to this unless you turn it off. This uses an external dns and can prevent resolution of your own local resources like webswitch.home.arpa

If you want to resolve local resources, you should disable in your browser the use of doh

jappish

@johnpoz Thank you, I turned off the browsers dns and cleared the dns cache and can now access my clients using the hostname + local domain.

I understand using .local could potentially result in hostname conflicts but since my setup is a home setup with a quite easily managable amount of clients and I'm the only tinkerer in the house I feel that any potential hostname conflicts would be managed quite easily by me, and that potential conflicts are "worth" the extra effort eventually needed as other things will "just work".

Other than hostname conflicts, what other potential issues am I missing with .local?

johnpoz

@jappish its just bad practice because it is the mdns tld that is meant to not actually resolve from dns server, but only local via the mdns protocol on 5353.

The new best practice domain to use locally is home.arpa

https://datatracker.ietf.org/doc/html/rfc8375
Special-Use Domain 'home.arpa.'

In the bigger picture - use whatever you want, if it works for you could use microsoft.com locally ;) but might be a bit of an issue and problematic if you wanted to actually go to some real microsoft.com address on the internet ;)

One issue for me personally if was using host.local - did that resolve from dns, or was it just a mdns discovery, etc. I like to know where my clients resolved something from specifically.

And personally despise local discovery using multicast, etc. If I want some name to resolve to an IP, I will make sure my dns resolves that to the IP I want ;)

And actually go out of my way to turn off multicast like that.. Why should some client bother every single client on my network with a broadcast - hey is this your name? When it can just ask my dns server. 2nd that doesn't even work across networks, and since I have a segmented network.. If some client was asking for host.local and was on another vlan it couldn't resolve it anyway - so its just noise added to the network.. All pointless when host.mydomain.tld resolves specifically from my dns server - just ask it, and don't bother the rest of the network with your noise ;)

edit: Don't mean to turn this into my own personal rant ;) heheh But unwanted noise on a network is guess one of my pet peeves.. Especially if wireless where that sort of multicast nonsense uses the group key and goes out an low bit rate, and sucks performance from your other clients. Prob not a big issue if you have a hand full of clients - but when you have a lot of them..

But if you have a bunch of clients sending out multicast asking hey is your name host.local vs just a unicast packet to the dns.. Its just not a good use of your limited wireless bandwidth that is shared between all your clients.. And the other way around as well, bunch of wired clients on the same vlan where you have wireless clients and multicast going out onto yoru wireless network - for not actual purpose.. When the host your looking for is right there in the local dns.

edit2: This seems to have pushed one of my buttons this morning, so sorry for the rant. While I can see how such local discovery can come in handy for billy's grandmother that just wants to be able to find her printer, but has no clue to how networking works, or dns, etc. ;)

But there are security concerns with such discovery since it is very easy to manipulate, and poison with say Adversary-in-the-Middle sort of attacks.

And I just discovered yesterday that my new pc was still doing it, even though I thought I had disabled it.. Ended up using a powershell cmd that seems to have finally killed it off.. If you want to create protocols that are noisy like that to make life easier for billy bob the home user - fine.. But it should be dead simple easy to turn it all off if I don't want to use it as well.

jappish

@johnpoz Hehe, I really don't see it as rant and I for one am very grateful for the long and detailed response. I think I have a better understanding of it now and have personally had experience with noisy networks (sonos) sending tons of multicast packets flooding the network.

I use home assistant a lot and some features need mDNS specifically to work smoothly and get discovered "magically", and honestly, just the thought of configuring everything manually makes my head ache, because I know I would spend more time with it than I would be happy with :)