Re: Sense of the WG: mDNS configuration?

[Erik Guttman <[e-mail]>]

Bernard,

Thanks for bringing this topic to the list.  I've been on vacation -
sorry for the delay in responding.

On Aug 19, Bernard wrote:
> At IETF 51, we had a discussion relating to configuration of mDNS. A
> number of alternatives were discussed, including:
>
>      Domain Searchlist (draft-aboba-dhc-domsearch-05.txt)
>      mDNS enable (draft-guttman-dhc-mdns-enable-01.txt)
>      Name Service Searchlist (RFC 2937)
>
> Note that each of these alternative approaches allows for local
> configuration, in addition to control via a DHCP option.  

I hadn't considered RFC 2937.  The mDNS enable option could be
handled by assigning additional values for mDNS name resolution.
Values corresponding to different multicast scopes could be used,
exactly as described in draft-guttman-dhc-mdns-enable-01.txt.
We could just update RFC 2937 with the new info instead of creating
a new option.  

On Aug 19 Itojin wrote:
> i vote for domain searchlist.  there are environments without DHCP
> server, like IPv6 stateless address autoconf
> (RFC2937 and guttman-dhc-mbdns-enable both assumes that a DHCP
> server is there).

Thanks for your comment.  I understand your concern that we want
to allow mDNS in the case when there is no DHCP server.

If no DNS configuration exists - this is the zeroconf case.  There
has been no objection to using mDNS in this case.

Where there have been objections is the case where you have DNS
configuration and you *still* use mDNS.  In this case, the consensus
on the namedroppers mailing list was to explicitely enable mDNS
behavior (the default being NOT to use mDNS, as it is today :-).  
This can be done using a DHC option, or in the absence of DHC,
static (non-default) configuration.  

The problems with the domain search list are serious:

 1. It creates a binding between certain names and DNS transport
    protocols.  Here the proposal is 'local.arpa' means use IPv4
    LINKLOCAL multicast, sending with TTL=255, rejecting received
    if TTL != 255, hosts must be prepared to receive multiple replies,
    etc etc.  

    In the future, if we define use of multicast DNS for admin local
    scope for IPv4, IPv6 multicast scopes, with different rules than
    those in draft-ietf-dnsext-mdns, then we need NEW NAMES for the
    search list!

 2. The search list mechanism implies that names resolved by mdns
    are qualified by the search list name.  In draft-ietf-dnsext-mdns
    I can only resolve names ending in 'local.arpa'.  Why this 
    artificial restriction?

 3. Administration of name resolution behavior will be extremely 
    obscure if users and administrators must add special purpose 
    domain names to their search path to control DNS transport 
    behavior...

Coupling naming service behavior with special names is a bad idea.
It is a hack to avoid confronting the real problem:  We want DNS
to work as it does today in the common case, to use mDNS in the
unconfigured case.  Only *when local policy allows* should we
enable mDNS to coexist with DNS.  Let's use a mechanism which
allows this policy to be imposed on hosts, not a mechanism which
imposes contortions upon standardization, applications, implementors
and administrators.

On 19 Aug, Robert Elz wrote:
> Either of the latter two - the mdns-enable option is basically just
> a special case of 2937, in a sense - but as I read 2937, it would need
> another DNS option defined anyway, so its option number can be used in
> the 2937 option (there's no current dhcp option giving the addresses
> of the servers for mDNS .. for obvious reasons).

Robert, I think you misread 2937.  It gives only a list of 2 byte
values corresponding to name services to try (in order), not 
addresses.  2937 is silent about how one gets addresses for name
services and even how the option is interpreted by clients.

---

My vote is to extend the Name Service Searchlist (RFC 2937) with
new values for mDNS.

Erik



to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.