Date: Sat, 26 Aug 2006 13:07:02 -0400 From: Pat Lashley <patl@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: <A960A8D896826C3BD3494535@garrett.local> In-Reply-To: <44F068FD.1080408@shapeshifter.se> References: <3E29077FA25E6B14361D2C3B@2EEC3F7CCB6B8A97580F632A> <44F068FD.1080408@shapeshifter.se>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A960A8D896826C3BD3494535>