Multicast DNS and the Unicast .local Domain

[Carsten Strotmann]

Hi,

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.

If you look at the DNS root server statistics (for example
l.root-servers.net ->
http://stats.l.root-servers.org/cgi-bin/dsc-grapher.pl?plot=qtype_vs_all_tld&server=L-root 
), you will see that ".local" is the most prominent pseudo Top Level
Domain that is hitting the root server system. There are other reasons
for this than just MDNS (like many Windows AD networks use ".local"
internally), however from my experience of doing DNS Audits in large
enterprise environments I know that some ".local" request are triggered
by the existence of ".local" MDNS in the network (URLs in Documents,
registry keys, configuration files etc etc).

To prevent unnecessary traffic to go to the root dns server system and
to prevent internal data to leak into the Internet, it would be actually
a good practice to have a ".local" unicast DNS domain on every resolving
DNS Server on the edge of an network with MDNS enabled internally. This
".local" Unicast domain would be an empty DNS zone.

To my knowledge there is no bulletproof way to detect whether the
".local" Unicast DNS zone is an empty one to prevent leakage, or a DNS
Zone "in use". One possible way could be to query for the SOA record and
disable MDNS (Avahi) only if the serial number is above a certain value
(as an empty ".local" zone will never change and might have an serial of
"0" or "1". Maybe we can spark a discussion on this topic here on the ML
and collect some ideas from the MDNS community.

Thanks for listening.

Carsten Strotmann

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

[Aldrin Martoq]

On Fri, Jun 19, 2009 at 1:19 PM, Carsten Strotmann<carsten@...> 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.


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.

--
Aldrin Martoq
http://aldrin.martoq.cl/
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

[Carsten Strotmann]

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

Hello Aldrin,

Aldrin Martoq wrote:

> On Fri, Jun 19, 2009 at 1:19 PM, Carsten Strotmann<carsten@...> 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-----
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

[Aldrin Martoq]

On Sat, Jun 20, 2009 at 5:02 AM, Carsten<carsten@...> wrote:

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

Hi Carsten, I guess I didn't explain myself very well. Take for example BCP 32:
http://www.rfc-editor.org/rfc/rfc2606.txt

It explicitly defines .test .example .localhost an other TLD's as invalid.

What I really want is that .local be defined as THE TLD for zeroconf,
and even further: as recommendation that any resolv library ignore the
domain.

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

Of course, there will be operating systems that are/will not be
updated; but that shouldn't limit us where we should go from now...

So "let's fix the resolvers" means "let's use .local exclusively for zeroconf".

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

Well, If that code is in the init script it doesn't change too much...
Instead of --skip-dns-check, you can try something like
"SKIP_DNS_CHECK=FALSE" as default in some /etc/defaults/avahi config
or similar; and propose that.


Saludos!

--
Aldrin Martoq
http://aldrin.martoq.cl/
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

[Lennart Poettering-8]

On Fri, 19.06.09 19:19, Carsten Strotmann (carsten@...) wrote:

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

This is simply broken. Your DNS server should not return a working SOA
for .local. If at all your DNS server should always return NXDOMAIN
for all .local names, overriding the internet .local SOA.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

[Carsten Strotmann]

Hello Lennart,

> This is simply broken. Your DNS server should not return a working SOA
> for .local. If at all your DNS server should always return NXDOMAIN
> for all .local names, overriding the internet .local SOA.

to my knowledge every DNS zone configured on a DNS Server will need at
least a valid SOA record and one valid NS record. And the DNS Server
will return this records. To my knowledge there is no way to configure a
local DNS server to return NXDOMAIN without the DNS Server going out to
the Internet ROOT DNS Server or withour running an own internal ROOT
Zone (which would be a solution, but overkill to the problem).

Recent BIND 9 implementations create certain "virtual" zones even if no
zone of that name is specified in the DNS Servers configuration. These
zones are for example the zones for the loopback and RFC 1918 private IP
Address reverse zones.

When queried for the SOA of these zones, BIND returns a valid SOA with a
serial number of "0".

It might be a solution to configure a ".local" unicast domain that is
created to stop ".local" queries to leak out to the Internet with a
serial of '0' and have the Avahi startup script to check against this
SOA serial value.

A ".local" unicast domain used locally in a LAN would have a serial
number != 0.

So if Avahi detects a ".local" unicast zone, it can check against the
serial number. If serial is "0", Ahavi can start without creating an
issue for the ".local" DNS lookups. If the serial is != 0, Avahi can
stop with an warning message to not conflict with a ".local" unicast
zone in use.

I also came across this post on CircleID about the issue:

Most Popular Invalid TLDs Should Be Reserved
http://www.circleid.com/posts/20090618_most_popular_invalid_tlds_should_be_reserved/

Given that TLDs will be free to register (for a certain amount of money)
in the future, maybe Apple or some other company with interest in
MulticastDNS will register and delegate the ".local" domain in the
Internet.

Best regards

Carsten Strotmann

On 30.06.2009 4:27 Uhr, Lennart Poettering wrote:

> On Fri, 19.06.09 19:19, Carsten Strotmann (carsten@...) wrote:
>
>> Hi,
>>
>> 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.
>
> This is simply broken. Your DNS server should not return a working SOA
> for .local. If at all your DNS server should always return NXDOMAIN
> for all .local names, overriding the internet .local SOA.
>
> Lennart
>

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

[Lennart Poettering-8]

On Mon, 13.07.09 10:14, Carsten Strotmann (private) (carsten@...) wrote:

> Recent BIND 9 implementations create certain "virtual" zones even if no
> zone of that name is specified in the DNS Servers configuration. These
> zones are for example the zones for the loopback and RFC 1918 private IP
> Address reverse zones.
>
> When queried for the SOA of these zones, BIND returns a valid SOA with a
> serial number of "0".
>
> It might be a solution to configure a ".local" unicast domain that is
> created to stop ".local" queries to leak out to the Internet with a
> serial of '0' and have the Avahi startup script to check against this
> SOA serial value.
>
> A ".local" unicast domain used locally in a LAN would have a serial
> number != 0.
>
> So if Avahi detects a ".local" unicast zone, it can check against the
> serial number. If serial is "0", Ahavi can start without creating an
> issue for the ".local" DNS lookups. If the serial is != 0, Avahi can
> stop with an warning message to not conflict with a ".local" unicast
> zone in use.

Sounds like a good idea. Could you please bring this to the attention
of the Debian/Ubuntu folks who ship that .local detection script? (To
my knowledge the other distros still don't, though they should)

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi