Subject: summary/conclusion of discussion on mdns-00

From: Erik Guttman <[email-masked]>
Date: Mon, 14 May 2001 11:46:33 +0200 (MET DST)

Levon, folks,

I want to try and conclude our mdns-00 discussion.  IMO, we have 
consensus on the following points.

[1] Do not limit name in requests to '.local.arpa.'  Allow other
    names.

[2] mdns servers MUST NOT send error replies (to multicast requests)

[3] Clarify text on what names an mdns server responds to requests 
    for (only for names they are authoritative for, and authority for 
    "a" does not in this case imply authority for "child.a"

[4] Responses are never NULL.  An mdns server responds only with
    a positive non-null reply.

[5] Recommend resolvers send few retries to and cache no-responses 
    for a short time to suppress useless multicast queries.  Remove
    specific time (5 seconds).

[6] Change 'Sender MUST anticipate receiving multiple replies' to
    MAY. 

[7] Remove 'search path' configuration text and replace it with text
    regarding a DHCP option to disable mdns behavior.

[8] Change text: 'It is required to verify the uniqueness of the host
    DNS name when a host boots,...' to 'A host MAY verify...'

[9] Change text: 'A gratuitous name resolution query SHOULD be done 
    to check for a name conflict.  This is done by having the resolver
    send a multicast query for a SOA type query for its own name (i.e.
    for the name it is authoritative for.' 
    s/SHOULD/MAY/
    s/SOA/A/

[9] Change text: 'A host that has detected a name conflict MUST NOT
    use the name.'  
    s/MUST/SHOULD/

[10] Change text 'Name conflict in such situation is detected when
    a sender receives more than one response to its multicasted 
    DNS query.'
    To 'It is possible that more than one mdns server will be
    authoritative for the same name.  In some cases it is desirable
    to assign the same name to more than one host.  In this case
    a sender will receive more than one response to its multicasted
    DNS query.'

[11] Modify the acknowledgements section to recognize the contribution
    of Bill Manning and Bill Woodcock.

We had tangential discussion of two additional points.

[12] DNS server discovery

    We debated whether or not it is a good idea to offer more than
    one optional mechanism for configuring DNS server locations.
    Randy doubted whether we need more than DHCP.  Bernard noted
    that when we have a DNS server we can often assume there will
    be a DHCP server too.  All others participating in the discussion
    found some advantage in being able to use DNS to configure DNS.

    Note that this potential is present using mdns as defined, after
    change [1] above.  If an mdns query type='NS' is sent, any mdns
    enabled DNS server that responds has been discovered!

    Suggestion:  Add a note that DNS servers MAY listen for mdns
    requests of type=NS and respond (if the name corresponds to 
    the domain for which the server is authoritative).  Resolvers 
    MAY issue these requests to discover DNS servers.

[13] Service discovery

    We discussed how this might be possible with mdns and SRV RRs.
    Yes it is.  We could debate whether it is the right way to 
    discover services for some time.  Trust me on this.

    Suggestion: Say nothing about service discovery in this draft.  
    If mdns servers support SRV RRs they can respond to queries of 
    type=SRV, but this is already clear in the text:

>A sender sends multicast DNS query for any legal Type of resource record
>(e.g. A, PTR, etc.) for a name...

If there's no further discussion on this required, can the authors 
please issue mdns-01?  I volunteer to coauthor the doc and make the 
changes myself if you guys are overloaded right now.

Erik

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

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 15 May 2001 10:46:10 -0700

>     enabled DNS server that responds has been discovered!

That is not enough information to configure a client. For example, how do
you deal with multiple domain name offers? It is a good idea but there is
a lot more to it, or "there is a lot of procedural protocol to be defined"
at the very least. Probably the use of a new query type would be
beneficial to implementions as well. Anyway, there is a lot more to it
than this, but it is a good idea and it should be given direct and
complete treatment on its merits.

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 15 May 2001 17:01:09 -0400

>[1] Do not limit name in requests to '.local.arpa.'  Allow other

Not allowed, all queries to discover servers MUST be in domain local.arpa.

>[2] mdns servers MUST NOT send error replies (to multicast requests)

Yes,

>     "a" does not in this case imply authority for "child.a"

This needs clarification on if a delegation ?

>     a positive non-null reply.

Yes MUST.

>     specific time (5 seconds).

Why ? Replacing time with upper bound on retries is fine.

>[6] Change 'Sender MUST anticipate receiving multiple replies' to

Why change that, this reduces the robustness of the protocol ?

>     regarding a DHCP option to disable mdns behavior.

Does such an option exist?
I worry that not specifying in this document how to do this people will
go different ways.

>     DNS name when a host boots,...' to 'A host MAY verify...'

Again you want to reduce the robustness of the protocol, I can live
with changing the wording from "boot" to "before attempting any name
resolution"

>     for the name it is authoritative for.'

No way this change should be done!!! Read notes from the Adelaide lunch 
meeting to understand why.

>[9] Change text: 'A host that has detected a name conflict MUST NOT

NO,

>     a sender will receive more than one response to its multicasted

No

>     of Bill Manning and Bill Woodcock.

Yes please do.

Sorry for not getting involved sooner but I have been preoccupied with
DNSSEC over the last few weeks.

         Olafur (DNSEXT co-chair)

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 15 May 2001 15:52:59 -0700 (PDT)

In making conclusions on WG consensus, it is important to take past
discussion into account. A number of these changes were extensively
discussed in the past and rejected. So we don't start over from scratch in
establishing consensus for every posting. 

> [1] Do not limit name in requests to '.local.arpa.'  Allow other

This one was extensively discussed already, and WG consensus was to use
.local.arpa. So default should be to reject the change unless it can be
demonstrated that the WG has changed its mind. 

> [2] mdns servers MUST NOT send error replies (to multicast requests)

Think more discussion is needed on the implications of this. Hard to think
of any bad effects, but the DNS experts in the WG might think of some ;)

>     "a" does not in this case imply authority for "child.a"

Think this one is ok. 

>     a positive non-null reply.

Also looks ok to me. 

>     specific time (5 seconds).

Looks ok to me. 
> [6] Change 'Sender MUST anticipate receiving multiple replies' to

If multiple replies are possible, then the sender MUST anticipate
them. Recommend to not accept the change.

>     regarding a DHCP option to disable mdns behavior.

This was extensively discussed previously. Recommend that we not make the
change. 

>     DNS name when a host boots,...' to 'A host MAY verify...'

Also discussed at length. Name conflicts can be a big problem, so it seems
prudent to err on the side of caution. Recommend rejecting the change.

>     for the name it is authoritative for.' 

Again, I think that name conflicts are a problem and caution is
advised. Recommend against the change.

> [9] Change text: 'A host that has detected a name conflict MUST NOT

For same reasons, recommend against the change.

>     a sender will receive more than one response to its multicasted

Don't agree that we should allow more than one host with the same name. I
think this is a problem. Recommend against the change.

>     of Bill Manning and Bill Woodcock.

No problem with this -- assuming that the Bills agree.

>     found some advantage in being able to use DNS to configure DNS.

This was extensively discussed previously with consensus against use in
this way. So I recommend against taking the change -- unless the original
proponents are canvassed and agree to it. 
> >(e.g. A, PTR, etc.) for a name...

Agree that the draft should not get into this. Do you have specific text
that you want stricken? I was under the impression that we are fairly
innocent on this score already. 

> please issue mdns-01?  

mdns-01 is indeed overdue, but I think we need some more discussion on the
points above before we issue it.

---

From: Erik Guttman <[email-masked]>
Date: Wed, 16 May 2001 07:50:49 +0200 (MET DST)

Olafur,

A couple comments I didn't send in my response to Bernard.

> Not allowed, all queries to discover servers MUST be in domain local.arpa.

Why?  Who doesn't allow it?

> Why ? Replacing time with upper bound on retries is fine.

As long as the algorithm is correct (i.e. exponential back off, caching
non-response), the specific time bounds are an implementation detail.
Different resolvers may be used in different scenarios - some will be
designed for responsiveness suitable for human users, others will have
no human user and could therefore be more patient.  At most we can put
a SHOULD here.

Erik

---

From: Erik Guttman <[email-masked]>
Date: Wed, 16 May 2001 07:46:41 +0200 (MET DST)

> establishing consensus for every posting. 

There were presentations made during DNSEXT WG meetings, but no discussion
or action on the mailing list.  I posted a list of discussion items in 
March, for which there was discussion.  I attempted to reflect the outcome
of that discussion, which might be wrong.

If we do not establish consensus for this protocol, we will not advance
it.  So let's try to iron out all the loose wrinkles here.  Let's
especially try to avoid unnecessary 'MUST's in the protocol specification.

> demonstrated that the WG has changed its mind. 

Why not?

> of any bad effects, but the DNS experts in the WG might think of some ;)

