[Dnsmasq-discuss] Multicast dns

[Tom Fanning]

Hi all

Having just installed Ubuntu 7.04, I'm having issues resolving domain
names ending in .local (accessible through router-to-router VPN), for
example vault.edgebyte.local. The following packets are seen:

http://tomnrob.dyndns.org/misc/mdns-capture.log

That packet capture is triggered when doing a
wget http://vault.edgebyte.local

wget falls over with a name resolution error. Same with pings, tcp
connects etc.

I found a posting about an assumption somewhere that .local names are
"Zeroconf" names and should not be resolvable by any DNS servers.
http://linux.derkeiler.com/Newsgroups/linux.redhat/2006-01/msg00159.html

My dnsmasq resolves all my .local addresses just fine (by means of an
upstream server for those specific domains, over the VPN tunnel), and
all other client machines (different OSes) resolve these names
absolutely fine from dnsmasq.

I realise that it's not directly a dnsmasq thing, but it would be great
if dnsmasq were to support these Ubuntu clients which now seem to choose
to follow this (faulty?) assumption. I'm not sure, but I think this is a
retrograde step brought in with Ubuntu Feisty 7.04 - I don't remember
this coming up as an issue with previous versions.

Drop me a reply with any comments/feedback/requests by all means.

Regards
Tom

[Simon Kelley]

Post by Tom Fanning
Hi all
Having just installed Ubuntu 7.04, I'm having issues resolving domain
names ending in .local (accessible through router-to-router VPN), for
http://tomnrob.dyndns.org/misc/mdns-capture.log
That packet capture is triggered when doing a
wget http://vault.edgebyte.local
wget falls over with a name resolution error. Same with pings, tcp
connects etc.
I found a posting about an assumption somewhere that .local names are
"Zeroconf" names and should not be resolvable by any DNS servers.
http://linux.derkeiler.com/Newsgroups/linux.redhat/2006-01/msg00159.html
My dnsmasq resolves all my .local addresses just fine (by means of an
upstream server for those specific domains, over the VPN tunnel), and
all other client machines (different OSes) resolve these names
absolutely fine from dnsmasq.
I realise that it's not directly a dnsmasq thing, but it would be great
if dnsmasq were to support these Ubuntu clients which now seem to choose
to follow this (faulty?) assumption. I'm not sure, but I think this is a
retrograde step brought in with Ubuntu Feisty 7.04 - I don't remember
this coming up as an issue with previous versions.
Drop me a reply with any comments/feedback/requests by all means.

What behaviour is needed? If the problem can be solved by having the DNS
server return "No such domain" for anything that ends in .local, then
such behaviour is already available: adding

local=/local/

to /etc/dnsmasq.conf will do it.

Other special-case behaviour for a domain is easy to implement, but only
if we know what is needed.

Cheers,

Simon.

Post by Tom Fanning
Regards
Tom
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Tom Fanning]

<snip>

Post by Simon Kelley
What behaviour is needed? If the problem can be solved by having the
DNS server return "No such domain" for anything that ends in .local,
then such behaviour is already available: adding
local=/local/
to /etc/dnsmasq.conf will do it.
Other special-case behaviour for a domain is easy to implement, but
only if we know what is needed.

Hi Simon

No. I wanted to go the other way with this.

