[SOLVED] Resolve by hostname and not IP

Questions about Wi-Fi and other network devices, file sharing, firewalls, connection sharing etc
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Locked
dpack
Level 1
Level 1
Posts: 13
Joined: Tue Apr 17, 2012 2:50 pm

[SOLVED] Resolve by hostname and not IP

Post by dpack »

I have a clean Mint 13 Maya 64bit install on my laptop. I have the LAN connected to my workplace, which is a Windows AD domain. I can ping workstations and servers by IP, but not by hostname. I have the DNS servers statically set on the NIC, as well as the AD domain name in the "search domains" field. I need to be able to communicate with other machines by name and not IP. What piece am I missing to make this happen?
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 2 times in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
stratus_ss

Re: Resolve by hostname and not IP

Post by stratus_ss »

can you post your /etc/resolv.conf

It is my suspicion that resolvconf is the problem. I had a similar problem where I had to disable dnsmasq in
/etc/NetworkManager/NetworkManager.conf

in order for my local dns to work. What was happening was even though resolv.conf/dns servers were set properly they were still resolving to my Internet IP instead of their internal IP

so

Step 1:

make sure you have /etc/resolv.conf
If it doesn't exist, try doing this

Code: Select all

sudo dpkg-reconfigure resolvconf
Step 2:

Your NetworkManger.conf should look like this

Code: Select all

[main]
plugins=ifupdown,keyfile
#dns=dnsmasq

[ifupdown]
managed=false
Step 4:

Restart network manager and see if your dns is now working (this worked for me)
Comradin

Re: Resolve by hostname and not IP

Post by Comradin »

This is a typical problem for domains with the .local tld. Avahi (mDNS) uses this as its default namespace.

There are two solutions:
- like above mentioned you can modify /etc/nsswitch.conf, either by deleting the mDNS entries or by moving the "dns" entrie right behind "files"
- the more drastical solution would be to remove the different avahi packets from your system.

Personally I prefere the second solution, as avahi is rendered kind of useless if you modify the nsswitch.conf file to something like "hosts: files dns". At least your system cannot use avahin any longer for name resolving, but I guess it would still propagate your printer ressources to your lokal network?


Regards,
Marcus
stratus_ss

Re: Resolve by hostname and not IP

Post by stratus_ss »

Modifying the nsswitch.conf shouldn't be necessary since it has files and dns by default. Granted it has mdns4_minimal in between but it should get to the dns part failing the other two.

I also didnt know that the avahi daemon had anything to do with interacting with DNS servers. Unless it was an outward facing server I have always left avahi to do its own thing. Is this something that has changed with a newer version of avahi?
dpack
Level 1
Level 1
Posts: 13
Joined: Tue Apr 17, 2012 2:50 pm

Re: Resolve by hostname and not IP

Post by dpack »

I edited NetworkManger.conf and remmed out dns=dnsmasq. I rebooted my system, but things just got worse. I could still ping by IP, but hostname was still unknown. The worse part is when I discovered I could no longer access anything on the Internet. I reverted the conf file back to its original config, and now, things are back to normal.

I opened Synaptic Package Manager and searched for avahi. There are several packages installed with this keyword. I am concerned about removing them, as it might really break something based on what happened above.

Since I also cannot get samba to access network shares in the domain via IP, I am quickly coming to the conclusion this OS is not ready for use in a work environment that is a Windows domain. However, at home, Mint 13 runs like a champ and I have no plans to go back to Windows there!

Thanks for the help!
Comradin

Re: Resolve by hostname and not IP

Post by Comradin »

stratus_ss wrote:Modifying the nsswitch.conf shouldn't be necessary since it has files and dns by default. Granted it has mdns4_minimal in between but it should get to the dns part failing the other two.

I also didnt know that the avahi daemon had anything to do with interacting with DNS servers. Unless it was an outward facing server I have always left avahi to do its own thing. Is this something that has changed with a newer version of avahi?
No, its just that avahi uses the .local namespace for its own purpose and thus intercepts the question and answeres it finally.

