Avahi daemon prevents resolution of FQDNs ending in ".local" due to false negatives in the detection of ".local" networks

What happens if you try to do a dns lookup for the fully qualified domain name? (i.e. dig computer1.mydomain.local)

Using NSLookup works fine for both computer1 and computer1.mydomain.local

Its only if I try to ping or resolve the FQDN in a shell or app other than nslookup.

On my Feisty install I don't have any problems resolving fully qualified domain names.

Are the fully qualified domain names names that are the same as your computers domain name? I can resolve domain names that are not a part of my local domain, ie, www.kubuntu.org resolves fine, its just when you try to resolve fully qualified domain names when the domain name is the same as the machine your on., ie, computer1.mydomain.local...

I have the same problem.
DNS/DHCP Server: Linksys WRT54G router with DD-WRT Firmware (dnsmasq as dhcp/dns server)
Client Computers (OS): Edgy, Feisty (fresh install, updates installed)
network-manager is connecting through dhcp (search domain is automatically defined in resolv.conf)

In feisty it isn't possible to resolve a local fqdn (computer.mydomain.local)... but resolving internet domains is no problem!
dns lookup works in edgy and feisty.
ping and e.g. firefox can't resolve my domain.local.

So i can't access my local ftp/http server with the fqdn, but using only the hostname or ip makes no trouble.

Could this be related to avahi or new network-manager version?
I will have to do some more tests.

Ok, just disabled avahi through network configuration tool...

Now i can access my local ftp/http server with fqdn again! Ping does also work again!

Don't know anything about avahi, but deactivated it seems to be a working workaround.

Hope that someone with detailed information about avahi could solve this bug.

Could someone else test/confirm whether that is avahi related? (look at my previous post)

I have this same problem on 7.04 beta.
Avahi uses the .local as its SOA. Because you use it internally avahi causes conflict.

What should happen is that avahi should warn you that you are using .local as part of yout fqdn and offer to disable itself in a bubble.

For now, I have changed my internal domain name to .private instead of .local
This doesn't fix the issue that avahi is not warning us about the conflict though

Rod, Michael,

Can you run "host -t soa local"
and post back the results?

$ host -t soa local
Host local not found: 3(NXDOMAIN)

zigford, are you sure that this command is correct? host tries to interpret local as hostname.

$ host -t soa hostname
hostname.domain.local has no SOA record

I am using dnsmasq as dns server (look at one of my previous posts for more details).

$ host -a hostname
Trying "hostname.domain.local"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5071
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;hostname.domain.local. IN ANY

;; ANSWER SECTION:
hostname.domain.local. 0 IN A XXX.XXX.XXX.XXX

Received 62 bytes from XXX.XXX.XXX.YYY#53 in 3 ms

For now i have changed my tld to ".site" => Problem is gone, I am happy again ;)

Okay, I have changed to "jspeed.private" as my tld
When I go "host -t soa private"
I get:

chichi:~ harrisj$ host -t soa private
Host private not found: 3(NXDOMAIN)
chichi:~ harrisj$

When I go "host -s soa jspeed.private"
I get:
chichi:~ harrisj$ host -t soa jspeed.private
jspeed.private has SOA record ns.jspeed.private. root.jspeed.private. 1269 10800 3600 604800 38400

Can someone who knows more about avahi comment? My understanding is that avahi uses .local as its tld
So when it checks to see if there is already a .local soa on the network it is correct that it hasn't found one.

There is a mydomain.local on the network, which shouldn't make a difference to avahi or any local dns server. Is my understanding of avahi correct? If so, this is probably a bug higher up in the chain rather than the ubuntu packaging. Probably needs to be reported if it hasn't already.

Good morning,

I noticed the last post was from 2007-03, are you still having problems with this document? If so how can I help to make it receive getter visibility?

I renamed my internal DNS to avoind the conflict. Others may still have the problem though.

This problem still exists in Gutsy Tribe 5.

I am having this issue on Feisty and found this bug thread today.
avahi-daemon 0.6.17
When I stop the avahi-daemon using:
"sudo avahi-daemon -k"
I am able to ping things.mydomain.local
When I start it again using:
"sudo avahi-daemon -D"
pings to things.mydomain.local stop working.

I can confirm this problem on feisty (7.05). avahi should really warn about this. You swear a lot 'wtf?!?' until you get the idea that avahi is the problem.

See
http://www.avahi.org/wiki/AvahiAndUnicastDotLocal
(includes a suggestion for package maintainers)

