Subject: Re: Sense of the WG: mDNS configuration?

From: Erik Guttman <[email-masked]>
Date: Thu, 30 Aug 2001 12:27:46 +0200 (MET DST)

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Aug 2001 10:47:31 -0700 (PDT)

> We could just update RFC 2937 with the new info instead of creating

I think that a revision of RFC 2937 is required only because the 
numbers assigned to the name services correspond to DHCP option
codes, and a new IANA considerations section would need to be 
written to describe allocation of name service codes without
corresponding allocation of DHCP option codes. Otherwise, all
that would be needed would be an IANA allocation of the mDNS
name service codes. 

> static (non-default) configuration.  

The question was how to explicitly enable mDNS using IPv6 stateless
autoconfig. I would suggest that this be added as an objective of the 
DNS Discovery work ongoing in IPNG WG. 

> services and even how the option is interpreted by clients.

Yes, that's how I read RFC 2937. We would just need to allocate
name service codes for mDNS, and re-write the IANA considerations
section of it.

---

From: Robert Elz <[email-masked]>
Date: Fri, 31 Aug 2001 18:03:50 +0700

Date:        Thu, 30 Aug 2001 12:27:46 +0200 (MET DST)
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <[email-masked]>

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

That may very well be, but I thought its values were the identifiers
of other DHCP options, which have the information about the servers for
the various nameserver lookup types (DNS, netbios, ...)

I don't think there's any reason it would have to stay that way, but
it certainly looked to be how it was defined right now.

That is ...

     A DHCP server SHOULD return, in its preferred order, the 16-bit,
     network byte order (big-endian [4]) integer option code for the
     name services (the earlier in the list, the more preferred the name
     service).

     In the above diagram, ns1 and ns2 are 16-bit integers corresponding
     to two DHCP options which specify the IP addresses of two different
     types of name server.  The current list of name services and their
     DHCP option codes, taken from RFC 2132, includes

(etc).  And 0 means /etc/hosts ("local naming information") as a special
case.   If we took any other special case values, we'd have to make sure
that those particular identifiers never mapped into DHCP option numbers
that specify IP addresses of nameserver tyoes.  Somehow.

kre