Pat Lashley wrote:
First, I'd like to correct something that slipped by earlier. Service
Discovery via DNS does -NOT depend on mDNS; it may be implemented using
traditional unicast DNS. (And to a pure client, there should be no
detectable difference.)
Yes this is correct (if I've implied otherwise it was a mistake).
See below.
No, it shouldn't depend on whether the file is present or not. The
defaults should be reasonable; and the config file should be able to
override the defaults. You should -never- have to put anything in the
config file to obtain behavior that would be chosen automatically if the
config file were absent.
It should be possible to explicitly specify behavior that matches the
default; just for those of us who don't always trust the defaults not to
change. But it shouldn't be necessary just because a config file exists.
An empty, or comment-only config file should produce the same behavior
as a missing one. A config file with one default behavior explicitly
specified should also produce the same behavior as a missing config
file, or one that explicitly specifies all of the options as matching
the defaults.
Please, provide a example of how such configuration file would look.
Ok, I might agree to have, for each interface, a hostname.local
(A and AAAA, depending on whats available on the interface) and
an associated PTR record as the default if we can agree on a
easy way to disable this behavior without making the mdns.conf
too complex.
One example would be to have something such as "override default=yes",
in both a global and interface local scope.
The nsswitch.conf should IHMO be :files dns mdns,
and the mdns nss module should ship with a default to only allow
queries to
.local
.168.254.in-addr.arpa
I think you meant .254.168.in-addr.arpa here.
Actually .254.169.in-addr.arpa :)
.168.192.in-addr.arpa
.16.172.in-addr.arpa-31.172.in-addr.arpa
.10.in-addr.arpa
I put mdns before dns for performance reasons. If you restrict the
queries as defined above, there's no real advantage to doing the dns
query first.
Yes, agreed (if restricted).
I am reluctantly coming to agree that for security reasons we need to
restrict the domains for A record lookups via mDNS; and PTR records in
the in-addr.arpa domain.
I think the reasons are very clear, in a mobile environment you might
hook up your laptop to various "untrusted" networks.
But service discovery will often have a non-.local domain; so I think we
need to allow PTR/SVC/TXT lookups in any domain. (Or possibly anything
outside in-addr.arpa. Given the existence of the .local domain, I don't
see any utility in advertising a service in an in-addr.arpa domain. I'm
sure somebody will post an example if I'm just being short-sighted here...)
As you said above SD is not only for mDNS. SD over mDNS should be in the
.local domain. A SD browser should go through the normal nss environment
to do its searching and not directly consult the mDNS API for all of its
queries. Under normal circumstances queries for SD records in existing
TLDs should be looked up just as any other DNS record.
Not entirely. It is also a syntactic/semantic issue in the config file
design. There's a choice between whether there's an implicit "ignore
this if the necessary protocol isn't available" or some sort of
conditional block to explicitly say 'if condition X, then apply the
following set of options'. The later is potentially more powerful.
Yes, I agree. A user might want to advertise a record only if a
certain condition is met, however I think we should be careful
not to create a too complex syntax.
The mdns.conf must be simple enough so that an average user is
able to edit it without too much knowledge.
We really do not want to turn in into something similar to named.conf,
more /etc/hosts on steroids.
Fredrik Lindberg
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
