Some ISPs have .local domain which disables avahi-daemon

Bug #327362 reported by Daniel Holm
434
This bug affects 88 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Fix Released
Undecided
Unassigned
avahi (Ubuntu)
Invalid
Medium
Unassigned
Declined for Jaunty by Steve Langasek
Declined for Lucid by Timo Jyrinki
Karmic
Won't Fix
Medium
Unassigned
nss-mdns (Ubuntu)
Fix Released
Undecided
Unassigned
Declined for Jaunty by Steve Langasek
Declined for Lucid by Timo Jyrinki
Karmic
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: avahi-daemon

After a fresh install of Jaunty Alpha 3 avahi did not work and as a result of that - not Bonjour in Pidgin, and some network discovery stuff.

I have been looking for a solution, but still - after the fresh install, when I used Intrepid, it worked fine.

During boot I see some error with avahi-daemon (do quick to actually read), and I think that it is the same thing as I get when trying to startup avahi-damon:
daniel@daniel-laptop:~$ sudo /etc/init.d/avahi-daemon start
 * Starting Avahi mDNS/DNS-SD Daemon avahi-daemon
 * avahi-daemon disabled because there is a unicast .local domain

And after login there is a notify regarding the same matter.

This same things is confirmed on my finances netbook.
We used the Alternative Jaunty CD for install (due to that the install crashed when the installing user already existed in /home, on the desktop CD)

Awesome work - keep it up! ;)

Daniel Holm (danielholm)
Changed in avahi:
status: New → Confirmed
Revision history for this message
jocko (jomnal00) wrote :

I have this problem as well. It prevents me from using programs that are dependent on avahi-daemon (such as padevchooser).
I have a fully updated jaunty. This problem did not happen in intrepid or any earlier ubuntu versions, and I haven't changed anything in my network (I connect through a wireless router which in turn is connected to an adsl modem).
Where is this ".local" domain set up and how can I change it?

I've found a temporary fix which needs to run after every boot:
[code]sudo rm /var/run/avahi-daemon/disabled-for-unicast-local
sudo /etc/init.d/avahi-daemon restart[/code]

Revision history for this message
Daniel Holm (danielholm) wrote :

I will try that. I use:
sudo avahi-daemon -d
sudo /etc/init.d/avahi-daemon start

to get my to work. But Bonjour still doesnt work tough.

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

I think the problem is caused by Internet Service Providers. Some ISP:s DNS servers provide some return value for "local", which in turns lets avahi/Ubuntu think there is actually such domain in use. When I changed to using OpenDNS instead in my router, the problem went away.

One can test if the ISP is problematic by running the command: host -t SOA local.

It should return "Host local. not found: 3(NXDOMAIN)", but if it returns something like "local has SOA record" then it's ISP:s fault, at least to some extent.

But I am not 100% sure if something changed in this regard between Ubuntu 8.10 and Ubuntu 9.04. Can someone else say anything about that?

Also, correct me if I'm wrong.

Revision history for this message
Thomas Novin (thomasn80) wrote :

$ host -t SOA local
local has SOA record localhost. backbone.telia.net. 1 3600 900 3600000 3600

Hmm. I'd say avahi's way of detecting this is pretty bad. Is it perhaps possible to add a local addition of the .local-domain and reject lookups? I have my own DNS specified on this machine but the DNS server is configured with forwarders to my local ISPs name servers.

Revision history for this message
Trent Lloyd (lathiat) wrote : Re: [Bug 327362] Re: avahi-daemon disabled because there is a unicast .local domain

Hi Thomas,

On 19/02/2009, at 2:25 AM, ThomasNovin wrote:

> $ host -t SOA local
> local has SOA record localhost. backbone.telia.net. 1 3600 900
> 3600000 3600
>
> Hmm. I'd say avahi's way of detecting this is pretty bad. Is it
> perhaps
> possible to add a local addition of the .local-domain and reject
> lookups? I have my own DNS specified on this machine but the DNS
> server
> is configured with forwarders to my local ISPs name servers.

Yes, so the problem here is your ISP has this local. record - that is
*really* broken, FYI :) - Most actual uses of .local are local LANs,
often MS domains.

There isn't really any better way to 'detect' this.. you could disable
the functionality on your box .. but if the user was actually using
those .local domains and they turn Avahi on then they will break - and
we can't really guess whether they are using them or not.

