Subject: RE: summary/conclusion of discussion on mdns-00

From: "Nicolae, Dan" <[email-masked]>
Date: Thu, 24 May 2001 14:59:02 -0400

> From: Robert Elz [mailto:[email-masked]]
>| There may be operational reasons, in some cases, to disable mDNS.  I want 
>| to distinguish this mode from other modes - such as a host being configured
>| to use certain DNS servers or being configured to use a particular set of
>| domains in its search list. 
>
> Sure, I'd prefer that too.  I actually believe that a new DHCP option is
> the right way to go, rather than trying to overload an existing one with a
> new meaning.  The "magic address" proposal in the last message was just
> intended to show a different way that an existing option could be
> overloaded, which I think would work better.  I don't think that is the
> right solution.
>
> But I think that option should enable mDNS (as should most probably not
> getting any DNS "server" list from DHCP at all - that's essentially
> returning the net to "no DNS configured" state).  Without the option, and
> assuming that the DNS is configured, I'd leave mDNS off.

I don't think that the "magic address" idea is that bad. It doesn't have to
be "magic" though. Why can't it be the actual mDNS multicast address (e.g.
239.255.255.251)? It wouldn't even be a matter of overloading the existing
DHCP option. The DHCP option returns a *ordered* list of DNS servers (or
back end resolvers if you wish) to be used by a stub resolver. The mDNS
multicast address is just another DNS server to try. The draft states the
intent that mDNS is "an extension to the DNS protocol which consists of a
single change to the method of use ...". I have noticed quite a few changes
and the usage of local.arpa does not seem to be a justified one.

I don't mean that we won't need a new DHCP option. I agree that most likely
one will be needed to address any configuration issues that go beyond simply
enabling/disabling mDNS, but those issues are still TBD.

dan

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, 24 May 2001 19:09:26 -0700 (PDT)

> 239.255.255.251)? 

Well, there are pros and cons to this. It does give you considerable
flexiblity long term. However, one effect is to require admins to
set the address correctly. If they make a mistake, either mDNS won't be
used at all (if the resolver checks for the "correct" address),  or mDNS
might be used on the wrong  scope, which could be disasterous
given that it is only engineered for use on the linklocal scope today. 

> enabling/disabling mDNS, but those issues are still TBD.
As noted earlier, there is the issue of usage order as well as
enable/disable, and potentially the scope issue longer term.

---

From: Robert Elz <[email-masked]>
Date: Fri, 25 May 2001 16:06:52 +0700

Date:        Thu, 24 May 2001 14:59:02 -0400
    From:        "Nicolae, Dan" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I don't think that the "magic address" idea is that bad.

I don't think it is that good either...

  | Why can't it be the actual mDNS multicast address (e.g.239.255.255.251)?

I considered that when I suggested it.   The real problem is the effect
that would have on clients that know nothing about mDNS.   If this were
to be adopted as an indicator, the address needs to be something that can't
cause existing clients to react badly.   If an existing resolver managed to
send to that address, it would expect replies to return from that as a source
addr - and that isn't going to happen.  Clients would also use their normal
retry algorithms, which probably wouldn't be a good idea either.

kre