[avahi] Multicast DNS and the Unicast .local Domain

[Carsten]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Aldrin,

Aldrin Martoq wrote:
> On Fri, Jun 19, 2009 at 1:19 PM, Carsten Strotmann<carsten at strotmann.de> wrote:
>> I stumbled over the topic I describe below when I updated an Ubuntu
>> System from Version 8.04 tro 9.04. Avahi refused to start because I have
>> a unicast ".local" domain in my network(s).
>> This behavior is documented as recommended for distributions in the
>> Avahi Wiki at
>> http://avahi.org/wiki/AvahiAndUnicastDotLocal
>> I think this is a not well thought out decision. It would be a good
>> decision if it would detect a "used" unicast ".local" domain, but in my
>> case, the ".local" domain is one of many "pseudo" domains that are
>> configured as "empty" DNS zones on all resolving DNS Servers on the
>> network edge (border to the Internet), to prevent any "pseudo TLD" like
>> ".local" to be leaked into the Internet and hitting the Root DNS Server
>> System.
> 
> I don´t think that your solution is the best for the presented
> problem; everyone can´t afford a DNS Server and make the internet
> better. If we are really using .local as a standard for LAN
> communications, then we should fix the resolv libraries instead.

I'm not proposing that everyone should run a DNS Server to make the
Internet better. Not everyone operates an DNS Server, however (almost)
everyone is using an resolving DNS Server (home users use their ISPs DNS
resolvers, enterprise users use the DNS resolvers), and the operators
might have a ".local" unicast DNS Zone for the purpose to stop ".local"
requests to bubble up to the Internet Root DNS Server.

Fixing the resolv library will not help, because the issue mostly
happens with operating systems that have no MDNS and will also never
updated (like old OS/2, Win NT, older Linux, embedded OS etc). The
average user cannot tell if "example.local" is a valid DNS name in his
environment or not, because the average user does not know if MDNS is
enabled in the network he/she is working in. The User learns while
working in an network with MDNS enabled, that he/she can address
machines with a ".local" name and then will use this learned pattern
even in non-MDNS networks (resulting in bogus DNS requests going to the
root DNS).

> About avahi behavior, I guess a configurable option like
> --skip-dns-check should fix your [unwanted by developers for good
> reasons] setup. If such an option doesn´t exist, you have the code and
> maybe send a patch.

My personal setup was use as an example, stopping pseudo TLD Domains at
the resolver level is kind of recommended practice. The code to fix is
the code published on the Avahi Wiki, it's not something to be fixed in
the Avahi Codebase.

Basically the snipped below should be enhanced to distinguish empty
".local" zones  (good) from used zones (not good).

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

I will try to get feedback on this matter from a DNS related community
and come back with an suggestion on a possible enhancement to the init
script code presented in the wiki.

Best regards

Carsten Strotmann

P.S.: Is anyone from the Avahi Project at LinuxTag in Berlin next week?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko8pa0ACgkQiDbv+TR5q6I3xACbB7vACjt1RFFxSUrrs8h4YLrF
M88AoITUtC1vuS2rOPSDRRgCUwRKqEAA
=nATq
-----END PGP SIGNATURE-----