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

From: "Christian Huitema" <[email-masked]>
Date: Mon, 21 May 2001 09:05:26 -0700

> From: Robert Elz [mailto:[email-masked]]
>     From:        Harald Tveit Alvestrand <[email-masked]>
>     Message-ID:  <[email-masked]>
>
>   | Is there any reason why a DHCP response containing a DNS server address
>   | should NOT disable MDNS behaviour?
>
> This seems like a much better idea than any of the previous proposals.

Well, it boils down to "if the node has unicast access to a DNS server,
it should not initiate mDNS queries." In fact, it does not matter much
how the DNS server has been found -- DHCP or explicit configuration
would do.

> It almost seems to me that just getting a dhcp response ought be nearly
> enough to disable mDNS - if there's a configured dhcp server, then whether
> it tells you about DNS servers or not, it is obviously telling you what
> the administrator wants you to know.

Nope. One thing is to heed explicit DHCP advice, "the dns server is
there", and another is to extrapolate that if there is a DHCP server, an
administrator might have used it to configure a dns server option.

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 ?

-- Christian Huitema

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: Mon, 21 May 2001 16:12:30 -0700 (PDT)

> how the DNS server has been found -- DHCP or explicit configuration
Assuming that mDNS usage is controlled by the searchlist, then if
".local.arpa" is not in the searchlist, mDNS will not be used, whether
there is a DNS server or not. If ".local.arpa" is last in the searchlist,
then if a DNS server is available and answers, then mDNS will not be used
(modulo use of intelligent DNS resolver timers). 

> > the administrator wants you to know.

If the DHCP server returns the searchlist option, then the DNS resolver is
controlled by the contents of the option. If the DHCP server returns
neither a DNS server option nor a searchlist option, then the default
searchlist (with no ".local.arpa" included) is assumed, and mDNS will
not be used. If the DHCP server returns a DNS server option and no
searchlist option, that unicast DNS server will be used and there will be
no mDNS usage. If the DHCP server returns a DNS server option and a
searchlist option with ".local.arpa" last in the searchlist, then
mDNS will be used, but only as a last resort.

> administrator might have used it to configure a dns server option.

Indeed. This is why the behavior with no searchlist option is *not* to use
mDNS. You don't want an upgraded client to change its behavior from the
current default. So to turn mDNS on, you either need no DHCP server at
all, or you need to return the searchlist option with
".local.arpa" somehwere in the searchlist. 

> OK to use mDNS if the node has lost contact with the configured DNS

The current answer is that if ".local.arpa" is last in the searchlist,
then mDNS will be used after unicast attempts have failed. This can cause
use of mDNS after transient DNS server failures. Back in the days when
mDNS used site scope multicast, this was a substantial cause for
concern. However, now that mDNS is purely linklocal, the effects have been
diminished. I'd note that the usage of mDNS in this scenario will still
depend on the resolver's failover behavior, which is currently undefined. 
In some cases, mDNS might end up being used even when the unicast server
is up, just responding slowly. Many resolvers don't adjust their sending
behavior to the DNS RTT, and some premature mDNS usage is conceivable
(or even likely).

---

From: Robert Elz <[email-masked]>
Date: Tue, 22 May 2001 17:23:05 +0700

Date:        Mon, 21 May 2001 09:05:26 -0700
    From:        "Christian Huitema" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Nope. One thing is to heed explicit DHCP advice,

Yes, that's what I said in the rest of my paragraph...

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

The effect of allowing transient access would be that a short reachability
outage of the configured DNS servers would result in mDNS queries
on the local cable, looking for names that are quite probably not
unique there, and hence getting multiple responses, with no way of
determining which one is the "correct" one.   I think having communications
just fail (as they do now) in that scenario is better.

I suppose a "solution" there would be to require that any mDNS aware
device always do a mDNS name query when it is assigned its name, to
check it for uniqueness, regardless of whether it will use mDNS for
queries later on.   That then requires all (mDNS aware) nodes to always
listen for mDNS queries, and reply when appropriate, even when they're
not making mDNS queries themselves.

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.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 22 May 2001 17:08:50 +0700

Date:        Mon, 21 May 2001 16:12:30 -0700 (PDT)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | If the DHCP server returns the searchlist option,

What DHCP searchlist option???

Even assuming that such a thing eventually gets defined by the IETF,
and that sometime in the future, DHCP servers support it, using a
magic string in it to control something other than the domains to
search seems terribly wrong.

What if I want my DNS lookups to search the local.arpa domain, but I
don't want to use mDNS ?

If you really have to pervert the value of a DHCP option to control this
behaviour (for the cases where DHCP is used) - and you don't want to
wait for a new DHCP option to be defined, it seems that it would be just
as good to designate a "magic" IP address, and say that mDNS is to be
used only if the DHCP server returns that IP address as (one of) the
DNS servers to be queried.  (The magic address could be 127.127.127.127
or something like that, that is going to do no harm to anyone who receives
it and doesn't understand that it is meant to signal use of mDNS - unlike
local.arpa which will have queries from old resolvers (if any that implement
the non-existent DHSP searchlist option can be found) banging on the root
servers looking for an NS list for local.arpa ...)   You could keep the
order dependence - query servers in the order they're given, doing mDNS
instead of a query of the magic address in its turn.

Of course, here there's some cause for problems caused by the general
decoupling of the DHCP client, and of the DNS resolver.   I suspect that
you anticipate that most resolvers will do mDNS if the local.arpa domain
is in the searchlist that they're using.   DHCP clients (ones I know
anyway) tend to build the searchlist out of the DHCP "domain name" option.
DHCP doesn't care that spaces occur in that option - resolvers treat the
spaces as separating domains, and most code treats the first element of
the search list as the "default domain".   But an implementation that
worked like this couldn't conform to your current spec - as passing
"local.arpa" in the "domain name" string isn't specified as enabling mDNS,
only passing it in the "searchlist" option (whatever it turns out to be).
So, implementations would actually need to pass a new flag from the dhcp
client to the resolver, indicating whether the search list handed to the
resolver came from the domain name option, or from the search list option.

This all gets very messy.   Not at all clean.  In fact, down right ugly.

  | I'd note that the usage of mDNS in this scenario will still
  | depend on the resolver's failover behavior, which is currently undefined.

Since current resolvers won't do mDNS at all, this is irrelevant.  If you
need failover behaviour defined for use with mDNS, define it - then the
resolvers bahaviour  (mDNS implementing reslvers) won't be undefined.

kre