Date: Sat, 26 Aug 2006 17:30:05 +0200 From: Fredrik Lindberg <fli+freebsd-net@shapeshifter.se> To: Pat Lashley <patl+freebsd@volant.org> Cc: freebsd-net@freebsd.org, Doug Barton <dougb@FreeBSD.org> Subject: Re: Zeroconfig and Multicast DNS Message-ID: <44F068FD.1080408@shapeshifter.se> In-Reply-To: <3E29077FA25E6B14361D2C3B@2EEC3F7CCB6B8A97580F632A> References: <3E29077FA25E6B14361D2C3B@2EEC3F7CCB6B8A97580F632A>
next in thread | previous in thread | raw e-mail | index | archive | help
Pat Lashley wrote:
>>
>> 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).
>
> 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.
>
> 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.
> 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.
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.
>
>
>> 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.
>
>> >> 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".
>
>
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.
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.
Fredrik Lindberg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44F068FD.1080408>