Re: Zeroconfig and Multicast DNS

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
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Zeroconfig and Multicast DNS
    ... Service Discovery via DNS does -NOT depend on mDNS; it may be implemented using traditional unicast DNS. ... and the config file should be able to override the defaults. ... My claim is that when the host does its initial 'I want to use this address' broadcast on interface 1, it should also -receive- that packet on interface 2 IFF the two are on the same link. ...
    (freebsd-net)
  • Re: Zeroconfig and Multicast DNS
    ... But I also believe that programs should Do The Right Thing even when the config file is missing. ... And in this case The Right Thing is to advertise the hostname; since that will be the desired result in 99+% of the cases. ... A multi-homed host with two interfaces configured in 169.254/16 will ... And that's one of the things that we'll have to fix if we want LLA and mDNS to work correctly. ...
    (freebsd-net)
  • Re: Zeroconfig and Multicast DNS
    ... And in this case The Right Thing is to advertise the hostname; since that will be the desired result in 99+% of the cases. ... A multi-homed host with two interfaces configured in 169.254/16 will ... And that's one of the things that we'll have to fix if we want LLA and mDNS to work correctly. ... The problem with your proposal is that if the config file is missing, there is no host advertisement at all. ...
    (freebsd-net)
  • Re: Zeroconfig and Multicast DNS
    ... > behind the firewall typically use a completely different DNS server. ... That does not provide any impediment at all if they wish to use mDNS for service discovery. ... It does not prohibit delegation of other domains. ...
    (freebsd-net)
  • Re: Zeroconfig and Multicast DNS
    ... Let us for a second pretend that SD doesn't exist but mDNS does, ... As I mentioned in an earlier posting, I would really like to see it support multiple TLDs for a single host. ... 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. ... Command-line flags set via /etc/rc.conf can indicate interfaces that are to be used, whether or not to automatically produce an HINFO record, and whether to advertise all or none of the /etc/hosts records. ...
    (freebsd-net)