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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
