ubuntu server not resolving LAN hostnames

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP








up vote
11
down vote

favorite
3












Bit stuck here.



I have 2 machines that cannot resolve LAN hostsnames, unless there are specific entries in /etc/hosts



But other machines on the LAN can resolves hostnames.



My LAN:



  • 1 x Cisco router runnning DD-WRT v24-sp2 with DNSMasq enabled. I've configured this with the hostnames and IPs on my LAN.

  • 1 x Kubuntu 12.10 (resolves all hostnames correctly as long as they are entered into DNSMasq on the router)

  • 2 x NAS (also resolve all names correctly)


  • 1 x Ubuntu Server 12.04 (this does NOT resolve local hostnames unless they are entered into /etc/hosts)


  • 1 x XBMCLive (Dharma) (same - does not resolve unless entries are in /etc/hosts)

How do I get the last 2 to use the DNSMasq entries on the router? Each machine is set to use the router as a nameserver, and all units resolve external addresses correctly.



Thanks.



some more info:



whilst on server, if I ping another PC (wstation)



$ ping wstation
PING wstation.local.domain (x.x.x.x)


If I then append .local



$ ping wstation.local
PING wstation.local.local.domain (x.x.x.x)


and directly



$ ping 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_req=1 ttl=64 time=0.387 ms
64 bytes from 10.0.0.4: icmp_req=2 ttl=64 time=0.316 ms
64 bytes from 10.0.0.4: icmp_req=3 ttl=64 time=0.312 ms
64 bytes from 10.0.0.4: icmp_req=4 ttl=64 time=0.280 ms
64 bytes from 10.0.0.4: icmp_req=5 ttl=64 time=0.322 ms
^C
--- 10.0.0.4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.280/0.323/0.387/0.038 ms









share|improve this question























  • I don't know the answer, and I have no idea if this will be helpful, but in case you didn't know... I discovered that if I appended ".local" after a machine name, it would somehow be found without any configuration needed. It actually helped me because I was specifying addresses, but was needing to keep changing entries when I would add or remove an OS I used for testing, etc. But, by specifying machinename.local, I no longer needed to worry. If you know where this comes from, feel free to tell me. :)
    – Marty Fried
    Jan 19 '13 at 1:32






  • 1




    Hi Marty, thanks for your answer. I've added some more info to the problem to show what happens with .local
    – teracow
    Jan 19 '13 at 21:01














up vote
11
down vote

favorite
3












Bit stuck here.



I have 2 machines that cannot resolve LAN hostsnames, unless there are specific entries in /etc/hosts



But other machines on the LAN can resolves hostnames.



My LAN:



  • 1 x Cisco router runnning DD-WRT v24-sp2 with DNSMasq enabled. I've configured this with the hostnames and IPs on my LAN.

  • 1 x Kubuntu 12.10 (resolves all hostnames correctly as long as they are entered into DNSMasq on the router)

  • 2 x NAS (also resolve all names correctly)


  • 1 x Ubuntu Server 12.04 (this does NOT resolve local hostnames unless they are entered into /etc/hosts)


  • 1 x XBMCLive (Dharma) (same - does not resolve unless entries are in /etc/hosts)

How do I get the last 2 to use the DNSMasq entries on the router? Each machine is set to use the router as a nameserver, and all units resolve external addresses correctly.



Thanks.



some more info:



whilst on server, if I ping another PC (wstation)



$ ping wstation
PING wstation.local.domain (x.x.x.x)


If I then append .local



$ ping wstation.local
PING wstation.local.local.domain (x.x.x.x)


and directly



$ ping 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_req=1 ttl=64 time=0.387 ms
64 bytes from 10.0.0.4: icmp_req=2 ttl=64 time=0.316 ms
64 bytes from 10.0.0.4: icmp_req=3 ttl=64 time=0.312 ms
64 bytes from 10.0.0.4: icmp_req=4 ttl=64 time=0.280 ms
64 bytes from 10.0.0.4: icmp_req=5 ttl=64 time=0.322 ms
^C
--- 10.0.0.4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.280/0.323/0.387/0.038 ms









share|improve this question























  • I don't know the answer, and I have no idea if this will be helpful, but in case you didn't know... I discovered that if I appended ".local" after a machine name, it would somehow be found without any configuration needed. It actually helped me because I was specifying addresses, but was needing to keep changing entries when I would add or remove an OS I used for testing, etc. But, by specifying machinename.local, I no longer needed to worry. If you know where this comes from, feel free to tell me. :)
    – Marty Fried
    Jan 19 '13 at 1:32






  • 1




    Hi Marty, thanks for your answer. I've added some more info to the problem to show what happens with .local
    – teracow
    Jan 19 '13 at 21:01












up vote
11
down vote

favorite
3









up vote
11
down vote

favorite
3






3





Bit stuck here.



I have 2 machines that cannot resolve LAN hostsnames, unless there are specific entries in /etc/hosts



But other machines on the LAN can resolves hostnames.



My LAN:



  • 1 x Cisco router runnning DD-WRT v24-sp2 with DNSMasq enabled. I've configured this with the hostnames and IPs on my LAN.

  • 1 x Kubuntu 12.10 (resolves all hostnames correctly as long as they are entered into DNSMasq on the router)

  • 2 x NAS (also resolve all names correctly)


  • 1 x Ubuntu Server 12.04 (this does NOT resolve local hostnames unless they are entered into /etc/hosts)


  • 1 x XBMCLive (Dharma) (same - does not resolve unless entries are in /etc/hosts)

