Pat Lashley wrote:
Let us for a second pretend that SD doesn't exist but mDNS does, mDNS
without SD is still a very valuable protocol.
No argument there.
The specs. says that each host should claim a unique host and also
advertise a HINFO record, but this in my opinion a policy decision
and should be left to the end user.
The HINFO record should be a policy decision; but I'm much less certain
about the utility of not advertising a hostname.
Well, then we can agree upon disagreeing :)
I guess it's just my nature, I really don't want to restrict end users
ability to do stuff when there is no TECHNICAL limitation of doing so.
It's the classical policy versus mechanism scenario, imho policy should
be left to the user, of course provided with sane default values that
can be used out of the box.
A user might want to advertise 0, 1, 2 or many different unique records,
and the main purpose of the mdns.conf file would be to provide a easy
way to do so (without writing scripts that calls a cmd line utility).
For example, a line in the mdns.conf might look like this
$(hostname).local. A $(ifaddr)
Might look cryptic but it just means announce a A record using my
current hostname, append .local. and point it to whatever ip number
that happens to be configured on my interface.
Things get a bit more complex for multi-homed hosts; especially if they
are connected to more than one local link using IPv4 Link Local
Addressing...
Well, I already have a proof-of-concept of this running a multi-homed
responder and hosts on both ends resolve the addresses correct.
A multi-homed host with two interfaces configured in 169.254/16 will
have other major problems beyond mDNS as the host would threat
both interfaces as being on the same net even if they are
physically separated.
As I mentioned in an earlier posting, I would really like to see it
support multiple TLDs for a single host. In particular, if I'm using
example.com, then mumble.local and mumble.example.com should both
resolve via mDNS to the IP address of host mumble. Similarly, services
advertised by host mumble should automatically be listed in both domains.
Well, $(hostname).example.com. A $(ifaddr) :)
You would have to configure the NSS module to allow .com queries too.
If we're going to require an entry in a config file to get address
advertisement; then we need to ensure that the default config file Does
The Right Thing for the 99.99% case. (Otherwise, it isn't really
zeroconf, is it?)
Of course, default configuration should always be such that it requires
none or minimal work by the end user to get it running with values
that suite most people. However I feel power-users shouldn't be
restricted to do what ever they want, even how crazy other people
might think it is.
The default of my proof-of-concept stuff had this as default, which
means advertise a A and a PTR record for my hostname on all interfaces
using the address of the interface. (should be expanded with AAAA and
$(ifaddr6) in a real application).
interface * {
$(hostname).local. A $(ifaddr)
$(ifaddr) PTR $(hostname).local.
}
I think that it would be best if the most common cases worked correctly
without a config file at all. Command-line flags set via /etc/rc.conf
can indicate interfaces that are (not) to be used, whether or not to
automatically produce an HINFO record, and whether to advertise all
(except 127/8) or none of the /etc/hosts records. Doing this via rc.conf
makes it much easier to set up common options at install time via
sysinstall.
I really don't understand how it should read /etc/hosts, users might
have aliases in there that doesn't belong to them which would make
the responder announce records that doesn't belong to them.
The config file, if provided would specify additional hosts that don't
advertise themselves; and additional services provided by hosts that
don't advertise. It would also be used to specify a non-default HINFO
record format. (I'm thinking a string with various % substitutions
available.) Note that whether or not to produce an HINFO record at all
would still be handled by the command line.
Now we can get back to the reality where SD does exists.
In addition to this mdns.conf we have the client API, using this
client API a command line tool should be built that can insert
and remove records (even those records configured using mdns.conf).
Lets call this tool mdns for now (the name it doesn't matter, and
isn't really the point).
Programs announcing a service using SD would preferably call the
mdns tool in their rc.d scripts to add/remove SD records.
No, programs announcing a service using SD would preferably make a call
to the mdns-sd library. The use of the mdnstool in the rc.d script
should probably be viewed as the preferred method during the transition
period between bundling the basic mDNS support and converting the
service providers to being directly mDNS-aware.
Yeah, on a second though I agree with that.
> Right. Except for the additional bit of knowledge about the .local
domain.
>
I've been thinking about this too. The NSS module would require a file
similar to resolv.conf. It would contain a "white list" of allowed
domains to resolv (local., 168.192.in-addr.arpa., 10.in-addr.arpa etc).
But it could also contain a "search" directive so that if it receives
a query for a name without a white listed TLD it appends for
example ".local." to the name.
It might be dangerous though as it could try to query for
www.google.com.local., a solution to this would be do "blacklist"
existing TLDs when a search is done or only to do a search if there are
no dots in the name, I think the latter solution is the best
Anyway, it would allow users to leave out the .local part when
communicating
which I think would be a nice feature.
Is that really necessary? I haven't looked at how the resolver handles
the domain search list and how that relates to NSS calls; but couldn't
it be handled by implicitly adding 'local' to the list?
I was under the impression that resolv.conf was explicitly used by the
dns nss module, but I could be wrong. The mDNS will requires its own
nss module that should be independent from the other DNS.
Fredrik Lindberg
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
