Zeroconfig and Multicast DNS

[Fredrik Lindberg]

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