Date: Sat, 26 Aug 2006 19:45:17 +0200 From: Fredrik Lindberg <fli+freebsd-net@shapeshifter.se> To: Pat Lashley <patl@volant.org> Cc: freebsd-net@freebsd.org, Doug Barton <dougb@FreeBSD.org> Subject: Re: Zeroconfig and Multicast DNS Message-ID: <44F088AD.8000408@shapeshifter.se> In-Reply-To: <A960A8D896826C3BD3494535@garrett.local> References: <3E29077FA25E6B14361D2C3B@2EEC3F7CCB6B8A97580F632A> <44F068FD.1080408@shapeshifter.se> <A960A8D896826C3BD3494535@garrett.local>
next in thread | previous in thread | raw e-mail | index | archive | help
Pat Lashley wrote:
>>
>> 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.
Of course not, that has never been my intention.
>
>> > 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.
Ok, this would work for a multicast-aware service discovery browser that
would understand to switch to mDNS when it receives a NS record pointing
to 224.0.0.251/FF02::FB.
I suppose we could ship an example configuration for this.
>
>> 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.)
>
To clarify my statements a bit. The *only* place that should restrict
which domains that are resolvable is the mDNS NSS module, neither
the mDNS client API nor a DNS-SD library should impose any form
of restrictions on which types of domains to be resolvable.
Clients of these APIs should cope with potential hazards (just as the
mdns nss module is a client of the mdns api, and quite sensitive to
malicious behavior as it handles gethostbyname etc).
Fredrik Lindberg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44F088AD.8000408>