This is needed because a malformed request would cause an implosion of 
errors.  If there were many mdns servers this would be a very bad thing!

> them. Recommend to not accept the change.

I suggest 'SHOULD' at most.  There are applications which require only
one reply.  There are millions of resolvers deployed today which would
only await one reply and could otherwise use mdns.

> This was extensively discussed previously. Recommend that we not make the

The problem is that search-path and other behavior are not necessarily
interdependent.  Overloading the interpretation of the search list is a
bad idea.  Why not have a distinct DHCP option which turns off mdns?

> prudent to err on the side of caution. Recommend rejecting the change.

These comments concern [8], [9] and [10] also.

Different addresses are often assigned the same name, to provide
redundency.  These are effectively aliases.  Unless we make the 
change, it would not be possible to support this useful feature
with mdns!  At most a SHOULD here.

There are good reasons for detecting name conflicts, just as there 
are good reasons, sometimes, for not considering multiple assignments 
of the same name as a conflict.
 
Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 16 May 2001 17:14:38 +0200 (CEST)

> demonstrated that the WG has changed its mind. 

When thinking about local.arpa it would be good to take a look at
draft-iab-arpa-01.txt.

  Erik

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 16 May 2001 23:49:40 +0900

>prudent to err on the side of caution. Recommend rejecting the change.

	I'm seeing a little bit of conflict between [6] and [8], if everything
	works perfectly.  mdns responder (server?) will respond to
	foo.local.arpa, iff the device is called "foo" or "foo.local.arpa" (*).
	so if [8] is always true, we don't need to care about multiple 
	responses.  if there's possibility for [8] to be false, we need
	to care about multiple responses.

	in realworld situation, yes, [8] may not be true (even though every
	devices try to verify the uniqueness of name), and thus we need to
	consider [6].

	i'd like to see some comment/footnote in the draft, to help
	people understand the background (i don't think we need to change
	the wording itself).

	(*) in the past draft proxy replies (bar replies to query to "foo"
	if bar knows foo) were permitted, but now is dropped.

