PM Lashley wrote:
> 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.
No, I don't think that there's any good reason to restrict mDNS service
discovery to .local; when you're using some other domain on the LAN, you
still want to easily do the dynamic service advertisement, even if the A
records are being handled by a traditional unicast DNS server and static
IP allocation.
Well, this would cause an authority conflict if it's on by default as
anyone on the local network would be able to announce SD records in
a domain they do not have authority over.
Do do SD updates to an DNS zone you would need to enable dynamic updates
on that name server, just as the Service Discovery specifications says.
Some quotes from draft-cheshire-dnsext-dns-sd.txt
The <domain> part of the name may be "local" (meaning "perform the
query using link-local multicast) or it may be learned through some
other mechanism, such as the DHCP "Domain" option (option code 15)
[RFC 2132] or the DHCP "Domain Search" option (option code 119)
[RFC 3397].
Service discovery requires a central aggregation server.
DNS already has one: It's called a DNS server.
Service discovery requires a service registration protocol.
DNS already has one: It's called DNS Dynamic Update.
Service discovery requires a query protocol
DNS already has one: It's called DNS.
Service discovery requires security mechanisms.
DNS already has security mechanisms: DNSSEC.
Service discovery requires a multicast mode for ad-hoc networks.
Zeroconf environments already require a multicast-based DNS-like
name lookup protocol for mapping host names to addresses, so it
makes sense to let one multicast-based protocol do both jobs.
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.
> 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.
We can define the basic conditional block and some simple conditional
tests for things like 'is interface X currently supporting IPv4?' or 'is
interface X a point-to-point link?'; and possibly a 'for each <list of
interface globs>'. And then add condition tests as necessary/desirable
later.
Yeah sure, but it's all about creating a logical and easy syntax...
Fredrik Lindberg
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