How do I get the last 2 to use the DNSMasq entries on the router? Each machine is set to use the router as a nameserver, and all units resolve external addresses correctly.



Thanks.



some more info:



whilst on server, if I ping another PC (wstation)



$ ping wstation
PING wstation.local.domain (x.x.x.x)


If I then append .local



$ ping wstation.local
PING wstation.local.local.domain (x.x.x.x)


and directly



$ ping 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_req=1 ttl=64 time=0.387 ms
64 bytes from 10.0.0.4: icmp_req=2 ttl=64 time=0.316 ms
64 bytes from 10.0.0.4: icmp_req=3 ttl=64 time=0.312 ms
64 bytes from 10.0.0.4: icmp_req=4 ttl=64 time=0.280 ms
64 bytes from 10.0.0.4: icmp_req=5 ttl=64 time=0.322 ms
^C
--- 10.0.0.4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.280/0.323/0.387/0.038 ms









share|improve this question















Bit stuck here.



I have 2 machines that cannot resolve LAN hostsnames, unless there are specific entries in /etc/hosts



But other machines on the LAN can resolves hostnames.



My LAN:



  • 1 x Cisco router runnning DD-WRT v24-sp2 with DNSMasq enabled. I've configured this with the hostnames and IPs on my LAN.

  • 1 x Kubuntu 12.10 (resolves all hostnames correctly as long as they are entered into DNSMasq on the router)

  • 2 x NAS (also resolve all names correctly)


  • 1 x Ubuntu Server 12.04 (this does NOT resolve local hostnames unless they are entered into /etc/hosts)


  • 1 x XBMCLive (Dharma) (same - does not resolve unless entries are in /etc/hosts)

How do I get the last 2 to use the DNSMasq entries on the router? Each machine is set to use the router as a nameserver, and all units resolve external addresses correctly.



Thanks.



some more info:



whilst on server, if I ping another PC (wstation)



$ ping wstation
PING wstation.local.domain (x.x.x.x)


If I then append .local



$ ping wstation.local
PING wstation.local.local.domain (x.x.x.x)


and directly



$ ping 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_req=1 ttl=64 time=0.387 ms
64 bytes from 10.0.0.4: icmp_req=2 ttl=64 time=0.316 ms
64 bytes from 10.0.0.4: icmp_req=3 ttl=64 time=0.312 ms
64 bytes from 10.0.0.4: icmp_req=4 ttl=64 time=0.280 ms
64 bytes from 10.0.0.4: icmp_req=5 ttl=64 time=0.322 ms
^C
--- 10.0.0.4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.280/0.323/0.387/0.038 ms






lan hostname hosts dnsmasq






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 19 '13 at 21:10

























asked Jan 19 '13 at 1:24









teracow

58118




58118











  • I don't know the answer, and I have no idea if this will be helpful, but in case you didn't know... I discovered that if I appended ".local" after a machine name, it would somehow be found without any configuration needed. It actually helped me because I was specifying addresses, but was needing to keep changing entries when I would add or remove an OS I used for testing, etc. But, by specifying machinename.local, I no longer needed to worry. If you know where this comes from, feel free to tell me. :)
    – Marty Fried
    Jan 19 '13 at 1:32






  • 1




    Hi Marty, thanks for your answer. I've added some more info to the problem to show what happens with .local
    – teracow
    Jan 19 '13 at 21:01
















  • I don't know the answer, and I have no idea if this will be helpful, but in case you didn't know... I discovered that if I appended ".local" after a machine name, it would somehow be found without any configuration needed. It actually helped me because I was specifying addresses, but was needing to keep changing entries when I would add or remove an OS I used for testing, etc. But, by specifying machinename.local, I no longer needed to worry. If you know where this comes from, feel free to tell me. :)
    – Marty Fried
    Jan 19 '13 at 1:32






  • 1




    Hi Marty, thanks for your answer. I've added some more info to the problem to show what happens with .local
    – teracow
    Jan 19 '13 at 21:01















I don't know the answer, and I have no idea if this will be helpful, but in case you didn't know... I discovered that if I appended ".local" after a machine name, it would somehow be found without any configuration needed. It actually helped me because I was specifying addresses, but was needing to keep changing entries when I would add or remove an OS I used for testing, etc. But, by specifying machinename.local, I no longer needed to worry. If you know where this comes from, feel free to tell me. :)
– Marty Fried
Jan 19 '13 at 1:32




I don't know the answer, and I have no idea if this will be helpful, but in case you didn't know... I discovered that if I appended ".local" after a machine name, it would somehow be found without any configuration needed. It actually helped me because I was specifying addresses, but was needing to keep changing entries when I would add or remove an OS I used for testing, etc. But, by specifying machinename.local, I no longer needed to worry. If you know where this comes from, feel free to tell me. :)
– Marty Fried
Jan 19 '13 at 1:32




1




1




Hi Marty, thanks for your answer. I've added some more info to the problem to show what happens with .local
– teracow
Jan 19 '13 at 21:01




Hi Marty, thanks for your answer. I've added some more info to the problem to show what happens with .local
– teracow
Jan 19 '13 at 21:01










3 Answers
3






active

oldest

votes

