I was actually hoping dnsmasq could be extended to reply properly to these
multicast DNS lookups that Ubuntu seems to be making - dnsmasq here appears
to ignore them and the query just times out. (It may be that I've just not
configured something right but I couldn't spot anything obvious)

My thinking here is now that Ubuntu is making such inroads into desktop
Linux use that it would be nice to support its out-of-the-box behaviour.
(Yes I'm aware that Ubuntu (arguably) shouldn't make the assumption that
.local names should be looked up through multicast DNS, but I think it's
more likely that this will get fixed here than in Ubuntu.)

The packet trace I linked to is complete and shows a series of three
lookups.

This site has lots of details on multicast DNS
http://www.multicastdns.org/

Kind regards

Tom

[Simon Kelley]

Post by Tom Fanning
<snip>

Post by Simon Kelley
What behaviour is needed? If the problem can be solved by having the
DNS server return "No such domain" for anything that ends in .local,
then such behaviour is already available: adding
local=/local/
to /etc/dnsmasq.conf will do it.
Other special-case behaviour for a domain is easy to implement, but
only if we know what is needed.

Hi Simon
No. I wanted to go the other way with this.
I was actually hoping dnsmasq could be extended to reply properly to these
multicast DNS lookups that Ubuntu seems to be making - dnsmasq here appears
to ignore them and the query just times out. (It may be that I've just not
configured something right but I couldn't spot anything obvious)
My thinking here is now that Ubuntu is making such inroads into desktop
Linux use that it would be nice to support its out-of-the-box behaviour.
(Yes I'm aware that Ubuntu (arguably) shouldn't make the assumption that
.local names should be looked up through multicast DNS, but I think it's
more likely that this will get fixed here than in Ubuntu.)
The packet trace I linked to is complete and shows a series of three
lookups.
This site has lots of details on multicast DNS
http://www.multicastdns.org/

OK, my understanding (which might be wrong) is this:

Ubuntu have enabled mdns by default, which means that DNS queries for
the .local domain are being sent to the well-known multicast address
associated with mDNS, and port 5353. Since dnsmasq is not listening on
these ports, it never sees the queries.

Tom has been bitten because he is already using .local for private
domain names (Why didn't the mDNS people pick .mdns instead, this clash
seems rather easily predictable?)

The idea in mDNS is that there is not a "DNS server" everything on the
network listens to the multicasts, and when it sees a request for an
address in knows, it replies, otherwise it keeps quiet.

Thus to find "myprinter.local" in the DNS, you don't need to configure
DNS at all, you just plug in a printer which knows its name is
"myprinter", when is see an mDNS request for "myprinter.local" it replies.


It would be possible to make dnsmasq listen for muticast DNS queries
quite easily, but the question, then, is what should it respond to and
what should it forward? Doing the same as for "ordinary" DNS and
attempting at answer every query completely defeats the distributed
nature of mDNS, but it would solve Tom's immediate problem.

On the other hand, just editing /etc/nsswitch.conf to remove the mDNS
resolver would do the same thing.

Hmm, difficult.


Cheers,

Simon

[Tom Fanning]

<snip>

Post by Simon Kelley
On the other hand, just editing /etc/nsswitch.conf to remove the mDNS
resolver would do the same thing.

... the vital remaining part of the puzzle that I couldn't find. Thank you.

Post by Simon Kelley
Hmm, difficult.

Point taken, I'll go away now. It was very late last night when I posted.
Sorry for the noise.

[Simon Kelley]

Post by Tom Fanning
<snip>

Post by Simon Kelley
On the other hand, just editing /etc/nsswitch.conf to remove the mDNS
resolver would do the same thing.

... the vital remaining part of the puzzle that I couldn't find. Thank you.

Post by Simon Kelley
Hmm, difficult.

Point taken, I'll go away now. It was very late last night when I posted.
Sorry for the noise.

Not at all, It's a reasonable suggestion that dnsmasq should be
configurable to listen for mDNS and reply to everything: Even with the
nsswitch.conf fix, that has to be fixed on every new Ubuntu Feisty
install, a dnsmasq configuration tweak would do it for a whole network
and if mDNS was not otherwise in use, nothing is lost.

OTOH, against doing this is that it breaks "real mDNS" so it's a bug to
fix another bug. Also it's possibly bloat for dnsmasq and of minor real
world use for most people. A judgement call, like most possible
enhancements.

Cheers,

Simon.

Post by Tom Fanning
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Tom Fanning]

<snip>

Post by Simon Kelley
Not at all, It's a reasonable suggestion that dnsmasq should be
configurable to listen for mDNS and reply to everything: Even with the
nsswitch.conf fix, that has to be fixed on every new Ubuntu Feisty
install, a dnsmasq configuration tweak would do it for a whole network
and if mDNS was not otherwise in use, nothing is lost.
OTOH, against doing this is that it breaks "real mDNS" so it's a bug to
fix another bug. Also it's possibly bloat for dnsmasq and of minor real
world use for most people. A judgement call, like most possible
enhancements.

Well I guess it's up to you, Simon. I can certainly help with testing at
this end. (Obviously!) Code-wise, I'm not hot on unmanaged code, so not much
use to you here.

Tom

[Simon Kelley]

Post by Tom Fanning
<snip>

Post by Simon Kelley
Not at all, It's a reasonable suggestion that dnsmasq should be
configurable to listen for mDNS and reply to everything: Even with the
nsswitch.conf fix, that has to be fixed on every new Ubuntu Feisty
install, a dnsmasq configuration tweak would do it for a whole network
and if mDNS was not otherwise in use, nothing is lost.
OTOH, against doing this is that it breaks "real mDNS" so it's a bug to
fix another bug. Also it's possibly bloat for dnsmasq and of minor real
world use for most people. A judgement call, like most possible
enhancements.

Well I guess it's up to you, Simon. I can certainly help with testing at
this end. (Obviously!) Code-wise, I'm not hot on unmanaged code, so not much
use to you here.

I think that the following might be useful, and probably RFC-compliant.

1) Add a flag --multicast, which makes dnsmasq listen for multicast DNS
requests: these are treated completely as normal, _except_ that queries
for the .local domain are ignored.