>advised. Recommend against the change.

	i strongly object against s/SOA/A/ change.  we can't assume that every
	device has an IPv4 address (think of IPv6 only devices).

itojun

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 18 May 2001 13:56:34 +0200

>I worry that not specifying in this document how to do this people will

Is there any reason why a DHCP response containing a DNS server address 
should NOT disable MDNS behaviour?
Seems to me that if an admin bothers to tell you a DNS server to use, it is 
rather strange behaviour to use the multicast model.

     Harald, department of wheel non-reinvention

---

From: Robert Elz <[email-masked]>
Date: Sat, 19 May 2001 13:09:55 +0700

Date:        Fri, 18 May 2001 13:56:34 +0200
    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.

There is (obviously) no "disable mDNS" option in DHCP currently, but
nor is there a "set the search list" option - though there has been a
proposal for the latter I believe.   But even if completed, it is
currently supported by no-one.

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.   But as I said, "almost" - unfortunately
there are dhcp servers around these days that simply turn themselves on, and
respond with whatever they believe the clients need to know, with little or
no administrator action.   Fortunately though they can't start sending out
DNS server addresses without knowing there are actually DNS servers at the
addresses (back end resolvers really, calling them servers is a mistake)
so Harald's suggestion makes a lot of sense.

What's more, as soon as that "magic string in the search list" stuff is
gone, the whole "local.arpa" nonsense can go with it (which isn't to say
that people shouldn't use that necessarily, just that there's no reason
at all to compel it).   (ie: unlike some others on the list, I agree
with proposed change #1).

As it is, it isn't at all clear from the draft how it is to be used - if the
theory is that it would be used like any other domain in the search list,
and then, when doing a lookup inside it, mDNS would be used - then it doesn't
work very well as seems has been assumed.   In particular, the search list is
usually only used for unqualified names "foo" rather than for names containing
dots, and is never used for FQDN's.   That means only unqualified names can
ever be found using mDNS (or that's all you can rely upon).   Since unqualified
names aren't legal in many places (such as in e-mail) this would rather
severely restrict the utility of the approach.

A better approach is simply to allow a node which has no DNS back end
resolver configured (ie: neither the DNS, nor the local admin/user has
set one) to send mDNS queries for any name it wants to look up.

Then it either gets a positive response, or it gets nothing (I'm not
actually sure that stopping a properly configured resolver back end from
sending negative replies is needed - that could save some delays, and I
don't see any immediate harm from that - but nor is it essential to allow
it, and preventing thousands of replies because everyone thinks they
properly know there is no such name is certainly required).

I'm also not sure that simply doing a query for the name I want to
claim, and grabbing it if there's no response (or the response identifies me)
is adequate.   I think I'd prefer to have the node send a dynamic DNS
"add me if I don't exist" type transaction.   Then, if anyone else out there
has the name, they'd respond, and return an error (name already exists).
If no-one has the name, no response, just as before, and things continue.

That seems to be just the same - but this way, if there is a properly
configured back end resolver, it could take that "add me" and send it
to the server for the domain, and actually cause the node to be registered
in the global DNS, if that's what the local site admins want to happen
(it isn't mandatory, just an option).   No-one can do that merely from a
query (or series of queries) for the name.

Not only does this add functionality, but it also allows a test "does the
name exist" which (other than sending a query type ANY, which has other
potential problems) otherwise doesn't exist in the DNS.   Certainly mandating
that the query be A is wrong, as Itojun pointed out - but doing an SOA
query seems to totally misunderstand where SOA records actually exist
(unless mDNS "responders" aren't to interpret such a query the same way that
any normal DNS server would).

kre

ps: please change all uses of "multicasted" in the doc to just "multicast".

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 21 May 2001 14:42:46 -0400

> rather strange behaviour to use the multicast model.

The text in the MDNS document is supposed to explain the following:
if a host gets configured by DHCP, it can ONLY use MDNS when the DHCP
server includes the string "local.arpa." in the search path.

This avoids reserving a special DHC option, but still allows turning
MDNS on in DHCP configured environment.

>      Harald, department of wheel non-reinvention

Olafur, department of constant changes.