>> 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 :)
Err, yes. I knew that... :-)
>> .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.
Just because they're clear doesn't mean that I'm happy with them. But then I'm
not happy with the need to lock my car or my front door either; but I recognize
the need to do so.
> 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.
> 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.
-Pat
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