up vote
12
down vote



accepted










About your current output



ping wstation
PING wstation.local.domain


Clearly indicates that your pc is appending .local.domain to non-FQDN queries. This is something configured improperly or at least wrong in your set up. (unless you actually use the .local.domain suffix on purpose)



Name resolving and periods



One important thing what a lot of people don't know, is that a full name should always end with a period (.). If you omit it, then the machine will try to resolve it within the local search domain (e.g. mydomain.tld). So in that case, a query for mypc.local would become mypc.local.mydomain.tld. To prevent this, query with the period.



Resolver configuration



The resolver configuration is of great importance here. In Ubuntu (and Debian) this is configured in the file /etc/network/interfaces (assuming you're not running NetworkManager):



iface eth0 inet static
address 192.168.3.3
netmask 255.255.255.0
gateway 192.168.3.1
dns-nameservers 192.168.3.45 192.168.8.10
dns-search foo.org bar.com # <-- these are the search domains


Name resolving in Linux can also be accomplished in other ways. It's not just that the local DNS server is being queried for all of this. Take a look at your /etc/nsswitch.conf file for the hosts configuration of resolving:



hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4


This means that files are tried first (this is the /etc/hosts file), then mDNS and only later the real DNS server is queried. mDNS is implemented using Avahi in Linux and is called Bonjour on Apple devices. It is using the .local suffix by default and works via broadcast messages. Much like ARP works, but then for DNS.



All these systems can be very confusing and even more when using .local in a regular DNS setup mixed with mDNS devices. I guess this is why you're confused now as to why one device works and the other doesn't: they're not all using the same resolving method.



To sort things out



  • Avoid the use if .local unless you want to rely on mDNS completely. From your question I understand you'd like to keep things configured yourself in a central place, so my approach here is to avoid it.

  • Configure your local DNS server (the DD-WRT device in your case) to use a special domain name, e.g. my.home. For dnsmasq this is a single setting, but in regular setups this should be configured on both the DNS server as well as the DHCP server (as it's being announced via DHCP).

  • Configure all PCs to have a simple and unique host name. They use this in their request for DHCP and this is used in the dnsmasq running on your router to resolve them. Alternatively, configure them manually to not to have to rely on DHCP.

  • Remove any leftover configuration in /etc/resolv.conf in case you fiddled with it in the past.


  • Configure the PCs in your network to use my.home as the local search domain. This can be done via DHCP automatically, or if using static addresses via the /etc/network/interfaces file or in Network Manager:



    enter image description here



  • Now both simple name resolving (ping hostname) as well as full name (ping hostname.my.home) should work.





share|improve this answer


















  • 3




    Wow! Awesome answer gertvdijk! Very comprehensive. So much so, that I'll need some time to understand what you've said. I can say that I tested a ping with a dot after the hostname and it worked correctly. I don't use DHCP on this LAN for the permanent machines. I've never configured the .local settings on any machine as I didn't understand what it was all about. I'll investigate this further as per your instructions and get back to you.
    – teracow
    Jan 19 '13 at 23:58











  • Thankyou for this comprehensive answer. I changed my /etc/nsswitch.conf so that DNS is attempted before mDNS files mdns4_minimal [NOTFOUND=return] dns mdns4. Now everything behaves more like I am expecting with my (poorly named) host.foo.local addressed machines. Before this change ping hostname would work but ping hostname.foo.local was failing. I was getting really confused when dig hostname was failing & dig hostname.foo.local was returning a result, the opposite of what I expected. Now I can ping FQDNs as I expected. Is there a downside to having the order set this way?
    – TafT
    Jan 14 '16 at 10:14


















up vote
1
down vote













Based on the answer by gertvdijk I just commented out the line in nsswitch.conf



sudo vim /etc/nsswitch.conf

.
.
.
hosts: files dns # mdns4_minimal [NOTFOUND=return] dns





share|improve this answer



























    up vote
    0
    down vote













    I got similar issues with a /etc/hosts containing multiple spaces between IP and hostname, instead using a TAB. After changing to TAB the hostname could be resolved by ping.



    127.0.0.1 test.local
    ^^^^^^^^ → Should be a TAB not multiple spaces.


    see also on https://superuser.com/a/938366/467479






    share|improve this answer


















    • 2




      I'm sorry, that is NOT correct. The hosts file will work with spaces or tabs. Also, 127.0.0.1 should have localhost first, followed by localhost.localdomain - and depending on your setup, your machine hostname. (Some setups, Ubuntu/Debian have you put your hostname on the 127.0.1.1 line)I would not recommend installing any .local addresses in the hosts file, though, as they conflict with mDNS/Avahi
      – The Dude
      Oct 20 '16 at 14:02







    • 1




      If you have Windows machines on your domain, apparently it uses unicast DNS, which is not compatible with the Avahi or Zeroconf mDNS implementations. Also, check your /etc/nsswitch.conf to see if it is bailing after mdns4_minimal [NOTFOUND=return] or doing a full mdns4 lookup (move it back). Also, do not configure any DNS servers to use the .local domain, as mDNS/sd-DNS resolvers will mask lookups to that domain. For your internal DNS TLD, use .lan, .work, .home, etc (but NOT one of the new TLDs, like .biz, .xyz, .web, etc...). Good luck, and welcome to the fun world of DNS resolution.
      – The Dude
      Oct 20 '16 at 14:15










    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "89"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f244865%2fubuntu-server-not-resolving-lan-hostnames%23new-answer', 'question_page');

    );

    Post as a guest






























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    12
    down vote



    accepted










    About your current output



    ping wstation
    PING wstation.local.domain


    Clearly indicates that your pc is appending .local.domain to non-FQDN queries. This is something configured improperly or at least wrong in your set up. (unless you actually use the .local.domain suffix on purpose)



    Name resolving and periods



    One important thing what a lot of people don't know, is that a full name should always end with a period (.). If you omit it, then the machine will try to resolve it within the local search domain (e.g. mydomain.tld). So in that case, a query for mypc.local would become mypc.local.mydomain.tld. To prevent this, query with the period.



    Resolver configuration



    The resolver configuration is of great importance here. In Ubuntu (and Debian) this is configured in the file /etc/network/interfaces (assuming you're not running NetworkManager):



    iface eth0 inet static
    address 192.168.3.3
    netmask 255.255.255.0
    gateway 192.168.3.1
    dns-nameservers 192.168.3.45 192.168.8.10
    dns-search foo.org bar.com # <-- these are the search domains


    Name resolving in Linux can also be accomplished in other ways. It's not just that the local DNS server is being queried for all of this. Take a look at your /etc/nsswitch.conf file for the hosts configuration of resolving:



    hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4


    This means that files are tried first (this is the /etc/hosts file), then mDNS and only later the real DNS server is queried. mDNS is implemented using Avahi in Linux and is called Bonjour on Apple devices. It is using the .local suffix by default and works via broadcast messages. Much like ARP works, but then for DNS.



    All these systems can be very confusing and even more when using .local in a regular DNS setup mixed with mDNS devices. I guess this is why you're confused now as to why one device works and the other doesn't: they're not all using the same resolving method.



    To sort things out



    • Avoid the use if .local unless you want to rely on mDNS completely. From your question I understand you'd like to keep things configured yourself in a central place, so my approach here is to avoid it.

    • Configure your local DNS server (the DD-WRT device in your case) to use a special domain name, e.g. my.home. For dnsmasq this is a single setting, but in regular setups this should be configured on both the DNS server as well as the DHCP server (as it's being announced via DHCP).

    • Configure all PCs to have a simple and unique host name. They use this in their request for DHCP and this is used in the dnsmasq running on your router to resolve them. Alternatively, configure them manually to not to have to rely on DHCP.

    • Remove any leftover configuration in /etc/resolv.conf in case you fiddled with it in the past.


    • Configure the PCs in your network to use my.home as the local search domain. This can be done via DHCP automatically, or if using static addresses via the /etc/network/interfaces file or in Network Manager:



      enter image description here



    • Now both simple name resolving (ping hostname) as well as full name (ping hostname.my.home) should work.





    share|improve this answer


















    • 3




      Wow! Awesome answer gertvdijk! Very comprehensive. So much so, that I'll need some time to understand what you've said. I can say that I tested a ping with a dot after the hostname and it worked correctly. I don't use DHCP on this LAN for the permanent machines. I've never configured the .local settings on any machine as I didn't understand what it was all about. I'll investigate this further as per your instructions and get back to you.
      – teracow
      Jan 19 '13 at 23:58











    • Thankyou for this comprehensive answer. I changed my /etc/nsswitch.conf so that DNS is attempted before mDNS files mdns4_minimal [NOTFOUND=return] dns mdns4. Now everything behaves more like I am expecting with my (poorly named) host.foo.local addressed machines. Before this change ping hostname would work but ping hostname.foo.local was failing. I was getting really confused when dig hostname was failing & dig hostname.foo.local was returning a result, the opposite of what I expected. Now I can ping FQDNs as I expected. Is there a downside to having the order set this way?
      – TafT
      Jan 14 '16 at 10:14















    up vote
    12
    down vote



    accepted










    About your current output



    ping wstation
    PING wstation.local.domain


    Clearly indicates that your pc is appending .local.domain to non-FQDN queries. This is something configured improperly or at least wrong in your set up. (unless you actually use the .local.domain suffix on purpose)



    Name resolving and periods



    One important thing what a lot of people don't know, is that a full name should always end with a period (.). If you omit it, then the machine will try to resolve it within the local search domain (e.g. mydomain.tld). So in that case, a query for mypc.local would become mypc.local.mydomain.tld. To prevent this, query with the period.



    Resolver configuration



    The resolver configuration is of great importance here. In Ubuntu (and Debian) this is configured in the file /etc/network/interfaces (assuming you're not running NetworkManager):



    iface eth0 inet static
    address 192.168.3.3
    netmask 255.255.255.0
    gateway 192.168.3.1
    dns-nameservers 192.168.3.45 192.168.8.10
    dns-search foo.org bar.com # <-- these are the search domains


    Name resolving in Linux can also be accomplished in other ways. It's not just that the local DNS server is being queried for all of this. Take a look at your /etc/nsswitch.conf file for the hosts configuration of resolving:



    hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4


    This means that files are tried first (this is the /etc/hosts file), then mDNS and only later the real DNS server is queried. mDNS is implemented using Avahi in Linux and is called Bonjour on Apple devices. It is using the .local suffix by default and works via broadcast messages. Much like ARP works, but then for DNS.



    All these systems can be very confusing and even more when using .local in a regular DNS setup mixed with mDNS devices. I guess this is why you're confused now as to why one device works and the other doesn't: they're not all using the same resolving method.



    To sort things out



    • Avoid the use if .local unless you want to rely on mDNS completely. From your question I understand you'd like to keep things configured yourself in a central place, so my approach here is to avoid it.

    • Configure your local DNS server (the DD-WRT device in your case) to use a special domain name, e.g. my.home. For dnsmasq this is a single setting, but in regular setups this should be configured on both the DNS server as well as the DHCP server (as it's being announced via DHCP).

    • Configure all PCs to have a simple and unique host name. They use this in their request for DHCP and this is used in the dnsmasq running on your router to resolve them. Alternatively, configure them manually to not to have to rely on DHCP.

    • Remove any leftover configuration in /etc/resolv.conf in case you fiddled with it in the past.


    • Configure the PCs in your network to use my.home as the local search domain. This can be done via DHCP automatically, or if using static addresses via the /etc/network/interfaces file or in Network Manager:



      enter image description here



    • Now both simple name resolving (ping hostname) as well as full name (ping hostname.my.home) should work.





    share|improve this answer


















    • 3




      Wow! Awesome answer gertvdijk! Very comprehensive. So much so, that I'll need some time to understand what you've said. I can say that I tested a ping with a dot after the hostname and it worked correctly. I don't use DHCP on this LAN for the permanent machines. I've never configured the .local settings on any machine as I didn't understand what it was all about. I'll investigate this further as per your instructions and get back to you.
      – teracow
      Jan 19 '13 at 23:58











    • Thankyou for this comprehensive answer. I changed my /etc/nsswitch.conf so that DNS is attempted before mDNS files mdns4_minimal [NOTFOUND=return] dns mdns4. Now everything behaves more like I am expecting with my (poorly named) host.foo.local addressed machines. Before this change ping hostname would work but ping hostname.foo.local was failing. I was getting really confused when dig hostname was failing & dig hostname.foo.local was returning a result, the opposite of what I expected. Now I can ping FQDNs as I expected. Is there a downside to having the order set this way?
      – TafT
      Jan 14 '16 at 10:14













    up vote
    12
    down vote



    accepted







    up vote
    12
    down vote



    accepted






    About your current output



    ping wstation
    PING wstation.local.domain


    Clearly indicates that your pc is appending .local.domain to non-FQDN queries. This is something configured improperly or at least wrong in your set up. (unless you actually use the .local.domain suffix on purpose)



    Name resolving and periods



    One important thing what a lot of people don't know, is that a full name should always end with a period (.). If you omit it, then the machine will try to resolve it within the local search domain (e.g. mydomain.tld). So in that case, a query for mypc.local would become mypc.local.mydomain.tld. To prevent this, query with the period.



    Resolver configuration



    The resolver configuration is of great importance here. In Ubuntu (and Debian) this is configured in the file /etc/network/interfaces (assuming you're not running NetworkManager):



    iface eth0 inet static
    address 192.168.3.3
    netmask 255.255.255.0
    gateway 192.168.3.1
    dns-nameservers 192.168.3.45 192.168.8.10
    dns-search foo.org bar.com # <-- these are the search domains


    Name resolving in Linux can also be accomplished in other ways. It's not just that the local DNS server is being queried for all of this. Take a look at your /etc/nsswitch.conf file for the hosts configuration of resolving:



    hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4


    This means that files are tried first (this is the /etc/hosts file), then mDNS and only later the real DNS server is queried. mDNS is implemented using Avahi in Linux and is called Bonjour on Apple devices. It is using the .local suffix by default and works via broadcast messages. Much like ARP works, but then for DNS.



    All these systems can be very confusing and even more when using .local in a regular DNS setup mixed with mDNS devices. I guess this is why you're confused now as to why one device works and the other doesn't: they're not all using the same resolving method.



    To sort things out



    • Avoid the use if .local unless you want to rely on mDNS completely. From your question I understand you'd like to keep things configured yourself in a central place, so my approach here is to avoid it.

    • Configure your local DNS server (the DD-WRT device in your case) to use a special domain name, e.g. my.home. For dnsmasq this is a single setting, but in regular setups this should be configured on both the DNS server as well as the DHCP server (as it's being announced via DHCP).

    • Configure all PCs to have a simple and unique host name. They use this in their request for DHCP and this is used in the dnsmasq running on your router to resolve them. Alternatively, configure them manually to not to have to rely on DHCP.

    • Remove any leftover configuration in /etc/resolv.conf in case you fiddled with it in the past.


    • Configure the PCs in your network to use my.home as the local search domain. This can be done via DHCP automatically, or if using static addresses via the /etc/network/interfaces file or in Network Manager:



      enter image description here



    • Now both simple name resolving (ping hostname) as well as full name (ping hostname.my.home) should work.





    share|improve this answer














    About your current output



    ping wstation
    PING wstation.local.domain


    Clearly indicates that your pc is appending .local.domain to non-FQDN queries. This is something configured improperly or at least wrong in your set up. (unless you actually use the .local.domain suffix on purpose)



    Name resolving and periods



    One important thing what a lot of people don't know, is that a full name should always end with a period (.). If you omit it, then the machine will try to resolve it within the local search domain (e.g. mydomain.tld). So in that case, a query for mypc.local would become mypc.local.mydomain.tld. To prevent this, query with the period.



    Resolver configuration



    The resolver configuration is of great importance here. In Ubuntu (and Debian) this is configured in the file /etc/network/interfaces (assuming you're not running NetworkManager):



    iface eth0 inet static
    address 192.168.3.3
    netmask 255.255.255.0
    gateway 192.168.3.1
    dns-nameservers 192.168.3.45 192.168.8.10
    dns-search foo.org bar.com # <-- these are the search domains


    Name resolving in Linux can also be accomplished in other ways. It's not just that the local DNS server is being queried for all of this. Take a look at your /etc/nsswitch.conf file for the hosts configuration of resolving:



    hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4


    This means that files are tried first (this is the /etc/hosts file), then mDNS and only later the real DNS server is queried. mDNS is implemented using Avahi in Linux and is called Bonjour on Apple devices. It is using the .local suffix by default and works via broadcast messages. Much like ARP works, but then for DNS.



    All these systems can be very confusing and even more when using .local in a regular DNS setup mixed with mDNS devices. I guess this is why you're confused now as to why one device works and the other doesn't: they're not all using the same resolving method.



    To sort things out



    • Avoid the use if .local unless you want to rely on mDNS completely. From your question I understand you'd like to keep things configured yourself in a central place, so my approach here is to avoid it.

    • Configure your local DNS server (the DD-WRT device in your case) to use a special domain name, e.g. my.home. For dnsmasq this is a single setting, but in regular setups this should be configured on both the DNS server as well as the DHCP server (as it's being announced via DHCP).

    • Configure all PCs to have a simple and unique host name. They use this in their request for DHCP and this is used in the dnsmasq running on your router to resolve them. Alternatively, configure them manually to not to have to rely on DHCP.

    • Remove any leftover configuration in /etc/resolv.conf in case you fiddled with it in the past.


    • Configure the PCs in your network to use my.home as the local search domain. This can be done via DHCP automatically, or if using static addresses via the /etc/network/interfaces file or in Network Manager:



      enter image description here



    • Now both simple name resolving (ping hostname) as well as full name (ping hostname.my.home) should work.






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 20 '13 at 0:03

























    answered Jan 19 '13 at 22:07









    gertvdijk

    48.8k18138230




    48.8k18138230







    • 3




      Wow! Awesome answer gertvdijk! Very comprehensive. So much so, that I'll need some time to understand what you've said. I can say that I tested a ping with a dot after the hostname and it worked correctly. I don't use DHCP on this LAN for the permanent machines. I've never configured the .local settings on any machine as I didn't understand what it was all about. I'll investigate this further as per your instructions and get back to you.
      – teracow
      Jan 19 '13 at 23:58











    • Thankyou for this comprehensive answer. I changed my /etc/nsswitch.conf so that DNS is attempted before mDNS files mdns4_minimal [NOTFOUND=return] dns mdns4. Now everything behaves more like I am expecting with my (poorly named) host.foo.local addressed machines. Before this change ping hostname would work but ping hostname.foo.local was failing. I was getting really confused when dig hostname was failing & dig hostname.foo.local was returning a result, the opposite of what I expected. Now I can ping FQDNs as I expected. Is there a downside to having the order set this way?
      – TafT
      Jan 14 '16 at 10:14













    • 3




      Wow! Awesome answer gertvdijk! Very comprehensive. So much so, that I'll need some time to understand what you've said. I can say that I tested a ping with a dot after the hostname and it worked correctly. I don't use DHCP on this LAN for the permanent machines. I've never configured the .local settings on any machine as I didn't understand what it was all about. I'll investigate this further as per your instructions and get back to you.
      – teracow
      Jan 19 '13 at 23:58











    • Thankyou for this comprehensive answer. I changed my /etc/nsswitch.conf so that DNS is attempted before mDNS files mdns4_minimal [NOTFOUND=return] dns mdns4. Now everything behaves more like I am expecting with my (poorly named) host.foo.local addressed machines. Before this change ping hostname would work but ping hostname.foo.local was failing. I was getting really confused when dig hostname was failing & dig hostname.foo.local was returning a result, the opposite of what I expected. Now I can ping FQDNs as I expected. Is there a downside to having the order set this way?
      – TafT
      Jan 14 '16 at 10:14








    3




    3




    Wow! Awesome answer gertvdijk! Very comprehensive. So much so, that I'll need some time to understand what you've said. I can say that I tested a ping with a dot after the hostname and it worked correctly. I don't use DHCP on this LAN for the permanent machines. I've never configured the .local settings on any machine as I didn't understand what it was all about. I'll investigate this further as per your instructions and get back to you.
    – teracow
    Jan 19 '13 at 23:58





    Wow! Awesome answer gertvdijk! Very comprehensive. So much so, that I'll need some time to understand what you've said. I can say that I tested a ping with a dot after the hostname and it worked correctly. I don't use DHCP on this LAN for the permanent machines. I've never configured the .local settings on any machine as I didn't understand what it was all about. I'll investigate this further as per your instructions and get back to you.
    – teracow
    Jan 19 '13 at 23:58













    Thankyou for this comprehensive answer. I changed my /etc/nsswitch.conf so that DNS is attempted before mDNS files mdns4_minimal [NOTFOUND=return] dns mdns4. Now everything behaves more like I am expecting with my (poorly named) host.foo.local addressed machines. Before this change ping hostname would work but ping hostname.foo.local was failing. I was getting really confused when dig hostname was failing & dig hostname.foo.local was returning a result, the opposite of what I expected. Now I can ping FQDNs as I expected. Is there a downside to having the order set this way?
    – TafT
    Jan 14 '16 at 10:14





    Thankyou for this comprehensive answer. I changed my /etc/nsswitch.conf so that DNS is attempted before mDNS files mdns4_minimal [NOTFOUND=return] dns mdns4. Now everything behaves more like I am expecting with my (poorly named) host.foo.local addressed machines. Before this change ping hostname would work but ping hostname.foo.local was failing. I was getting really confused when dig hostname was failing & dig hostname.foo.local was returning a result, the opposite of what I expected. Now I can ping FQDNs as I expected. Is there a downside to having the order set this way?
    – TafT
    Jan 14 '16 at 10:14













    up vote
    1
    down vote













    Based on the answer by gertvdijk I just commented out the line in nsswitch.conf



    sudo vim /etc/nsswitch.conf

    .
    .
    .
    hosts: files dns # mdns4_minimal [NOTFOUND=return] dns





    share|improve this answer
























      up vote
      1
      down vote













      Based on the answer by gertvdijk I just commented out the line in nsswitch.conf



      sudo vim /etc/nsswitch.conf

      .
      .
      .
      hosts: files dns # mdns4_minimal [NOTFOUND=return] dns





      share|improve this answer






















        up vote
        1
        down vote










        up vote
        1
        down vote









        Based on the answer by gertvdijk I just commented out the line in nsswitch.conf



        sudo vim /etc/nsswitch.conf

        .
        .
        .
        hosts: files dns # mdns4_minimal [NOTFOUND=return] dns





        share|improve this answer












        Based on the answer by gertvdijk I just commented out the line in nsswitch.conf



        sudo vim /etc/nsswitch.conf

        .
        .
        .
        hosts: files dns # mdns4_minimal [NOTFOUND=return] dns






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 11 '17 at 13:37









        falnyr

        1213




        1213




















            up vote
            0
            down vote













            I got similar issues with a /etc/hosts containing multiple spaces between IP and hostname, instead using a TAB. After changing to TAB the hostname could be resolved by ping.



            127.0.0.1 test.local
            ^^^^^^^^ → Should be a TAB not multiple spaces.


            see also on https://superuser.com/a/938366/467479






            share|improve this answer


















            • 2




              I'm sorry, that is NOT correct. The hosts file will work with spaces or tabs. Also, 127.0.0.1 should have localhost first, followed by localhost.localdomain - and depending on your setup, your machine hostname. (Some setups, Ubuntu/Debian have you put your hostname on the 127.0.1.1 line)I would not recommend installing any .local addresses in the hosts file, though, as they conflict with mDNS/Avahi
              – The Dude
              Oct 20 '16 at 14:02







            • 1




              If you have Windows machines on your domain, apparently it uses unicast DNS, which is not compatible with the Avahi or Zeroconf mDNS implementations. Also, check your /etc/nsswitch.conf to see if it is bailing after mdns4_minimal [NOTFOUND=return] or doing a full mdns4 lookup (move it back). Also, do not configure any DNS servers to use the .local domain, as mDNS/sd-DNS resolvers will mask lookups to that domain. For your internal DNS TLD, use .lan, .work, .home, etc (but NOT one of the new TLDs, like .biz, .xyz, .web, etc...). Good luck, and welcome to the fun world of DNS resolution.
              – The Dude
              Oct 20 '16 at 14:15














            up vote
            0
            down vote













            I got similar issues with a /etc/hosts containing multiple spaces between IP and hostname, instead using a TAB. After changing to TAB the hostname could be resolved by ping.



            127.0.0.1 test.local
            ^^^^^^^^ → Should be a TAB not multiple spaces.


            see also on https://superuser.com/a/938366/467479






            share|improve this answer


















            • 2




              I'm sorry, that is NOT correct. The hosts file will work with spaces or tabs. Also, 127.0.0.1 should have localhost first, followed by localhost.localdomain - and depending on your setup, your machine hostname. (Some setups, Ubuntu/Debian have you put your hostname on the 127.0.1.1 line)I would not recommend installing any .local addresses in the hosts file, though, as they conflict with mDNS/Avahi
              – The Dude
              Oct 20 '16 at 14:02







            • 1




              If you have Windows machines on your domain, apparently it uses unicast DNS, which is not compatible with the Avahi or Zeroconf mDNS implementations. Also, check your /etc/nsswitch.conf to see if it is bailing after mdns4_minimal [NOTFOUND=return] or doing a full mdns4 lookup (move it back). Also, do not configure any DNS servers to use the .local domain, as mDNS/sd-DNS resolvers will mask lookups to that domain. For your internal DNS TLD, use .lan, .work, .home, etc (but NOT one of the new TLDs, like .biz, .xyz, .web, etc...). Good luck, and welcome to the fun world of DNS resolution.
              – The Dude
              Oct 20 '16 at 14:15












            up vote
            0
            down vote










            up vote
            0
            down vote









            I got similar issues with a /etc/hosts containing multiple spaces between IP and hostname, instead using a TAB. After changing to TAB the hostname could be resolved by ping.



            127.0.0.1 test.local
            ^^^^^^^^ → Should be a TAB not multiple spaces.


            see also on https://superuser.com/a/938366/467479






            share|improve this answer














            I got similar issues with a /etc/hosts containing multiple spaces between IP and hostname, instead using a TAB. After changing to TAB the hostname could be resolved by ping.



            127.0.0.1 test.local
            ^^^^^^^^ → Should be a TAB not multiple spaces.


            see also on https://superuser.com/a/938366/467479







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 20 '17 at 10:04









            Community♦

            1




            1










            answered Jul 9 '15 at 12:42









            Thomas Lauria

            1012




            1012







            • 2




              I'm sorry, that is NOT correct. The hosts file will work with spaces or tabs. Also, 127.0.0.1 should have localhost first, followed by localhost.localdomain - and depending on your setup, your machine hostname. (Some setups, Ubuntu/Debian have you put your hostname on the 127.0.1.1 line)I would not recommend installing any .local addresses in the hosts file, though, as they conflict with mDNS/Avahi
              – The Dude
              Oct 20 '16 at 14:02







            • 1




              If you have Windows machines on your domain, apparently it uses unicast DNS, which is not compatible with the Avahi or Zeroconf mDNS implementations. Also, check your /etc/nsswitch.conf to see if it is bailing after mdns4_minimal [NOTFOUND=return] or doing a full mdns4 lookup (move it back). Also, do not configure any DNS servers to use the .local domain, as mDNS/sd-DNS resolvers will mask lookups to that domain. For your internal DNS TLD, use .lan, .work, .home, etc (but NOT one of the new TLDs, like .biz, .xyz, .web, etc...). Good luck, and welcome to the fun world of DNS resolution.
              – The Dude
              Oct 20 '16 at 14:15












            • 2




              I'm sorry, that is NOT correct. The hosts file will work with spaces or tabs. Also, 127.0.0.1 should have localhost first, followed by localhost.localdomain - and depending on your setup, your machine hostname. (Some setups, Ubuntu/Debian have you put your hostname on the 127.0.1.1 line)I would not recommend installing any .local addresses in the hosts file, though, as they conflict with mDNS/Avahi
              – The Dude
              Oct 20 '16 at 14:02







            • 1




              If you have Windows machines on your domain, apparently it uses unicast DNS, which is not compatible with the Avahi or Zeroconf mDNS implementations. Also, check your /etc/nsswitch.conf to see if it is bailing after mdns4_minimal [NOTFOUND=return] or doing a full mdns4 lookup (move it back). Also, do not configure any DNS servers to use the .local domain, as mDNS/sd-DNS resolvers will mask lookups to that domain. For your internal DNS TLD, use .lan, .work, .home, etc (but NOT one of the new TLDs, like .biz, .xyz, .web, etc...). Good luck, and welcome to the fun world of DNS resolution.
              – The Dude
              Oct 20 '16 at 14:15







            2




            2




            I'm sorry, that is NOT correct. The hosts file will work with spaces or tabs. Also, 127.0.0.1 should have localhost first, followed by localhost.localdomain - and depending on your setup, your machine hostname. (Some setups, Ubuntu/Debian have you put your hostname on the 127.0.1.1 line)I would not recommend installing any .local addresses in the hosts file, though, as they conflict with mDNS/Avahi
            – The Dude
            Oct 20 '16 at 14:02





            I'm sorry, that is NOT correct. The hosts file will work with spaces or tabs. Also, 127.0.0.1 should have localhost first, followed by localhost.localdomain - and depending on your setup, your machine hostname. (Some setups, Ubuntu/Debian have you put your hostname on the 127.0.1.1 line)I would not recommend installing any .local addresses in the hosts file, though, as they conflict with mDNS/Avahi
            – The Dude
            Oct 20 '16 at 14:02





            1




            1




            If you have Windows machines on your domain, apparently it uses unicast DNS, which is not compatible with the Avahi or Zeroconf mDNS implementations. Also, check your /etc/nsswitch.conf to see if it is bailing after mdns4_minimal [NOTFOUND=return] or doing a full mdns4 lookup (move it back). Also, do not configure any DNS servers to use the .local domain, as mDNS/sd-DNS resolvers will mask lookups to that domain. For your internal DNS TLD, use .lan, .work, .home, etc (but NOT one of the new TLDs, like .biz, .xyz, .web, etc...). Good luck, and welcome to the fun world of DNS resolution.
            – The Dude
            Oct 20 '16 at 14:15




            If you have Windows machines on your domain, apparently it uses unicast DNS, which is not compatible with the Avahi or Zeroconf mDNS implementations. Also, check your /etc/nsswitch.conf to see if it is bailing after mdns4_minimal [NOTFOUND=return] or doing a full mdns4 lookup (move it back). Also, do not configure any DNS servers to use the .local domain, as mDNS/sd-DNS resolvers will mask lookups to that domain. For your internal DNS TLD, use .lan, .work, .home, etc (but NOT one of the new TLDs, like .biz, .xyz, .web, etc...). Good luck, and welcome to the fun world of DNS resolution.
            – The Dude
            Oct 20 '16 at 14:15

















             

            draft saved


            draft discarded















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f244865%2fubuntu-server-not-resolving-lan-hostnames%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            pylint3 and pip3 broken

            Missing snmpget and snmpwalk

            How to enroll fingerprints to Ubuntu 17.10 with VFS491