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

Bug #80900 reported by Rodney Lane on 2007-01-21
206
This bug affects 35 people
Affects Status Importance Assigned to Milestone
avahi (Debian)
New
Undecided
Unassigned
avahi (Ubuntu)
Medium
Unassigned
Nominated for Hardy by Nathaniel W. Turner
Nominated for Intrepid by Nathaniel W. Turner
Nominated for Karmic by Nathaniel W. Turner
nss-mdns (Ubuntu)
Undecided
Unassigned
Nominated for Hardy by Nathaniel W. Turner
Nominated for Intrepid by Nathaniel W. Turner
Nominated for Karmic by Nathaniel W. Turner

Bug Description

Install Kubuntu Feisty
Set the ip address to dhcp for eth0 (ethernet port)
make sure the host name and domain name are set
Hostname computer1
DomainName mydomain.local

allow DHCP to assign the IP address

Ensure the computer details are registered in DNS for mydomain.local...

computer names registered in DNS (FQDN)
computer1.mydomain.local
computer2.mydomain.local
computer3.mydomain.local

computer2 and computer3 are both running Kubuntu Dapper and are both using DHCP.

if I issue the following comands on computer2 or computer3, it works correctly:

ping computer2 (response received - ping good)
ping computer3 (response received - ping good)
ping computer2.mydomain.local (response received - ping good)
ping computer3.mydomain.local (response received - ping good)

if i issue the same commands from the feisty box (computer1), these are the results..

ping computer2 (response received - ping good)
ping computer3 (response received - ping good)
ping computer2.mydomain.local (unknown host)
ping computer3.mydomain.local (unknown host)

for some reason if you try to ping the fully qualified domain name on feisty, it cant resolve it, yet it can resolve it using both static IP Addressing and DHCP addressing on Dapper. (i set the IP to static as well for the test) Static and DHCP on Dapper works fine. Static and DHCP wont resolve fully qualified domain names on Feisty. (computer1, computer2 and computer 3 are all Kubuntu machines. DNS Server is a Windows 2003 Server (that will be changed a kubuntu server very soon though!)

It can resolve the host name only though, and will return the fully qualified domain name in the response.

cheers

Rod.

Brian Murray (brian-murray) wrote :

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

Rodney Lane (roddles) wrote :

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.

Jonathan Jesse (jjesse) wrote :

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

Rodney Lane (roddles) wrote :

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

Michael-250 (michael-250) wrote :

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.

Michael-250 (michael-250) wrote :

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.

Michael-250 (michael-250) wrote :

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

zigford (zigford) wrote :

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

zigford (zigford) wrote :

Rod, Michael,

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

Michael-250 (michael-250) wrote :

$ 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 ;)

zigford (zigford) wrote :

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.

Jonathan Jesse (jjesse) wrote :

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?

Changed in avahi:
status: New → Incomplete
zigford (zigford) wrote :

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

Daniel Harvey (daniel.harvey) wrote :

This problem still exists in Gutsy Tribe 5.

slyride (slyride) wrote :

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.

gsauthof (g-sauthoff) wrote :

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

Launchpad Janitor (janitor) wrote :

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

jshanks (jim-shanks) wrote :

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.

Dominic Maricic (dcmeagle) wrote :

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?

slyride (slyride) 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)"

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?

Changed in avahi:
importance: Undecided → Medium
status: Invalid → Confirmed

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

Loye Young (loyeyoung) wrote :

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

nitecoder (nitecoder) wrote :

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.

Alfas (alfonsasstonis) wrote :

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.

sefs (sefsinc) wrote :

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.

Changed in avahi (Ubuntu):
status: Confirmed → Triaged
Robert Ancell (robert-ancell) wrote :

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

scottuss (scottuss) wrote :

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!)

scottuss (scottuss) wrote :

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!)

scottuss (scottuss) wrote :

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

Doug (doug-m) wrote :

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

Noesis (tyler-bannister) wrote :

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.

enoch (a-drevet) wrote :

Bug still present in Lucid ...

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

dahias (wengahias) wrote :

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.

hyper_sonic (hyper-sonic) wrote :

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

Will Rouesnel (w-rouesnel) wrote :

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.

Jeremy Lincicome (w0jrl1) wrote :

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?

Thomas Hood (jdthood) wrote :

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

Thomas Hood (jdthood) on 2013-04-10
summary: - problems resolving fully qualified domain names in environments where
- .local is used as a TLD
+ Avahi daemon prevents resolution of FQDNs ending in ".local" due to
+ false negatives in the detection of ".local" networks
Thomas Hood (jdthood) wrote :

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

Changed in avahi (Debian):
status: Unknown → Fix Released
Thomas Hood (jdthood) on 2014-03-03
Changed in avahi (Debian):
importance: Unknown → Undecided
status: Fix Released → New
Lukas Vacek (lukas-vacek) wrote :

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.

Lukas Vacek (lukas-vacek) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in nss-mdns (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.