Best Regards,
Trent
[Avahi Developer]

Revision history for this message
Daniel Holm (danielholm) wrote : Re: avahi-daemon disabled because there is a unicast .local domain

Thanks for the heads up.

But why did it worked in Intrepid, but not in Jaunty?

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Indeed. I now remembered I have one 8.04 LTS machine. There, on the same problematic ISP and ISP:s name servers, /var/run/avahi-daemon/disabled-for-unicast-local does _not_ get generated, avahi _does_ start and works problem-free eg. for accessing my DAAP share.

So it's a regression from 8.04 and 8.10, and I think something should be done about, whether it's technically wise for ISP:s to have configurations like that or not. Some major ISP:s seem to have the problem, including the biggest one in the Nordic countries (TeliaSonera).

Revision history for this message
Daniel Holm (danielholm) wrote :

Now when I run 'sudo avahi-damon && sudo /etc/inint.d/avahi-daemon start' all the previous Avahi-services works fine. Even Bonjour works again flawlessly. So why is that and why does not the same effect when I just startup Ubuntu?

Revision history for this message
Trent Lloyd (lathiat) wrote :

If you run "sudo avahi-daemon" that starts Avahi manually, bypassing the init script which is what does the check before starting it.

Revision history for this message
Daniel Holm (danielholm) wrote :

Alrigth. So the sudo /ec/init.d/avavi-daemon start, is not at all necessary?

Revision history for this message
Trent Lloyd (lathiat) wrote :

No .. if you want to start Avahi manually and daemonize it

sudo avahi-daemon -D

Regards,
Trent

Revision history for this message
Daniel Holm (danielholm) wrote :

Forgot to add that parameter, but I did already use it. But thanks.

Revision history for this message
Pauli (paniemin) wrote :

As side note:
I just upgraded to hydrid jaunty/intrepid from intrepid. I did upgrade kernel, xserver and mesa which included some libs. After upgrade avahi isn't discoverable in my lan.

Also my ISP doesn't have local in dns server so problem seems like related to some lib that avahi is using or then kernel upgrade caused this problem.

I will try to see if I can find the real cause for problem.

Revision history for this message
Pauli (paniemin) wrote :

Editing /etc/default/avahi-daemon fixed it for me.

AVAHI_DAEMON_DETECT_LOCAL=0 makes it discover all 8.10 machines in my lan (and others machines are now able to see the upgraded one).

Possible cause for problem might be D-link nat router which has built in dns proxy. I don't realy know but that is my best guess.

Revision history for this message
Daniel Holm (danielholm) wrote :

So shortly said, Pauli. If you edit that file as posted, you wont have the issue with the unicast notity av Avahi does work with .local?

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

