Zeroconfig and Multicast DNS

[Pat Lashley]

> >> 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.)
>
> Yes, what's your point? SD records are plain DNS records and should
> be treated for exactly what they are. SD records in a unicast DNS
> environment would of course obey the rules of unicast DNS (including
> delegation to other servers).

My point is that it doesn't really matter whether anyone using a real domain 
already has a unicast DNS server. That does not provide any impediment at all 
if they wish to use mDNS for service discovery. Or even for link-local host 
lookups in their domain. (By either delegating their domain if the request was 
from within the LAN or creating a sub-domain that is always delegated.)

> > 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.
>
> Yes, I'm aware of this. And SD records in a multicast DNS environment
> should obey the rules of mDNS.
> The problem and thing we seem to disagree on is whether SD records
> outside the .local domain should be allowed to be resolved using
> mDNS by default.

I have no problem with having that off by default; as long as it can be turned 
on through the use of a single simple knob in rc.conf. (And that all of the 
rc.conf mDNS and LLA knobs be setable from the sysinstall menus.)

Just don't make it so that mDNS -only- works for .local and the link local 
in-addr.arpa domains.

> > 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).
> >
>
> How are you going to delegate between protocols?, while DNS and
> mDNS share the same PDU format, they should be treated as separate
> protocols.

The draft RFC indicates that those (sub)domains should be delegated. It does 
not prohibit delegation of other (sub)domains.

> > 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.
> >
>
> Do you mean a NS record pointing to the mDNS multicast address?, that
> doesn't seem right and will most likely confuse normal DNS clients
> and servers.

According to section 12, current implementations delegate .local, 
.254.169.in-addr.arpa, and FF02::/16 via special-case code. If you're going to 
do that, you may as well recognize explicit NS delegations to 224.0.0.251 and 
FF02::FB

> For example the server would not be multicast aware, and if it does
> get a reply to one of its queries it will originate from a different
> ip than to which the query was sent.

That might be an argument against mixing them for host lookup; but for service 
discovery, this is really only going to come up for clients that are using 
DNS-SD; and there's absolutely no reason why the dns-sd library shouldn't 
handle it properly.

I'm not familiar with the internals of the nsswitch and resolver code to 
propose any particular solution; but there's no reason why it can't be made to 
work cleanly. At worst case, you'd need a single nss module that could handle 
both DNS and mDNS.


> >> 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 was referring to the use of a domain with a real TLD that you didn't
> register at a domain registrar (and might belong to somebody else).
> Of course if you own a domain you can use it as you like.

You might be able to get by with using 'example.com'; but I wouldn't advise 
trying it.

In any case; I don't think that we need to worry about people trying to use 
unregistered domains. My point is that just because a domain is registered 
doesn't mean that there are any unicast DNS servers providing authoritative 
records for it. (Admittedly, it's probably a very good idea to at least have 
one; even if it only contains the SOA.)

People will have good reasons to want to use a domain other than .local with 
mDNS; and to use both that domain and .local at the same time. And quite 
possibly to use multiple domains in additional to .local. Let's not get in 
their way.


> We have been over this already and concluded that the mdns nss module
> should only allow (in its default state) queries to a few selected
> domains. SD records are just *plain* (m)dns records and will have to
> obey the same rules as any other records. _tcp.local. would be allow
> to be resolved via mDNS while _tcp.example.com would not.
> However, we *might* ship with a default configuration to the mdns nss
> module that would add {_tcp,_udp}.* to the set of domains that
> the nss module would allow to be resolved.

I think we need a third state where it only adds {_tcp,_udp}.$(domain) to the 
list.

> A Service Discovery browser application that utilize the mDNS API
> directly would of course be allowed to do any type of query.
> But queries going through the more generalized NSS environment should
> be restricted by default.

Hmmm.  Yes, I think that's a valid distinction.  The nss_dns module and the 
dns-sd library need not have the same set of default restrictions. 
Applications using the nsswitch only are unlikely to be using DNS-SD at all; 
and cannot be expected to be able to cope with delegation to a multicast 
address.  Those using libdns_sd are almost certain to be mDNS-aware; and the 
library can handle the choice of mDNS -vs- unicast for particular queries (and 
the potential recursion needed to resolve them.)

But that means that some of the configuration choices will need to be available 
to the dns-sd library.  (E.g., Whether to use mDNS only for .local, or also for 
_{tcp,udp}.DOMAIN, _{tcp,udp}.*, or for everything.)



-Pat