Zeroconfig and Multicast DNS

[Pat Lashley]

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