So does anyone have an idea how to fix this regression for jaunty somehow semi-properly? This problem essentially disables avahi for millions of potential (novice) users (who don't know how to disable the check or eg. use OpenDNS instead their ISP:s).

Also anyone affected upgrading from 8.04 or 8.10 will lose avahi.

tags: added: regression-potential
summary: - avahi-daemon disabled because there is a unicast .local domain
+ [jaunty] regression with selected ISP:s: avahi-daemon disabled because
+ there is a unicast .local domain
Revision history for this message
Daniel Holm (danielholm) wrote : Re: [Bug 327362] Re: avahi-daemon disabled because there is a unicast .local domain

I just run 'sudo avahi-daemon' from a terminal after login and everything
works like a charm again. But it really should work anyway.

Revision history for this message
Daniel Holm (danielholm) wrote : Re: [jaunty] regression with selected ISP:s: avahi-daemon disabled because there is a unicast .local domain

I just run 'sudo avahi-daemon' from a terminal after login and everything works like a charm again. But it really should work anyway.

Steve Beattie (sbeattie)
Changed in avahi (Ubuntu):
assignee: nobody → canonical-desktop-team
importance: Undecided → Medium
Changed in avahi (Ubuntu):
assignee: canonical-desktop-team → nobody
tags: added: ct-rev
Revision history for this message
Toni Ruottu (toni-ruottu) wrote :

Communicating the problem to the ISPs is a great idea, but I already did that a few years ago and the problem is still present with my ISP. The Internet bill is attached to my rent so I cannot change my ISP without moving to another apartment. Also, I often use wireless access with my laptop and I would not want to communicate the problem to every network admin whose network I happen to bypass.

Revision history for this message
ba5e (willieham) wrote :

Is this anything to do with Sweden? I am having this issue too. I remember having a similar issue at the launch of 8.04 or 8.10 but can't remember much more.

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

 * Starting Avahi mDNS/DNS-SD Daemon avahi-daemon
 * avahi-daemon disabled because there is a unicast .local domain

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

This can be considered for a release note. It seems to affect TeliaSonera (the dominant ISP in Finland and Sweden) users, but possibly also other ISP:s. The bug is actually ISP:s fault, but nevertheless the Avahi detection code was somehow changed from hardy/intrepid where the problem does not exist if with these problematic ISP:s.

Revision history for this message
Daniel Holm (danielholm) wrote :

You might be on something there, Timo. But the same issue concerns the ISP "Bredbandsbolaget" (Telenor).

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Ok, then it's multiple ISP:s, which is not surprising of course.

The simplest and best workaround for now is to edit /etc/default/avahi-daemon, change AVAHI_DAEMON_DETECT_LOCAL to 0 and reboot. (alternative is to change to eg. OpenDNS from ISP:s DNS servers, and/or advocating the issue to ISP:s service desk).

Revision history for this message
Steve Langasek (vorlon) wrote :

Documented at <https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes#Avahi will not start if a .local domain is present>:

The avahi-daemon package, which implements the mDNS "zeroconf" standard, includes a check to avoid running when a conflicting .local DNS domain is present. It is reported that some ISPs advertise such a .local domain on their networks, which will leave Ubuntu 9.04 hosts unable to see names advertised on the local network (327362).

To force the use of mDNS on a network configured this way, users can run the command:

sudo sed -i -e'/AVAHI_DAEMON_DETECT_LOCAL/s/1/0/' /etc/default/avahi-daemon

Changed in ubuntu-release-notes:
status: New → Fix Released
Steve Beattie (sbeattie)
tags: added: jaunty regression-release
removed: regression-potential
Revision history for this message
NicoleDiana (nicole-nicolediana) wrote :

I had this error as well after upgrading this morning. While my laptop was at work today, it kept disconnecting from the network. Upon arriving home, I changed my DNS servers over to those of OpenDNS and haven't had a problem since. I even deleted and recreated my two wireless connections. Without OpenDNS, I will get the error every time. With OpenDNS, I do not get it.

summary: - [jaunty] regression with selected ISP:s: avahi-daemon disabled because
- there is a unicast .local domain
+ Some ISPs have .local domain which disables avahi-daemon
Revision history for this message
Robert Ancell (robert-ancell) wrote :

This bug is closely related to bug 80900.

splattx_x (fmanno)
Changed in avahi (Ubuntu Karmic):
assignee: nobody → splattx_x (fmanno)
Steve Langasek (vorlon)
Changed in avahi (Ubuntu Karmic):
assignee: splattx_x (fmanno) → nobody
Revision history for this message
robbanl (robert-lindberg1978) wrote :

This is still an issue for me with 9.10 Beta, i think it's very irritating to have the same error message present itself on each boot without helping out with a solution. These are the kind of problems that can never exist for the normal user, they wouldn't have a clue of what to do.
.
I tried to use the solution with editing the avahi-daemon in /etc/default but it isn't there in 9.10 beta, please deal with this bug before the release, cause it's effecting a lot of people (in Sweden anyway).

Revision history for this message
Magnus (koma-lysator) wrote :

True. This happens for at least the two largest ISPs in Sweden: Telia and Bredbandsbolaget.

If I were to contact them, what could I say to make them understand the problem?

Revision history for this message
Chris_Z (chris-ustation) wrote :

@robbanl

Just create this file with gedit (gksudo gedit /etc/default/avahi-daemon) and put inside:

   AVAHI_DAEMON_DETECT_LOCAL=0

and after that start the service manually from the terminal:

  sudo service avahi-daemon start

Revision history for this message
Steve Langasek (vorlon) wrote :

My understanding is that the released version of avahi in Ubuntu 9.10 no longer behaves this way; marking this bug as fixed.

Changed in avahi (Ubuntu):
status: Confirmed → Fix Released
Changed in avahi (Ubuntu Karmic):
status: Confirmed → Fix Released
Revision history for this message
aamukahvi (aamukahvi) wrote :

I am sorry to inform you that this is still a problem In Karmic 9.10, fresh install.

I get the notification every time the desktop is loaded.

Changed in avahi (Ubuntu Karmic):
status: Fix Released → Confirmed
Revision history for this message
Stuart Bishop (stub) wrote :

Confirmed Ubuntu 9.10 (Karmic).

The largest ISP in Thailand (True Internet) started redirecting failed DNS lookups recently to search/ads pages including .local. They also control most of the wifi hotspots in the country.

Changed in avahi (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
GlenMH (glenmh) wrote :

The fix may have been released but it still hasn't solved the problem. Both my Karmic machines are still giving the .local error.

I have 2 choices: the first is use OpenDNS settings in my router and then I don't have access to my networked drives via Samba. OR
Don't use OpenDNS, have a domain name in my router (which does not seem to make a difference), access my networked drives and then not be able to use my HP MFD which is also on the network.

Neither of these is ideal!

Any suggestions on how I can sort this out to get both bits working at the same time?

Thanks!

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Just tested on live-CD that it's not fixed on karmic. On karmic, /etc/default/avahi-daemon isn't simply created anymore, making it actually more difficult to workaround this problem. But the /var/run/avahi-daemon/disabled-for-unicast-local is still being created and Avahi is disabled.

As usual, adding the avahi-daemon file with AVAHI_DAEMON_DETECT_LOCAL=0 workarounds the problem.

Revision history for this message
GlenMH (glenmh) wrote :

Thanks Timo - your solution works perfectly, and is persistant after a full reboot.

A virtual beer for you!

Revision history for this message
altima (timashkov) wrote :

I have this bug in Ubuntu 9.10.

I believe it is somehow related to network-manager, and this is why:

I installed Ubuntu Minimal with gdm, but instead of installing network-manager, I installed wicd.
and avahi worked great!
but then I needed to set up broadband connection, and since wicd doesn't have the option, I replaced it with network-manager.

and at this very point avahi stopped working with the message about .local.

getting back to wicd did not solve the problem. so the thing must be in some config files that are being altered during a network-manager installation.

Revision history for this message
Mekk (marcin-kasperski) wrote :

Looks like the solution to this bug somehow affected me. Freshly installed Ubuntu 9.10, DHCP network connection initialized by networkmanager, and my firm uses .local domain names in their true DNS server.

Until I stop avahi-daemon, in-organization DNS names fail to resolve.

Iarms76 (iamrms76)
affects: avahi (Ubuntu Karmic) → firefox (Ubuntu Karmic)
Steve Langasek (vorlon)
affects: firefox (Ubuntu) → avahi (Ubuntu)
Revision history for this message
Psy[H[] (vovik-wfa) wrote :

I confirm what Mekk said: with running avahi-daemon I can not access local resources of my office by dns names. If i disable avahi-daemon, network works fine.
Ubuntu 9.10 with current upgrades, NM from network-manager/trunk ppa...

Revision history for this message
Rykel from Singapore (rykel98) wrote :

I am running Ubuntu Lucid on M1 Home Broadband in Singapore.

I have this ".local" bug error message everytime I reconnect after a disconnection.

If I have a disconnection, it takes a reboot of both my Speedtouch modem and Linksys WRT54GL router to reconnect my PC to the internet.

Revision history for this message
fferreres (fferreres) wrote :

I have this avahi problem as well. I live in Mexico and do not use any .local domain (I don't even connect to other computers, just to the router). Nothing seems to decidedly solve this, and everyone that I have showcased Ubuntu to (at least 50 people as I use it with my TV as set top box) have clearly seen how only rebooting seems to solve it.

I am utterly tired of Avahi disabling my wifi link...makes Ubutntu look so amateurish by not have a solution, not even a commitment to really look into this.

Revision history for this message
Toni Ruottu (toni-ruottu) wrote :

You might have a different problem. Rebooting never fixed this issue for me, and it never broke my wifi.

Revision history for this message
Erik Quaeghebeur (equaeghe) wrote :

Just as an extra confirmation: I got bitten by this bug today (Kubuntu 10.04 amd64).

Revision history for this message
Toni Ruottu (toni-ruottu) wrote :

I've seen it on Ubuntu 10.10 too.

Revision history for this message
Daniel Loiacono (loiacono-neunet) wrote :

I use Ubuntu Lucid 10.04 64bits and this problem is present. Removing Network-Manager and Installing Wicd resolve this issue for me. My question is: where it is the difference between these two managers?

Revision history for this message
andrewpmk (andrewpmk) wrote :

This problem still exists in Ubuntu 10.04. I cannot connect to the Toronto Public Library free wifi because it redirects to the webpage "spyders.local", which displays the terms and conditions for using the free wifi service. This works fine on Windows.

Revision history for this message
Andreas Ringlstetter (ext3h) wrote :

I think we are talking about two different bugs: In some networks there is actually a .local-domain defined, but there are also a lot of false positives!

In /usr/lib/avahi/avahi-daemon-check-dns.sh line 58 is faulty:
    if echo "$OUT" | egrep -vq 'has no|not found'; then

The "host"-command might return additional lines which contain debug-messages with a trailing ";; " but those are not recognized by this script and therby result in the shutdown of avahi-daemon.

Line 58 must be changed into the following to get rid of the false positives:
    if echo "$OUT" | egrep -vq 'has no|not found'; then

The suggested solution with adding AVAHI_DAEMON_DETECT_LOCAL=0 will disable the faulty check, but it does not solve the bug itself, even worse it will cause avahi to enabled in networks where the local-domain may be used by important services!

Revision history for this message
Andreas Ringlstetter (ext3h) wrote :

Sorry, forgott to add the corrected line in the previous post:
    if echo "$OUT" | egrep -vq 'has no|not found|^;; '; then

Revision history for this message
Lex Ross (lross) wrote :

The top three Russian ISP's (Golden Telecom, Beeline and Corbina) are configured as shown below

$ host -t SOA local.
local has SOA record dns1.corbina.net. hostmaster.corbina.net. 1268639101 3600 300 604800 3600

Does this indicate that ISP indeed uses local domain or is there a problem with avahi detection method? And how is DNS supposed to work when I have the following line in my /etc/nsswitch.conf by default

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

Shouldn't it put dns right after files instead, as suggested in bug #80900 ?

This is on Ubuntu 10.10 x64

Revision history for this message
Stone age (stein-somers) wrote :

For my ISP "LC_ALL=C host -t soa local." does return "Host local. not found: 3(NXDOMAIN)". But still I get the avahi complaint.

Figured out that before my ADSL router (a simple home device, Thomson speedtouch 536) established connection to the ISP, the query returns "local has address 198.18.1.2". This address is reserved for testing in RFC 2544. Perhaps the router developers would argue it's the avahi script that should recognize it's not a legal IP address. In any case, whichever way the avahi script tests, the DNS server radically changes a little later. I guess the whole network service should wait until the router is really ready.

This problem is basically due to the much improved boot time. Faster isn't always better...

Setting AVAHI_DAEMON_DETECT_LOCAL=0 in /etc/default/avahi-daemon removes the message, but in my case this file did not yet exist. Ubuntu 10.10 x64.

Revision history for this message
Marcus Carlson (0-launchpad-mejlamej-nu) wrote :

For information, this is how Mac OS X "handles" the situation;

From: http://support.apple.com/kb/TA20999?viewlocale=en_US
"Note: If you have set up a private DNS server that resolves names in the .local domain, computers using Mac OS X 10.2 will not use the DNS server to resolve these names. This may result in unexpected failures to connect to hostnames defined by your server. You should use a different domain, such as .home, .office, or .lan for DNS on private networks."

They just ignore the .local domain in DNS - should we do the same? Or just start it anyway and have avahi take precedence over dns in nsswitch.conf?

Revision history for this message
Roman Bolshakov (roolebo) wrote : Re: [Bug 327362] Re: Some ISPs have .local domain which disables avahi-daemon

Marcus, I think OS X way of handling the situation is better. There are
some reasons for that. I called some months ago to North-West
Telecom(one of the biggest internet providers in Saint Petersburg).
Customer support engineer said that they could remove the DNS zone only
for artificial persons. So the company protects own profit preventing
use of Active Directory for contracts with natural persons, because
price for artificial persons is higher usually. I said him(or her, I
didn't remember who it was) that the zone hindered for Ubuntu and Mac OS
users, but him(her) had nothing to say me. And the second advantage for
OS X way is current situation with torrent trackers. There are lots of
providers that introduced retracker.local domain with incorrect DNS
server settings. They set up whole .local zone instead of only
retracker.local. So the providers disturb peoples who even doesn't use
torrents.

Expelled (sir-expelled)
affects: ubuntu-release-notes → hedera
affects: hedera → ubuntu-release-notes
Revision history for this message
ceg (ceg) wrote :

I've read that ubuntu is not checking for existing .local domains in the release notes, however, then why does /etc/default/avahi-daemon and avahi-daemon.default in the package still say:

AVAHI_DAEMON_DETECT_LOCAL=1

Have you hard-patched the package and made it unconfigurabe instead of adapting the default setting in the configuration file?

Revision history for this message
Hobson Lane (hobs) wrote :

Same problem for free WiFi run by the city of New Orleans at New Orleans international airport:
> host -t SOA local
local has SOA record rxg.local. hostmaster.local. 1302159607 3600 1800 604800 3600

Revision history for this message
Hobson Lane (hobs) wrote :

Still a problem for 10.10 unless you do the OpenDNS or /etc/default/avahi work-arounds

Revision history for this message
Bryce Nesbitt (bryce2) wrote :

Same problem here on Ubuntu 11.04 x64, using a small local ISP:

bnesbitt@ubuntu:~$ host -t SOA local
local has SOA record . . 0 0 0 0 0

Rolf Leggewie (r0lf)
Changed in avahi (Ubuntu Karmic):
status: Confirmed → Won't Fix
Revision history for this message
Timokl (timokl) wrote :

Same problem with Thai ISP on Ubuntu 11.10 x64

host -t SOA local.
local has SOA record . . 1 3600 1200 604800 10800

Revision history for this message
Psy[H[] (vovik-wfa) wrote :

For the last couple of years my system works in office LAN with .local domain using this line in nsswitch.conf:

hosts: files mdns4_minimal dns mdns4 wins

Both hostname.local (avahi) and hostname.domain.local (domain) machine hostnames are being resolved normally. I didn't experience any troubles with this setup.

Revision history for this message
Simon Josefsson (simon-josefsson) wrote :

Same problem here on Ubuntu 11.10 and 12.04 beta. ISP is Bredbandsbolaget in Sweden, their DNS servers are 195.54.122.200 and 195.54.122.204.

local has SOA record localhost. root.localhost. 10 604800 86400 2419200 604800

My workaround was to install my own local resolver and use that instead of my ISPs DNS servers.

Revision history for this message
Thomas Hood (jdthood) wrote :

Comment #50 described how Mac OS X 10.2 did it. Here is how Mac OS X v10.6 does it (http://support.apple.com/kb/HT3473).

"As long as your network's DNS server is properly configured, you do not have to make any changes on your client Mac.

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

Revision history for this message
Thomas Hood (jdthood) wrote :

The original issue was, roughly, that Avahi daemon disables itself when an ISP has a .local TLD. I take it that this is not a bug but a feature. So perhaps this report should be marked wontfix?

A desire was also expressed that the Avahi daemon handle this situation better, as described for example in my previous comment (#60). I have filed a new bug report (bug #1167352) requesting that the improved behavior be implemented.

Another alleged issue is that the current test for .local has false positives: Exterminans claimed this in comment #46. However, his suggested alternative for line 58 looks the same to me as the original line 58 so I don't know what he means. Exterminans: Can you please open a *new* bug report with a fuller explanation of this false-positive bug?

The current test for .local also suffers from false negatives. That is bug #80900.

Revision history for this message
Narcis Garcia (narcisgarcia) wrote :

Problem found with Ubuntu 12.04 using DNS from France Telecom.
In the target network I manage a BIND9 DNS server and ISC DHCP server, and I suppose I cannot intercept the .local domains with a local zone (because I should be returning valid values instead of NXDOMAIN).

papukaija (papukaija)
tags: added: saucy
removed: jaunty
Revision history for this message
Pauli (4-launchpad-u) wrote :

This is a response I got from my ISP. I think it's relevant.

"According to the RFC 6762 (chapter 22, IANA
considerations) the top level domain .local
should be handled as being Special-Use Domain
Names, which the RFC 6761 states "the caching
DNS servers SHOULD generate immediate (positive
or negative) responses for all queries".

Basicly, one should not query any .local. names.
But as many users do this, ISPs like us must
protect root name servers from these bogus queries.

We recommend not using the avahi-daemon since
it is causing problems."

Rafael (valromer)
Changed in avahi (Ubuntu):
status: Confirmed → Invalid
Stuart Bishop (stub)
Changed in avahi (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Jason Heeris (detly) wrote :

This is *still* a problem on 16.04.1 LTS. This message in syslog:

Dec 5 14:12:11 tali avahi: Avahi detected that your currently configured local DNS server serves
Dec 5 14:12:11 tali avahi: a domain .local. This is inherently incompatible with Avahi and thus
Dec 5 14:12:11 tali avahi: Avahi disabled itself. If you want to use Avahi in this network, please
Dec 5 14:12:11 tali avahi: contact your administrator and convince him to use a different DNS domain,
Dec 5 14:12:11 tali avahi: since .local should be used exclusively for Zeroconf technology.
Dec 5 14:12:11 tali avahi: For more information, see http://avahi.org/wiki/AvahiAndUnicastDotLocal

There is no .local domain:

~ • host -t SOA local
;; Warning: Message parser reports malformed message packet.
local.Home has no SOA record
~ • host -t SOA local.
;; Warning: Message parser reports malformed message packet.
local has no SOA record

(Some posts I found do the lookup with a trailing dot, others omit it, so I did both.)

Revision history for this message
Mekk (marcin-kasperski) wrote :

As I found this bug accidentally after years, just small remark:

a) The firm I work for keeps naming hosts in internal network «name».ourfirm.local. Those addresses are omnipresent (from network config to myriads of development/test/staging/whatever environments and config files), so advice to abandon them is unlikely to be considered. Ah, and we started our naming convention in 1997 or so. Zeroconf was born in 2002 on Mac, appeared on Linuxes around 2007-2010, and was RFCed in 2013 :-P

b) Still, this simply means that our „linux installation checklist” contains request to edit /etc/nsswitch.conf and remove
     mdns4_minimal [NOTFOUND=return]

Having said that, I still have no clue why avahi couldn't restrict itself to non-dns-resolvable addresses and leave those resolvable to DNS.

summary: - Some ISPs have .local domain which disables avahi-daemon
+ Order Ambien Online to Manage Irregular Sleep-Wake Rhythm Disorder
Colin Watson (cjwatson)
summary: - Order Ambien Online to Manage Irregular Sleep-Wake Rhythm Disorder
+ Some ISPs have .local domain which disables avahi-daemon
Revision history for this message
Trent Lloyd (lathiat) wrote :

For anyone looking at this in 2020, this is fixed in nss-mdns 0.14 which is in Ubuntu Focal 20.04 - it will now correctly pass through unicast .local lookups.

Revision history for this message
Magnus (koma-lysator) wrote :

That's great!

Revision history for this message
George (gmk57) wrote :

It seems not "fixed", but rather broken again in Ubuntu 20.04. My ISP DNS servers respond to all ".local" queries with "127.0.0.200", and mDNS just doesn't work in this case. Setting AVAHI_DAEMON_DETECT_LOCAL=0 does not help. This is regression from 18.04 where mDNS worked fine with default settings. And it's a pity, as mDNS is even more important after NetBIOS/SMB1 retirement in 20.04. Should I post details here or start a new issue?

Revision history for this message
George (gmk57) wrote :

After some more searching I found an explanation of this issue in Ubuntu 20.04 and the correct way to disable it: https://github.com/lathiat/nss-mdns#etcmdnsallow

Revision history for this message
George (gmk57) wrote :

Discussion on this new issue: https://github.com/lathiat/nss-mdns/issues/75

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

Trent: Wow, thank you! I switched away from that problematic ISP in 2017 but I'm glad it'd now function correctly by default.

George: You can file a new bug at https://bugs.launchpad.net/ubuntu/+source/nss-mdns unless there's already a bug about it, and link the github issue also there.

Changed in avahi (Ubuntu):
status: Confirmed → Invalid
Changed in nss-mdns (Ubuntu):
status: New → Fix Released
Changed in nss-mdns (Ubuntu Karmic):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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