And sadly
http://www.faqs.org/rfcs/rfc2606.html
does not contain a reserved TLD for such cases ...

Best regards
Georg Sauthoff

[Expired for avahi (Ubuntu) because there has been no activity for 60 days.]

The bigger problem in large organizations is that the use of domain names ending in .local is the recommendation from Microsoft for server 2000 and 2003 configurations. It's also well documented in other places.

It's unfortunate that .local was chosen for mDNS. In many cases, (mine included), we have hundreds of machines already configured with the .local domain name, plus internal Intranet servers, SQL services etc. It's going to take some major time to fix the problem, just so people can use Linux boxes with avahi installed out of the box.

Ok, I spent the last WEEK trying to figure out what was going on before stumbling on this thread. I consult for a school with 500 machines using the Microsoft recommended .local domain name.

So what's the fix? Turn off avahi permanently?

Looks like turning it off is the best fix for now.
You can go under System>Administration>Services
Then Uncheck "Multicast DNS service Discovery (avahi-daemon)"

Hi,

The problem is that on a large network avahi plays a large role in finding
shares and printers. It makes this a lot more difficult to shut it down.

Dominic

On 11/9/07, slyride <email address hidden> wrote:
>
> Looks like turning it off is the best fix for now.
> You can go under System>Administration>Services
> Then Uncheck "Multicast DNS service Discovery (avahi-daemon)"
>
> --
> problems resolving fully qualified domain names on Kubuntu feisty
> https://bugs.launchpad.net/bugs/80900
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Marking as confirmed. This is a known issue.

Unfortunately the .local detection script does not work if no root "local." domain exists. A possible fix may be to have libnss-mdns not lookup .local hosts with more than 2 labels i.e. lookup test.local but not machine.test.local

Seems all MS networks always will use host-names in the form of host.DOMAIN.local correct? Is there any host.local case?

>> Seems all MS networks always will use host-names in the form of host.DOMAIN.local correct?

I'm not sure that will *always* be the case, but it has been the case in every local domain I've ever seen. Your fix sounds good to me.

This probably needs more testing, especially on the Samba side of things before this is accepted as fix. I can't speak on the Samba side myself, as I have no reason to join my *nix machines to our AD, so I don't, but if Samba emulates the lookups that Windows clients perform, this will still break things badly.

Client does DNS lookup for domain.local to return _svr records to tell the workstation where they can find LDAP/Global Catalog (login) servers. I have no idea if this affects *nix Samba clients in the same way.

My company has come up against this problem time and again. Our most reliable solution is to purge avahi-daemon, avahi-autoipd, and libnss-mdns, which allows networking to work automatically.

> on a large network avahi plays a large role in finding
> shares and printers

