Date: Sat, 26 Aug 2006 09:56:23 -0400 From: Pat Lashley <patl+freebsd@volant.org> To: Fredrik Lindberg <fli+freebsd-net@shapeshifter.se> Cc: freebsd-net@freebsd.org, Doug Barton <dougb@FreeBSD.org> Subject: Re: Zeroconfig and Multicast DNS Message-ID: <3E29077FA25E6B14361D2C3B@2EEC3F7CCB6B8A97580F632A>
next in thread | raw e-mail | index | archive | help
> > What makes you think that there even IS a unicast DNS server for the
> > (sub)domain in question?
>
> I would expect anyone using a real domain (as in using a real TLD,
> and a name registered at a domain registrar) to have a unicast DNS
> server.
But those servers are typically outside the firewall (or in a DMZ). Their
purpose is to advertise the publicly visible hosts. The LAN(s) behind the
firewall typically use a completely different DNS server. And often one or more
subdomains that are not normally exposed to the public.
Also, as is pointed out in draft-cheshire-dnsext-dns-sd.txt:
Note that the DNS-SD service does NOT have to be provided by the same
DNS server hardware that is currently providing an organization's
conventional host name lookup service (the service we traditionally
think of when we say "DNS"). By delegating the "_tcp" subdomain, all
the workload related to DNS-SD can be offloaded to a different
machine. This flexibility, to handle DNS-SD on the main DNS server,
or not, at the network administrator's discretion, is one of the
things that makes DNS-SD so compelling.
(I'm not sure why they don't mention the _udp subdomain here.)
And from draft-cheshire-dnsext-multicastdns.txt:
Multicast DNS Domains are not delegated from their parent domain via
use of NS records. There are no NS records anywhere in Multicast DNS
Domains. Instead, all Multicast DNS Domains are delegated to the IP
addresses 224.0.0.251 and FF02::FB by virtue of the individual
organizations producing DNS client software deciding how to handle
those names. It would be extremely valuable for the industry if this
special handling were ratified and recorded by IANA, since otherwise
the special handling provided by each vendor is likely to be
inconsistent.
The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The
IPv6 name server for a Multicast DNS Domain is FF02::FB. These are
multicast addresses; therefore they identify not a single host but a
collection of hosts, working in cooperation to maintain some
reasonable facsimile of a competently managed DNS zone. Conceptually
a Multicast DNS Domain is a single DNS zone, however its server is
implemented as a distributed process running on a cluster of loosely
cooperating CPUs rather than as a single process running on a single
CPU.
Given that, in a situation where there is a unicast DNS server(*), the standard
nsswitch order should be 'files dns mdns', with the DNS server containing
records to delegate .local, .254.169.in-addr.arpa, and ._{tcp,udp}.$(local
domain) to the mDNS IP address(es).
We may want to add those delegations to our default BIND configuration files.
Possibly commented-out with a 'Uncomment these if you want to use mDNS or
mDNS-SD on your LAN' comment.
(*)Note that here I'm ignoring the situation where the primary DNS server is
under some outside administrative control where it is not possible to add those
records. Which is a far too common situation for small business owners.
> Otherwise they have no "right" to use that name, even if
> it is only in a local network.
WRONG! Once you register a name, you have the right to use it; you are NOT
required to provide ANY publicly available DNS records for it. Of course, if
you don't, it will only be useful internally; but there are situations where
that's desirable. (You also have the right to not use it at all; in which case
you are just preventing anyone else from using it.)
> >> I don't say that we shouldn't support it, but it should not be on by
> >> default. And it will actually boil down to what the mdns nss module
> >> allows.
> >
> > I agree that it should not be on by default. But there should be one
> > simple knob in rc.conf to cause service advertisements to be published
> > for both .local and the host domain. Any thing more complex would
> > require editing mdns.conf.
>
> Publishing announcements is one thing, what the nss mdns module allows
> a host to resolve is what will limit its initial usage.
It should allow clients to resolve -any- service-related records that are
available as defined in the protocol. BUT please note that service browsers
and clients will normally only -search- in one default domain or in a list of
domains provided by {b,db,r,dr,lb}._dns-sd._udp services. And that clients
will normally include domain information in the list of choices presented to
the user.
I agree that there should be a separate knob for whether to to try mDNS for
name resolution for names outside the .local domain. And I think that the knob
should have at least four states: ".local only", ".local and this host's
domain", ".local and .{_tcp,_udp}.*" and "anything".
There are inherent security issues in using mDNS at all. But in many cases,
particularly the home user with a LAN, LAN parties, etc. the convenience far
outweighs the potential hazards.
In most cases, I expect zeroconf hosts to be satisfied with residing only in
the .local domain; which greatly reduces the ability of a malicious host on the
LAN to manipulate DNS responses for external entities. BUT note that in a true
zero-configuration setup, the host must use DNS-SD to discover the unicast DNS
server that's handling global queries.
-Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E29077FA25E6B14361D2C3B>