2) Add a second flag --local-ok which removes the _except_ behaviour from 2)

Just setting --multicast makes an RFC-compliant network which will work
with clients which do multicast for ordinary DNS and allow the
distributed-query system to work to answer .local queries.

setting --local-ok will stop mDNS from working, but it will allow
networks to still work which have used .local as the private domain,
even in the presence of Ubuntu Feisty-like clients which talk mDNS and
use multicast by default for .local queries. That should solve the sort
of problems Jan was seeing.


I'm not sure if this should go in 2.39 or not: I'll hack some code, and
see how disruptive it is, before deciding that.

Cheers,

Simon.

[Simon Kelley]

Post by Tom Fanning
<snip>

Post by Simon Kelley
Not at all, It's a reasonable suggestion that dnsmasq should be
configurable to listen for mDNS and reply to everything: Even with the
nsswitch.conf fix, that has to be fixed on every new Ubuntu Feisty
install, a dnsmasq configuration tweak would do it for a whole network
and if mDNS was not otherwise in use, nothing is lost.
OTOH, against doing this is that it breaks "real mDNS" so it's a bug to
fix another bug. Also it's possibly bloat for dnsmasq and of minor real
world use for most people. A judgement call, like most possible
enhancements.

I did some experimental hacking last night, and it looks like adding
mDNS support is a non-starter. Despite being billed as "DNS just
multicast" mDNS is in fact subtly different.

I made dnsmasq listen for and reply to multicast queries, and had it
reply to .local queries multicast by Avahi on an Ubuntu Feisty system.
The replies were rejected by Avahi, and on further reading it turns out
that mDNS replies must not include the "question" section which is
included in normal DNS replies. The presence of this section was enough
to spook Avahi.

The way dnsmasq is implemented makes it almost impossible to reliably
generate replies without a question section, so the whole plan is broken.

Sorry: editing nsswitch.conf or avoiding .local are the best I can offer.

There's a great quote in the draft standard:

Note also that the special treatment of names ending in ".local." has
been implemented in Macintosh computers since the days of Mac OS 9,
and continues today in Mac OS X. There are also implementations for
Linux and other platforms [dotlocal]. Operators setting up private
internal networks ("intranets") are advised that their lives may be
easier if they avoid using the suffix ".local." in names in their
private internal DNS server. Alternative possibilities include:

.intranet
.internal
.private
.corp
.home
.lan

Cheers,

Simon.

[Jan 'RedBully' Seiffert]

Post by Simon Kelley

Post by Tom Fanning
<snip>

Post by Simon Kelley
On the other hand, just editing /etc/nsswitch.conf to remove the mDNS
resolver would do the same thing.

... the vital remaining part of the puzzle that I couldn't find. Thank you.

Post by Simon Kelley
Hmm, difficult.

Point taken, I'll go away now. It was very late last night when I posted.
Sorry for the noise.

Not at all, It's a reasonable suggestion that dnsmasq should be
configurable to listen for mDNS and reply to everything: Even with the
nsswitch.conf fix, that has to be fixed on every new Ubuntu Feisty
install,

It's not only Ubunty...
More than half a year ago my brother visited me. I also had the TLD
.local . He plugged his laptop in, dnsmasq served him "his" dhcp entry
and *poof* his network was dead. Or no, he was sending his DNS-Queries
via multicast.
What happened? Before he came to me, he updated his Debian testing to
the latest versions and got mDNS/zeroconf/avahy behind his back.

So he deinstalled that avahi-stuff, and *plop* network worked again :).

Since then i switched my TLD to .lan. (Was a PITA. Services not running
anymore because you configured them to connect to foo.bar.local, the IP
would have been more stable...)

On Gentoo there was also a time, when they installed mDNS for you by
default (with glibc), now it is an extra package, you have to install
manually...

Post by Simon Kelley
a dnsmasq configuration tweak would do it for a whole network
and if mDNS was not otherwise in use, nothing is lost.

My problem was, which really made me mad, that suddenly ALL DNS queries
seemed to go over mDNS, not only those local zeroconf foo.
But i had no "for outer World DNS"-mDNS-server on the multicast address,
even with dnsmasq, the little swiss army knife (and i don't wanted to
blow up my router setup with adding a mDNS server).

Post by Simon Kelley
OTOH, against doing this is that it breaks "real mDNS" so it's a bug to
fix another bug.

But could be an interresting feature:
If my memorie serves me right, there are special request types in the
sense of "give me the network default printer" or "who answers DNS
queries here" (service discovery) and at least the last should be
answered by dnsmasq (or registering on avahi? how does this deamon
interact with this?). Thats how these zeroconf networks (ip 169....) are
suposed to work.
With the possiblity to add maunal entries into the dnsamsq conf one
could for example redirect "Got Printer?"-queries to his cups (until
cups grows this feature itself)

Post by Simon Kelley
Also it's possibly bloat for dnsmasq

Yup, hmmm.
Basically it's just another socket, hmmm, but some "special parsing", if
i'm correct.

But with a nice ./configure-option?

Post by Simon Kelley
and of minor real
world use for most people.

Mac-users?
IMHO it's an emerging thing, all those network-appliances grow this
feature (Net-Printer, NAS, Media-streaming boxes, VoIP-Phones?? (again,
service discovery)), and "Out-Of-The-Box"-Distros seem to enable it (and
again, service discovery, so Joe Average gets a nice "local Printers in
range" tab in his printing dialog).
Oh, and i think in IPv6-land there are some basic services (DHCP?)
changed to multicast, so maybe dnsmasq needs a multicast socket anyway.

Post by Simon Kelley
A judgement call, like most possible
enhancements.

I personly wouldn't need it (nor have any testcase, since i notoriously
disable auto-foobar), and would label it as "nice to have when you need
it" thing.
So, personal POV: hacking away on some mDNS code ASAP, no (some more
thoughts/research first).
Some mDNS awareness (<joke> Simon reads some RFC's and enlightens us :D
</joke>) esp. not how does the packet look like, but what could be done
with it and has to be done about it, in FAQ, Manual, HOWTOs (code?),
maybe yes.

Post by Simon Kelley
Cheers,
Simon.

Greetings
Jan