Printer recognition still works the right way, in part because CUPS depends on avahi client libraries that allow it to hear the printer. (It's rarely a problem anyway because the printer setup can scan for print servers listening on port 9100.)

The practice of using .local is problematic in every case because it's not a IANA TLD. (The current legal TLDs can be found at http://data.iana.org/TLD/tlds-alpha-by-domain.txt) Leakage from private networks causes a burden on the IANA servers and needlessly soaks up bandwidth on the Internet at large. (It is estimated that About 1/4 to 1/2 of the 206 traffic sent to the Root DNS Servers are related to the .local zone.) Several recommendations have been floated to solve the problem, but the problem persists. See, e.g., http://www.tools.ietf.org/html/draft-kato-dnsop-local-zones-00 (2003), http://www.isaserver.org/tutorials/2004illegaltldsplitdns.html (2005) (recommending split DNS zones and providing detailed implementation instructions), http://staff.science.uva.nl/~delaat/sne-2006-2007/p21/report.pdf (2007), http://ftp.kaist.ac.kr/pub/internet-drafts/draft-hardaker-dnsops-name-server-management-reqs-03.txt at Section A.1 (2008), http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-04.txt (2008).

From a best practices standpoint, we are recommending to business clients that networks using "example.local" networks (e.g., MS Active Directory networks) change to "local.example.com", and in the rare cases where avahi is useful, reconfigure avahi to broadcast on and listen for "mdns.example.com", "avahi.example.com", or other non-ambiguous FQDN. The public DNS server adds an A record for local.example.com mapping to the IP address of the public resource administering the local namespace, and the private DNS server would be configured like any other server for the namespace. Using this practice, any leakage to the public Internet is handled seamlessly by DNS. Further, in view of several proposals for .local to be recognized as a TLD, any future formalization to the .local namespace would not affect the local network.

Best practice for home users or other instances where the network does not have a registered FQDN would be to set the fallback avahi domain to local.avahi.org and add to the /etc/resolv.conf file "search local.avahi.org". Again, any leakage would fail without burden to the Internet (or at least only to the avahi.org domain and not the public IANA servers). Implementation is easily accomplished by editing the resolvconf scripts.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

A simple solution to this problem is implied here: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/153644
Changing the /etc/nsswitch.conf file's hosts line from

 hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

to

 hosts: files dns mdns4_minimal [NOTFOUND=return] mdns4

solves the problem. I'm still uncertain of the usefulness of avahi, but at least it's not in the way.

Thanks nitecode. This problem was so annoying. Simple change in /etc/nsswitch.conf
hosts: files dns mdns4_minimal [NOTFOUND=return] mdns4
solved the problem. This should fixed in default configuration.

Can it be like this?

hosts: files mdns4_minimal dns [NOTFOUND=return] mdns4

So that the dns comes before the notfound

so that mdns is checked first then dns?

Thanks.

Bug 327362 is about the daemon being disabled when their ISP DNS has .local in it.

This bug is causing a lot of problems. As the avahi-daemon is enabled by default, you need a great deal of knowledge to know what is going on here. For instance, our Microsoft network in the office uses the popular .local pseudo domain.

When connected to the VPN:

ping server - Works fine
ping server.ourdomain.local - Times out.

When in the office, and on the local LAN, I can't resolve .local hostnames at all when using actual services (i.e. SSH, ping etc).

To compound things, lookups using dig, host or nslookup commands all work fine. Thereby confusing me even further.

If I do:

sudo /etc/init.d/avahi-daemon stop

Magically, FQDN lookups work again. It took me a long time to find this out :)

FQDN lookups on .local domains are essential to a lot of people who use a Microsoft network and DNS servers. What about people connecting via a VPN? The avahi-daemon will start before the VPN connection, so detecting a '.local' domain at that point wouldn't help.

Changing the line to:

hosts: files dns mdns4_minimal [NOTFOUND=return] mdns4

....Works! Can this be the default,...and, can it be put into a Jaunty patch? Think it will help out a lot of people....

thanks,

Chris

We found that disabling the Avahi daemon helped. The problem we found seems to lie in the fact that whenever we tried to do a lookup / ping for a host on the .local doman, the system would append .local to it again.

Therefore when we did:

ping ourhost.companyname.local we actually got ping ourhost.companyname.local.companyname.local

Just thought the info might help (it may already be posted but I didn't want to read through everything!)

We found that disabling the Avahi daemon helped. The problem we found seems to lie in the fact that whenever we tried to do a lookup / ping for a host on the .local domain, the system would append .local to it again.

Therefore when we did:

ping ourhost.companyname.local we actually got ping ourhost.companyname.local.companyname.local

Just thought the info might help (it may already be posted but I didn't want to read through everything!)

Apologies for double post. Also, can we get this bumped up from medium importance? I'd say this is a pretty big issue considering many organisations use .local

Please increase the importance of this issue, it really needs to get fixed.

I would like to second the request for a different default nsswitch.conf.

Frankly, I don't understand why the default is:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

This says if something is not found in the .local TLD don't bother looking in dns. I would suggest either putting the dns in front of mdns4_minimal or simply removing the NOTFOUND status command. That will allow lookups in the .local TLD to failover to DNS instead of explicitly blocking that failover.

Because I've seen some reports of issues after changing the order of statements, I've put my dns entry in front of mdns4_minimal and everything if working well for me now.

Bug still present in Lucid ...

Same symptoms, same resolution : by deactivating avahi or by fixing the nsswich.conf

yep - please increase importance. it's annoying for all the poeple using ubuntu in business. not all will find the workaround for this bug quickly.

Yes, I encountered the same problem. But I fixed it.

In /usr/lib/avahi/avahi-daemon-check-dns.sh I replaced string here:

# OUT=`LC_ALL=C host -t soa local. 2>&1`
# if [ $? -eq 0 ] ; then
# if echo "$OUT" | egrep -vq 'has no|not found'; then
# return 0
# fi
# else.
    # Checking the dns servers failed. Assuming no .local unicast dns, but
    # remove the nameserver cache so we recheck the next time we're triggered
# rm -f ${NS_CACHE}
# return 1
# fi

to this:

  OUT=`LC_ALL=C awk '/^nameserver/ {print $2}' /etc/resolv.conf`
  if [ $? -eq 0 ]; then
    for INDEX in $OUT; do
      if `host -t soa $INDEX | grep -qE 'local'`; then
          return 0
      fi;
    done;
  else
  # Checking the dns servers failed. Assuming no .local unicast dns, but
  # remove the nameserver cache so we recheck the next time we're triggered
    rm -f ${NS_CACHE}
    return 1
  fi

May be it is not correct. but it works for me.

Had this problem and my boss had this simple fix. none of the more complicated solutions worked for me anyway

open
/etc/default/avahi-daemon

change
AVAHI_DAEMON_START=1
to
AVAHI_DAEMON_START=0

stop service
sudo /etc/init.d/avahi-daemon restart

Just ran into this myself with 12.04.

The problem is nsswitch.conf is:

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

which means looks up check hosts, mdns and if mdns reports a not found then it doesn't go to DNS.

Switching it to

hosts: files dns mdns4_minimal [NOTFOUND=return] mdns4

fixes it by having DNS get checked first. IMO this should be the out-of-the-box configuration since the historical trend would be the DNS is serving names and should get precedence anyway.

I ran into this bug as well on 12.04.2. The nsswitch.conf edit fixed it for me. Can we please get this as default configuration?

Will wrote:
> hosts: files dns mdns4_minimal [NOTFOUND=return] mdns4

I don't see the point of putting "mdns4_minimal" before "mdns4". Just "mdns4" should be equivalent and faster, but maybe I'm missing something.

Jeremy wrote:
> The nsswitch.conf edit fixed it for me.
> Can we please get this as default configuration?

1. Jeremy, does the following also work?

    hosts: files mdns4_minimal dns mdns4

(I.e., *without* the "[NOTFOUND=return]".)

2. Upstream's documentation

    http://avahi.org/wiki/AvahiAndUnicastDotLocal

says

    If you come across a network where .local is a unicast
    DNS domain, please contact the local administrator
    and ask him to move his DNS zone to a different domain.
    If this is not possible, we recommend not to use Avahi
    in such a network at all.

So editing nsswitch.conf is not the recommended solution. Removing avahi is the recommended solution. Obviously we shouldn't require the user to do this by hand. Avahi should be disabled automatically on such a network. Now, apparently avahi tries to do this (if AVAHI_DAEMON_DETECT_LOCAL=1 in /etc/default/avahi-daemon) but this doesn't always work properly; see, e.g., bug #327362.

Here's what Mac OS X 10.6 does (http://support.apple.com/kb/HT3473). (Bonjour plays the same role as avahi.)

«Host names that contain only one label in addition to local, for example "My-Computer.local", are resolved using Multicast DNS (Bonjour) by default. Host names that contain two or more labels in addition to local, for example "server.domain.local", are resolved using a DNS server by default.

Additionally, Mac OS X v10.6 automatically detects when the local network operator has set up a name server that will answer name requests for a domain ending in ".local". It does this by checking to see if there is a Start Of Authority (SOA) record for the top level domain "local", which is how a DNS server indicates that it claims to have authority over a part of the DNS namespace. As long as the DNS server is properly configured with the required SOA record, Mac OS X v10.6 will detect this SOA record and automatically use this server to look up all host names in the domain.»

Will Rouesnel wrote:
> Switching it to
> hosts: files dns mdns4_minimal [NOTFOUND=return] mdns4
> fixes it by having DNS get checked first.

Please see Lennart Poettering's comments at avahi.org

    http://avahi.org/wiki/AvahiAndUnicastDotLocal

and in Debian bug report #393711

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393711

about putting "dns" before "mdns4" in nsswitch.conf.

Quoting:

«[T]he line your package version adds has several
disadvantages, among them:

  * Slows down all mDNS lookups
  * Breaks mDNS lookups when the configured DNS server is not
    reachable (!)
  * Is a security hole, because local host info is leaked on unicast
    dns server and as such the internet
  * Is a security hole, because people on the internet can
    redirect local services to other hosts
  * Increases the burden on internet DNS servers needlessly. (This is
    a major problem which caused the creation of projects like AS112)
  * Breaks mDNS RR consistency because the unicast DNS zone .local is
    kind-of merged with the multicast DNS zone .local. However, the
    conflict protocol which makes sure that no two host names or
    service names conflict in the .local zone simply doesn't work
    against names from the .local unicast domain.»

where "the line your package version adds" he refers to is

    hosts: files mdns_minimal dns mdns

Ubuntu 14.04 is still affected.

Either the default nsswitch.conf has to be updated to use dns even when mdns fails or nss-mdns has to be patched to return NSS_STATUS_UNAVAIL instead of NSS_STATUS_NOTFOUND even for .local domains.

Re #43: the rest of the world (android, iphone, os x, ...) does fallback to dns when mdns fails though! Maybe that's something to consider.

Also most of the points mentioned there are simply not true when DNS is used only as a fallback for .local domain when mDNS fails.

Status changed to 'Confirmed' because the bug affects multiple users.

Apple, whose OS X Yosemite (10.10) will not even resolve DNS when internet is down ("private networks don't exist"), simply chose the wrong name for something that is basically only used by machines.

Their ".local" is not meant for manual use.

They could just as easily have called it ".mdns" or something -- OS X will by default not show it anyway I'm sure.

So they have claimed something they were not entitled to and their broken model of network computing is now the foundation of how to do things?

  * The local DNS server timeout issue is not really an issue; if you didn't want that you shouldn't have chosen .local for mdns.

  * .local leakage is no different from .home leakage and in this case can be prevented

  * redirecting local services would require upstream malicious .local to be configured in DNS servers but is directly at odds with the situation in which a _local_ .local DNS server is configured, so can also be solved by only allowing .local to get out if there IS a local .local DNS server

  * The only real argument that remains is name resolution; automatic changing of host names in cast of conflicts. RFC 6762 notes that

"Implementers MAY choose to look up such names concurrently via other
   mechanisms (e.g., Unicast DNS) and coalesce the results in some
   fashion. Implementers choosing to do this should be aware of the
   potential for user confusion when a given name can produce different
   results depending on external network conditions (such as, but not
   limited to, which name lookup mechanism responds faster)."

Lennart likes to scream about people not listening to the designers; but what does he do?

    The typical use case of a merged system is when DHCP provides DNS through supplied
    hostnames, there is no resolution in that sense, at least no standard one.

    The DHCP set would remain unchanged (and unresolved) while the mDNS set, oblivious
    to anything happening in unicast DNS, would produce different names where some of them
    would change, adding new ones to the total set. Those new names would only be resolvable
    through mDNS. Unless you were talking about a huge network (why would you use multicast
    in such a system?) the actual prevalence of such conflicts and confusion must be considered
    low.

    I think it can be argued that discovery is a much more important aspect of mDNS than
    resolution because most hardware devices pick MAC-based names and most operating systems
    also pick randomized names by default.

    Anything else reeks of configuration, and if you configure, you are not in zeroconf.

    So there aren't really any reasons that are deal-breaking, and those that exist are caused
    by mDNS' insistence to use for its automated system a human-meaningful name such as .local,
    which is a design flaw.

I guess I am wrong about the "upstream security hole" thing. But I don't know why you would use mDNS for serious security anyway.

mdns_minimal already causes a 4-second fallthrough (if AVAHI is disabled at least).

So Lennart is ranting and screaming only about the [NOTFOUND=return] line?

As if he decides what NSS does. His is a plugin. A plugin is a peer to other plugins; not one plugin is more important than the others;

the plugin is just that, the configuration is up to the end user (or the bigger system).

He acts as if /etc/nsswitch.conf now belongs to his package.

His PulseAudio also configures itself in the same way as authorative with ALSA. Same idea, repeats itself.

  "If PulseAudio module is loaded, set it to be the ALSA default device".

  What?

  What if some other module wanted to do the same?

So NSS is to Lennart just an annoyance, an archaic system that doesn't make him the most important person in the world and then he starts saying "fuck yous" to get his way.

He wanted his package to be orphaned and renamed, as if he holds a trademark to "mdns".

As if he holds a trademark to "libnss".

Nothing about that is "Lennart".

That's the least trade-markable name in the history of trademarkable names.

And then he starts ranting "You don't give a fuck about people and you think it's about you".

But everything is always about Lennart.

What Lennart wants.

What Lennart decides.

What Lennart says is best.

Quite remarkable that you can think "libnss-mdns" is somehow a trademarkable name.

This is fixed in Ubuntu 20.04 with nss-mdns 0.14 and later which does proper split horizon handling.