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

From: Erik Guttman <[email-masked]>
Date: Tue, 22 May 2001 16:43:02 +0200 (MEST)

Harald Tveit Alvestrand <[email-masked]> wrote:
> Is there any reason why a DHCP response containing a DNS server
> address should NOT disable MDNS behaviour?

What if the DNS servers the DHCP response indicates are not available?
It would be a shame not to disallow mDNS in this case.  The goal of 
ZEROCONF name resolution is to allow local resolution of names even if 
DNS servers fail, DHCP servers supply incorrect information, etc.

Robert Elz <[email-masked]> wrote:
> "Christian Huitema" <[email-masked]> wrote:
> | In fact, we have to also consider transient states. For example, is
> | it OK to use mDNS if the node has lost contact with the configured 
> | DNS server ?
> 
> Probably it isn't. If the node isn't doing mDNS, then it won't have
> done an mDNS name check either (however that ends up being defined to
> be done).   Nor will other nodes, most of which will have been
> configured the same way (assuming this is coming from DHCP advice, or
> similar - if there's none of that, then all nodes able will be doing
> mDNS all the time, and others never will, so that isn't an issue).

If all DNS servers known to a resolver are not responding, why shouldn't 
a resolver use mDNS to attempt to resolve a name?   If the resolver has 
been told not to (by some DHCP configuration, say) it shouldn't.  But
otherwise, why not?  

> All this also leaves aside the question of how a resolver determines
> that there is a transient failure - your typical resolver starts fresh
> with every new application that is run, with no history at all of what
> was done just milliseconds before, and no way to leave advice for queries
> to be made milliseconds later.  Get in fast, get an answer, use it, and
> go away is a common approach.

I agree.  And does it need to be more complicated than that?  As long
as the resolvers check if their configured DNS servers are available,
what's the harm falling back to mDNS as a last resort?

Erik

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

---

From: Robert Elz <[email-masked]>
Date: Tue, 22 May 2001 22:18:58 +0700

Date:        Tue, 22 May 2001 16:43:02 +0200 (MEST)
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <[email-masked]>

  | What if the DNS servers the DHCP response indicates are not available?
  | It would be a shame not to disallow mDNS in this case.

I think you mean allow...

  | The goal of 
  | ZEROCONF name resolution is to allow local resolution of names even if 
  | DNS servers fail, DHCP servers supply incorrect information, etc.

Part of this is who is to be in charge of the network.   If it is
my network, and I don't want any mDNS on it, for whatever reason,
you're saying that it is none of my business, and that nodes should
go ahead and use mDNS whenever they think things aren't working?

Even the draft doesn't suggest that.   And if you agree that it should
be possible to disable mDNS, all that is left is the question of exactly
how that is done.

  | If all DNS servers known to a resolver are not responding, why shouldn't 
  | a resolver use mDNS to attempt to resolve a name?   If the resolver has 
  | been told not to (by some DHCP configuration, say) it shouldn't.  But
  | otherwise, why not?

The assumption has been here that the resolver has been told not to - the
question then was what happens if even then the configured DNS servers
that it has been using become unreachable, can the node ignore the instruction
and go ahead and use mDNS anyway.   It seems that you agree. "no".

If the node has been told it can use mDNS, but only after it has tried
(whatever) and it has tried whatever, and that failed, then of course,
it should use mDNS.  (In some cases "whatever" might be "nothing" and
mDNS is all that is used).

  | I agree.  And does it need to be more complicated than that?  As long
  | as the resolvers check if their configured DNS servers are available,
  | what's the harm falling back to mDNS as a last resort?

Again, what's the context.   And in any case, how does the resolver know
the DNS server is available, but slow, as compared with unavailable.  If
it had waited just one more half second, the answer would have come the
normal way....

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 22 May 2001 09:43:08 -0700

I agree with the complaint that the use of search lists is the wrong place
to implement protocol. Stuffing the search list for a host does not ensure
that the host is able to conform to the needs of the protocol, and will
only obscure things.

For example, a pre-mDNS host may have its search list stuffed with
local.arpa but not be mDNS-aware, and in that case the resolver is likely
to use local.arpa for local completion of relative names, and then attempt
to resolve those names. That could be bad.

With this in mind, it would seem that the best place to implement mDNS is
just before local failure. Considering that there are several ways for any
given host to be configured for DNS activity, mDNS should be the last loop
before a lookup fails. If the host is configured for anything, then the
mDNS function wouldn't be called. That gives the desired results and
doesn't stuff interpretation.

It also means we don't need a DHCP option or a search list extension or
anything else.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 22 May 2001 12:13:39 -0700 (PDT)

> What's the harm in falling back to mDNS?

I think there was originally some concern back when mDNS was using site
scope multicast that a DNS outage could result in an enterprise wide flood
of queries. Now that mDNS is linklocal only, the harm seems minimal.

---

From: Robert Elz <[email-masked]>
Date: Wed, 23 May 2001 16:42:15 +0700

Date:        Wed, 23 May 2001 09:53:32 +0200 (MET DST)
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <[email-masked]>

  | I believe the default (no configuration) and common use case (DHCP DNS 
  | server configuration) should be to allow use of mDNS.  This is really 
  | the only place I think I am disagreeing with some folks posting to the 
  | list.

For no config, yes, I agree.  Where there is config, then it matters
much less, as the config can be be done anyway, if the default needs to
be altered (and whatever the method, it won't be hard) - but I think the
default should be that mDNS needs to be enabled explicitly, so the
behaviour of current nets doesn't suddenly alter just by new (mDNS aware)
clients starting to appear.   That's the way the draft has it now, and
I think that's the right way.

Where I disagree is with the method by which the config info is passed
to the clients (whichever was turns out to be the default).

  | No - I'm just saying mDNS should be permitted unless forbidden.
  | Obtaining DNS configuration from DHCP shouldn't be the same as 
  | forbidding mDNS.

As I just said, whichever way is the default doesn't matter all that
much - some set of admins are going to have to change their config
to get their desired behaviour.   I'd just prefer that my net not
just start behaving differently because I didn't change something.
I'd prefer to have to do the config to get that to happen.

  | Receiving a DHCP DNS server option shouldn't turn off mDNS as a last 
  | resort.  This would mean that in the common case, where DHCP is used 
  | and DNS servers fail (even for a while), one could not use mDNS.

Yes.   That's I think the right default, and it just leaves us exactly
where we are today (where there is no mDNS).   If on your net you would
prefer to have people be able to use mDNS when the DNS servers (back end
resolvers, I wish we could stop calling them servers) are not responding,
all you need to do is set the option in your dhcp config.  Whatever that
option turns out to be.

  | 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.
 
  | Isn't that an implementation decision?  Any value we specify in seconds
  | to wait or adaptive timeout based on RTT will in some cases not be enough. 
  | The real question is one of policy - is mDNS allowed or disallowed?

Yes.   But another policy question for a network might be "what constitutes
failure".   Implementation decision is fine - but if the implementations
decide that "0.1 of a second, no DNS response, I'm using mDNS" then I'm
really not going to like it.   In "distant" parts of the (global) net it
simply takes much longer than that to obtain most answers.  But for some
people, that might be exactly right - if most of your lookups are local,
and mDNS will find them, and you don't want delays, 0.1s might be too long
to be waiting for a regular DNS response (but you might still want to try
it first, so there's a better chance that some local rogue mDNS responder
won't claim to be your mail server's name, and intercept all your mail).

So, this probably needs to be able to be configured (where the net is being
configured) as well as the on/off switch.

Another reason for simply using a new DHCP option to config mDNS, all of
this data could be included in it.

You said "Please see my argument below" for why you believe that mDNS should
default to on, even in a configured net - but I didn't ever find the
argument in the message (or nothing more than "one could not use mDNS"
which is just a fact, and a desireable outcome...)

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 23 May 2001 16:03:12 +0700

Date:        Tue, 22 May 2001 12:13:39 -0700 (PDT)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | > What's the harm in falling back to mDNS?
  | 
  | I think there was originally some concern back when mDNS was using site
  | scope multicast that a DNS outage could result in an enterprise wide flood
  | of queries. Now that mDNS is linklocal only, the harm seems minimal.

It can still result in a lot of queries - with big switched nets
being created sometimes, a "link" can reach a lot of systems.
It would help if the link local multicast address created was
an address that depends upon the name to be located (some kind of
hash as is done in IPv6 ND) but that's still doing to only be a
smallish power of two divisor (and isn't how it is now spec'd,
and certainly complicates implementations).

Whether mDNS should be used when normal DNS resolution has failed is
another thing that needs to be able to be configured (in environments
where things get configured), as distinct from when it should be used
when regular DNS has succeeded, but failed to locate the name (which
is what putting "local.arpa" at the end of the search list is currently
defined to do).

kre

---

From: Erik Guttman <[email-masked]>
Date: Wed, 23 May 2001 09:53:32 +0200 (MET DST)

I believe the default (no configuration) and common use case (DHCP DNS 
server configuration) should be to allow use of mDNS.  This is really 
the only place I think I am disagreeing with some folks posting to the 
list.

> I think you mean allow...

Yes - oops.

> go ahead and use mDNS whenever they think things aren't working?

No - I'm just saying mDNS should be permitted unless forbidden.
Obtaining DNS configuration from DHCP shouldn't be the same as 
forbidding mDNS.  Please see my argument below.

> be possible to disable mDNS, all that is left is the question of exactly

Receiving a DHCP DNS server option shouldn't turn off mDNS as a last 
resort.  This would mean that in the common case, where DHCP is used 
and DNS servers fail (even for a while), one could not use mDNS.

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.  

> it had waited just one more half second, the answer would have come the

Isn't that an implementation decision?  Any value we specify in seconds
to wait or adaptive timeout based on RTT will in some cases not be enough. 
The real question is one of policy - is mDNS allowed or disallowed?

Thanks for working through these issues carefully.

Erik