Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Local hostname resolution not working

    Scheduled Pinned Locked Moved DHCP and DNS
    7 Posts 2 Posters 850 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      jappish
      last edited by

      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?

      johnpozJ 1 Reply Last reply Reply Quote 0
      • johnpozJ
        johnpoz LAYER 8 Global Moderator @jappish
        last edited by

        @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.

        An intelligent man is sometimes forced to be drunk to spend time with his fools
        If you get confused: Listen to the Music Play
        Please don't Chat/PM me for help, unless mod related
        SG-4860 24.11 | Lab VMs 2.8, 24.11

        1 Reply Last reply Reply Quote 0
        • J
          jappish
          last edited by 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

          johnpozJ 1 Reply Last reply Reply Quote 0
          • johnpozJ
            johnpoz LAYER 8 Global Moderator @jappish
            last edited by

            @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

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 24.11 | Lab VMs 2.8, 24.11

            J 1 Reply Last reply Reply Quote 0
            • J
              jappish @johnpoz
              last edited by

              @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?

              johnpozJ 1 Reply Last reply Reply Quote 0
              • johnpozJ
                johnpoz LAYER 8 Global Moderator @jappish
                last edited by 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.

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 24.11 | Lab VMs 2.8, 24.11

                J 1 Reply Last reply Reply Quote 2
                • J
                  jappish @johnpoz
                  last edited by

                  @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 :)

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.