It is like having two nameservers in your resolv.conf, if the first server isn't able to resolve the name it will issue an NXDOMAIN failure and the request is answered for the resolver library, even if the second nameserver could have given an answer.

Problem with .local is, that for example Microsoft uses this TLD for their SmallBusinessServer AD domains. If you're working in such a company with a client computer using avahi/mDNS will cause major trouble. The user can successfully resolve hostnames using 'host' or 'nslookup', as these tools direct question a configured nameserver. Ping, on the other hand, will go the way along the configured path in the nsswitch.conf.

First, look into hosts file. Nothing in it, so, next hop
Second, mDNS/avahi won't find the name and will report so with NXDOMAIN answer.
Third, your DNS server .. this one will never ever be questioned, as the resolver got a final answer from mDNS/avahi already.

I do not blame avahi for this, its just a problem with the dual-use of the .local namespace..


regards,
Marcus
Comradin

Re: Resolve by hostname and not IP

Post by Comradin »

dpack wrote:I opened Synaptic Package Manager and searched for avahi. There are several packages installed with this keyword. I am concerned about removing them, as it might really break something based on what happened above.

Since I also cannot get samba to access network shares in the domain via IP, I am quickly coming to the conclusion this OS is not ready for use in a work environment that is a Windows domain. However, at home, Mint 13 runs like a champ and I have no plans to go back to Windows there!

Thanks for the help!
As I wrote before, you can leave avahi in place and just modify the nsswitch.conf file, that you have the order like this:

Code: Select all

hosts:         files dns m......
I'm used to this for years and I can assure you, it is absolutly safe to remove avahi from your system.

I have avahi in this state:

Code: Select all

% dpkg -l | grep avahi
rc  avahi-autoipd                          0.6.30-5ubuntu2                         Avahi IPv4LL network address configuration daemon
rc  avahi-daemon                           0.6.30-5ubuntu2                         Avahi mDNS/DNS-SD daemon
ii  libavahi-client3                       0.6.30-5ubuntu2                         Avahi client library
ii  libavahi-common-data                   0.6.30-5ubuntu2                         Avahi common data files
ii  libavahi-common3                       0.6.30-5ubuntu2                         Avahi common library
ii  libavahi-core7                         0.6.30-5ubuntu2                         Avahi's embeddable mDNS/DNS-SD library
ii  libavahi-glib1                         0.6.30-5ubuntu2                         Avahi glib integration library
ii  libavahi-gobject0                      0.6.30-5ubuntu2                         Avahi GObject library
ii  libavahi-ui-gtk3-0                     0.6.30-5ubuntu2                         Avahi GTK+ User interface library for GTK3
As you can see, the avahi-daemon package is not installed and Im fine. And I have removed the avahi packages from every distribution I have ever used.


regards,
Marcus
dpack
Level 1
Level 1
Posts: 13
Joined: Tue Apr 17, 2012 2:50 pm

Re: Resolve by hostname and not IP

Post by dpack »

I went back to Windows on my host since I had to work. However, I loaded virtualbox and installed Mint 13 MATE. Now I can work and tinker with Mint as time permits.

I was able to get ping by hostname working with very little modification. All I had to do was edit /etc/resolv.conf. My company's DNS IPs were already listed in the file. The top line says "# Generated by NetWorkManager." Below the nameserver lines, I manually added domain mydomain.net and then rebooted the machine. (Substitue mydomain.net for the actual company domain ie. google.com) Now I can ping any server and workstation in the Windows domain by name.

Example resolv.conf contents:
# Generated by NetworkManager
nameserver 10.10.10.10
nameserver 10.10.10.11
domain google.com

This should help others. Thanks!
Vagabond

Re: [SOLVED] Resolve by hostname and not IP

Post by Vagabond »

