Subject: Re: New mDNS configuration language

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Sep 2001 11:30:33 -0700 (PDT)

> I can't see a need to revise rfc2937 in light of this text.

Possibly this is not needed. 
> 
> However, if it is going to work this way, I think that the
> interactions between mdns-enable and the search order need to be
> spelled out (i.e. Erik's table probably need to be included
> somewhere), even if people don't bother to implement rfc2937.
> 

Erik - do you have some proposed text to insert?

> > If an interface has been configured via any automatic configuration
> > mechanism which is able to supply DNS configuration information, then
> > multicast DNS MUST NOT be used on that interface unless it has been
> > explicitly enabled, whether via that mechanism or any other. This
> > ensures that upgraded hosts do not change their default behavior,
> > without requiring the source of the configuration information to be
> > simultaneously updated.  This implies that on the interface, the host
> > will neither listen on the DNS LINKLOCAL multicast address, nor will it
> > send queries to that address.
> 
> I've been a system admin for a number of years, I know where this text
> is coming from, and I sympathise, but ...
> 
>   - DHCP == death-to-mdns, which is a somewhat stronger statement than
>     was being advocated on the list which was DNS-disables-mdns.
>     Your text is is certainly more consistent.
> 
>   - mdns will be disabled in environments where NetBIOS naming and
>     Appletalk naming operate adequately today.
>     mDNS as a replacement for those protocols becomes still-born.
> 
>     One such environment is the home.  I don't know of any NAT/DHCP
>     boxes that allow the user to add the mdns-enable option, even if
>     they could.  So then I have to enable it on every host.
> 

Yes, that is undesirable. But it's hard to figure out how not to mess up
the home case while giving enterprise admins what they want. Any ideas??

>     It exasperates me that the people least able to cope have to do
>     configuration, so that the people best able to cope (managers of
>     networks) don't have to do anything.

Yup. Any way to give both of them what they want?

> > For a DNS server, automatic configuration mechanisms MUST NOT enable
> > multicast DNS on any interface.
> 
> Why not?  I don't recall seeing a reason why recursive mDNS lookups
> should be disallowed.  If you aren't a back-end resolver, don't
> resolve them.  Am I missing something here?
> 

I think that there was a concern about nodes becoming mDNS relays. 

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

---

From: Erik Guttman <[email-masked]>
Date: Fri, 21 Sep 2001 15:28:18 +0200 (MET DST)

Bernard, Aidan,

> Erik - do you have some proposed text to insert?

I suggest:

  The mDNS Enable Option specifies the order in which DNS and multicast
  DNS is done.  The mDNS Enable Option affects only DNS resolver behavior,
  that is, how DNS resolution is performed, whether multicast DNS is used.  

  The mDNS Enable Option does not determine whether or in which order DNS 
  itself is used for name resolution.  This can be specified, for example, 
  using the Name Service Search Option for DHCP [RFC2937].

> > > explicitly enabled, whether via that mechanism or any other. 

> the home case while giving enterprise admins what they want. Any ideas??

Personally, I would prefer the policy 'allow unless explicitely disabled.'
Many resisted this proposal (for example, the WG chairs.)

If mDNS were another protocol (not DNS at all), we wouldn't have this
problem.  Then it, like appletalk and netbios, could coexist with DNS.
But we are defining a new behavior for DNS.  

Or should we use a different port #?  That would dissolve this problem.

> Yup. Any way to give both of them what they want?

I believe that once we have experience with mDNS in real networks folks
will become more comfortable with it.  We will be able to relax the
'MUST NOT enable by mDNS by default' to a 'do whatever' policy.  That's
my hope.

Erik

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 21 Sep 2001 08:48:18 -0700 (PDT)

> Many resisted this proposal (for example, the WG chairs.)

There is somewhat of a double standard. NetBIOS & AppleTalk are "allow
unless explicitly disabled" once installed. So if mDNS were to be used
instead with the same policy, it would fit within the same admin
model. Yet, admins I talk to seem to hate the idea of clients changing
their configuration in an upgrade. I think that is because they're afraid
that they will then be stuck with *both* mDNS & NetBIOS/AppleTalk ;)

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 Sep 2001 13:28:20 -0700 (PDT)

How is this updated text?

3.1.  mDNS configuration

Multicast DNS usage can be configured manually or automatically.  On
interfaces where no manual or automatic configuration has been
performed, multicast DNS is enabled by default.

For IPv6, the stateless DNS discovery mechanisms described in [19] can
be used to discover whether multicast DNS is globally enabled or
disabled.

Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
configure multicast DNS on an interface.  The mDNS Enable Option,
described in [6], can be used to explicitly enable or disable use of
multicast DNS on an interface, as well as to specify the order in which
DNS and multicast DNS is used on that interface.

The mDNS Enable Option affects only DNS resolver behavior, that is, how
DNS resolution is performed, and whether multicast DNS is used.  The
mDNS Enable Option does not determine whether or in which order DNS
itself is used for name resolution.  This can be specified, for example,
using the Name Service Search Option for DHCP, RFC 2937 [3], which can
be used to globally determine where DNS is used within the name service
search order.

send queries to that address.  For a DNS server, automatic configuration
mechanisms MUST NOT  enable multicast DNS on any interface.