Zeroconfig and Multicast DNS

[PM Lashley]

> >> 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