I have encountered this same issue on my linux minut 15 system I just built (I've also been struggling with the same issue on an Ubuntu 12.04 system).

I have an Active Directory domain and the AD forest is defined as internaldomain.local, along with a disjoint dns name of externaldomain.com meaning that my internal DNS servers resolve internal IP addresses for my externaldomain.com while external DNS servers like google DNS servers resolve my internet facing IP. With ping and nslookup I was able to resolve the internal IP addresses for my externaldomain.com records, while I was unable to resolve any of the internaldomain.local records using ping while nslookup resolved my internaldomain.local records.

I had tried a number of things until I found this post which enlightened me to the fact that avahi steals (IMO) the entire .local TLD. After I ran the following to remove the avahi daemon mirroring the config posted by Comradin, I am now able to resolve all of my internaldomain.local records.

Code: Select all

sudo apt-get remove avahi-daemon
sudo apt-get remove avahi-autoipd
sudo restart network-manager
(note: I'm not sure if restarting network-manager was needed, but I figured it didn't hurt...)

My next command was ping internaldomain.local which resolved my DC like a champ!

Sorry for resurecting a resolved thread, but I wanted to report how I resolved the issue without needing to downgrade. I'd previously tried the resolution dpack indicated worked on Mint13, but that did not resolve my issue on Mint 15, where removing avahi did resolve this issue for me.

Now hopefully I'll be able to use Centrify Express to join my AD Domain and leverage some kerberos auth. I'd tried once earlier this week, but since I wasn't able to resolve any of my domain controllers by name due to my .local namespace I was unable to authenticate... Wish me luck.

Thank you for the knowledge!
Box293

Re: [SOLVED] Resolve by hostname and not IP

Post by Box293 »

Vagabond wrote:I had tried a number of things until I found this post which enlightened me to the fact that avahi steals (IMO) the entire .local TLD. After I ran the following to remove the avahi daemon mirroring the config posted by Comradin, I am now able to resolve all of my internaldomain.local records.

Code: Select all

sudo apt-get remove avahi-daemon
sudo apt-get remove avahi-autoipd
sudo restart network-manager
I also found this helpful. In my case, as soon as I stopped the service the problem was resolved:

Code: Select all

sudo service avahi-daemon stop
Instead of removing it I just prevented it from starting at boot.

Code: Select all

sudo update-rc.d -f avahi-daemon remove
I did try modifying the nsswitch.conf file, and it seemed to work for the ping command, but it didn't work inside the Firefox address bar. Stopping the service was the key bit for me :D
Dan185818

Re: [SOLVED] Resolve by hostname and not IP

Post by Dan185818 »

Hi, I'm a Windows server admin who has run an Ad consisting of over 100,000 accounts with integrated DNS. I'm trying to learn Linux, and this issue has been driving me crazy. I run Server 2012r2 Essentials at home (gives you a domain, dns, remote access, awesome backups, etc), but uses the .local tld. Having run the AD dns at work, I'm not a newbie at that. This issue (MDNS attempting to resolve the fqdn getting nxdomain) was driving me crazy. I have a dislike of Apple, so no bonjour on my servers, but then I couldn't get to them! Nslookup and dig returned the right data, it just didn't work!

This definitely clears things up, and I'll shortly be disabling and removing a avahi (since I have a real dns server handling the .local domain, it will only cause more problems in the future).

I know this is somewhat old (the ressurect, the original post is way older), but this has saved my Christmas season, since I can continue to tinker during my time off. Thank you all very much!
altair4
Level 20
Level 20
Posts: 11458
Joined: Tue Feb 03, 2009 10:27 am

Re: [SOLVED] Resolve by hostname and not IP

Post by altair4 »

I openly admit that AD is beyond my pay grade since I deal only in small / home networks and I don't mean to be confrontational but I thought even Microsoft advises against using .local suffixes in AD:

https://technet.microsoft.com/en-us/lib ... 0%29.aspx/
We recommend that you use DNS names that are registered with an Internet authority in the Active Directory namespace. Only registered names are guaranteed to be globally unique. If another organization later registers the same DNS domain name (or if your organization merges with, acquires, or is acquired by another company that uses the same DNS name), the two infrastructures cannot interact with one another.
CautionCaution
Do not use single-label DNS names. For more information, see Information about configuring Windows for domains with single-label DNS names (http://go.microsoft.com/fwlink/?LinkId=106631). Also, we do not recommend using unregistered suffixes, such as .local.
Anyway, if the enterprise servers have been configured that way you have no choice but it will be interesting to see how this all works with Windows 10 since that now also uses mDNS to resolve host names.
Please add a [SOLVED] at the end of your original subject header if your question has been answered and solved.
Dan185818

Re: [SOLVED] Resolve by hostname and not IP

Post by Dan185818 »

Microsoft does recommend against using .local. Then goes right ahead and sets it as the default (and if you don't have a registered domain, which for my home network, I do not), possibly forces you to use that TLD with the server essentials (it's been a bit since I've run the installer, so I can't swear by the forcing). I run server 2012 R2 Essentials at home. the AD comment was mainly to show that I do have DNS knowledge/experience above the normal home/business user, and everything on my network uses DNS for resolution of .local. I'm a bit of a control freak, so mDNS does NOT thrill me (if you have zero configuration, you have very, very limited troubleshooting ability, in my experience). "It just works" is fine until it doesn't :D. mDNS feels too much like WINS to me for me to be happy about it.

I definitely didn't take your response as confrontational, and Microsoft's default is stupid (although as recently as 10 years ago, using .local or .lcl WAS the recommended configuration. I'm dealing with tail end of migrating to a .edu instead of .lcl for our AD Domain name so that we can access cloud resources). But it's what I have, and Server Essentials is just way too nice for me to give up, so I have to make the Linux boxes I'm playing with work in that environment. Having to use ip address to access other local boxes was driving me out of my mind (another issue I'm working with. We have an entire department that uses IP addresses instead of names and those servers they use daily urgently need to be moved to a different network with a different IP), especially when nslookup worked!

Regarding the Windows 10 stuff, there is absolutely no issue. I've had several windows 10 vms along with a surface pro 3 on my home network and there has been zero issues with resolving .local names. Knowing tech, the Windows and Linux implementations are most likely different and MS's version doesn't have this incompatibility.
altair4
Level 20
Level 20
Posts: 11458
Joined: Tue Feb 03, 2009 10:27 am

Re: [SOLVED] Resolve by hostname and not IP

Post by altair4 »

What's curious about all this is that Linux is supposed to disable avahi by itself when it's in this situation with a script that looks something like this:
#!/bin/sh

if host -t SOA local. > /dev/null 2> /dev/null ; then
# Hoho! There is a domain .local in unicast DNS! Let's disable Avahi!

if test -x /etc/init.d/avahi ; then
/etc/init.d/avahi stop > /dev/null 2> /dev/null

if test -x /usr/bin/logger ; then
logger -p daemon.warning -t avahi <<EOF
Avahi detected that your currently configured local DNS server serves
a domain .local. This is inherently incompatible with Avahi and thus
Avahi disabled itself. If you want to use Avahi in this network, please
contact your administrator and convince him to use a different DNS domain,
since .local should be used exclusively for Zeroconf technology.
For more information, see http://avahi.org/wiki/AvahiAndUnicastDotLocal
EOF
fi
fi
fi
Must be a bug somewhere in this. I have been in a situation where a persons ISP has DNS servers using .local for some odd reason and they will get an error message that avahi has been disabled. An easy fix in this situation.

Apple does things differently since they've been at this longer. hostname.local is resolved using multicast and server.domain.local by unicast .
Please add a [SOLVED] at the end of your original subject header if your question has been answered and solved.
Locked

Return to “Networking”