Subject: RE: comments on mnds-00

From: "Levon Esibov" <[email-masked]>
Date: Fri, 6 Apr 2001 18:31:58 -0700

Erik,

Thanks for very thoughtful comments!

I encourage namedroppers readers to review my responses below, since in
many cases Eric suggests modifications that once already were rejected
by the meeting that took place in Adelaide last year, but I don't have
arguments against some of the Eric's suggestions, in fact, I support
some of them. To ensure that we are not circling around the same
arguments, those of you, who participated in the Adelaide's meeting and
had strong opinion about the issues discussed below, please, make sure
that you send your comments.

> >A sender sends multicast DNS query for any legal Type of 
> resource record
> >(e.g. A, PTR, etcà) for a name within the ".local.arpa." 
> domain to the
>                   ^
>               word cruft
> >LINKLOCAL address.

Sure. I'll fix this.

> If the name is in .local.arpa that indicates it MUST be multicast.
> That is, there is no sense in unicasting this request elsewhere 
> since it will have only local significance.
> 
> The converse is not true:  Why can't a host multicast a request for
> a host name which is not qualified with '.local.arpa'?  If this is 
> not allowed, it severely limits the utility of mdns.  FQDNs 
> are present
> in many protocols, configuration files, documents...  If these cannot
> be resolved locally, what is the point of mdns?  

I don't see any problems with sending multicast queries for the names
that don't end with ".local.arpa". In fact my original proposal didn't
have such limitation, but then the draft was updated according to
recommendations of the initiative group that met in Adelaide a year ago.

I suggest that proponents of that recommendation should speak up.

> >In this example (unless this
> >limitation introduced) the multicast query for an A record 
> for the name
> >"child.host.example.com.local.arpa." would cause two authoritative
> >responses: name error received from 
> "host.example.com.local.arpa.", and
> >requested A record - from "child.host.example.com.local.arpa.".
> 
> 1. Multicast DNS servers should not send error replies - these 
>    should be dropped.  
> 
>    Multicast discovery protocols which require all listeners to
>    respond with a unicast error reply cause broadcast storms.  
>    This is undesirable on a link-local network.  If mdns were 
>    ever to be defined at a larger scope (say administrative 
>    scope) in the future, this would be completely unacceptable.  
>    The protocol has to return correct replies to correct 
>    requests, that's all.

I agree with you. Probably this part of the draft is not written clear
enough.
The draft : "Responders MUST respond to multicast queries to those and
only those names for which they are authoritative.
...
<cut>
...
In conventional DNS terminology a DNS server authoritative for a zone is
authoritative for all the domain names under the zone root except for
the branches delegated into separate zones. Contrary to conventional DNS
terminology, a responder is authoritative only for the zone root. For
example the host "host.example.com.local.arpa." is not authoritative for
the name "child.host.example.com.local.arpa.""

Please, feel free to suggest clarifications to the text.

> >The responder includes in the additional and authority section of the
> >response the same records, as a DNS server would insert in 
> the response
> >to the unicast DNS query.
> 
> Please reword:
> 
> The responder SHOULD include an NS record for itself in the authority 
> section and an A record in the additional section of the response.  
> This is behavior is consistent with existing DNS server 
> implementations.

I don't agree with your suggestion.
It is not the purpose of this draft to specify which records should be
included in the additional and authority sections of the response to a
query. The set of records that should be included in the additional and
authority sections is specified elsewhere.

> 
> >Sender MUST anticipate receiving no replies to some 
> multicasted queries,
> >in the event that no responders are available within the multicast
> >scope, or in the event that no positive non-null responses 
> exist to the
> >transmitted query.
> 
> A responder must not send anything except a positive non-null 
> response.
> That is, a null response or a negative response MUST NOT be sent.  The
> argument for this is given above.

Agree. As I mentioned above, the draft is probably not very about this.
Suggestions on how to improve the text are welcome.

> >If no positive response is received, a resolver treats it as 
> a response
> >that no records of the specified type and class for the 
> specified name
> >exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT
> >exceed 5 seconds.
>  
> Why define this behavior?  This is complicated and will make little
> difference when a single mdns request is already takes a few seconds 
> to complete.

This behavior will prevent poorly written application from resending the
same query after it receives NXRRSET. I agree with your comment that if
sender resends the same query 5 times, with exponentially increasing
interval between them, then the mdsn query resolution may take a few
seconds, what makes negative caching not that useful. May be we should
recommend less number retries (e.g. 3 instead of 5)? In this case we'll
suppress larger number of useless multicast queries. 

> >Sender MUST anticipate receiving multiple replies to the same
> >multicasted query, in the event that several multicast DNS enabled
> >computers receive the query and respond with valid answers.  
> When this
> >occurs, the responses MAY first be concatenated, and then 
> treated in the
> >same manner that multiple RRs received from the same DNS 
> server would,
> >ordinarily.
> 
> With 'MAY' an existing resolver can simply use the mdns address and
> accept the first result, where an enhanced resolver would do something
> slicker.  The problem here is you don't get back the same info as you
> would from a DNS server.  Collecting the duplicates and collating
> them requires additional code, but perhaps it 'SHOULD' be done.

Sounds reasonable.

> 
> >Any device whose domain search configuration contains ".local.arpa." 
> >domain is configured to behave as "responder".
> 
> Why should this behavior be configured using the search path?
> Why should the resolver search path IN ANY CASE determine the 
> multicast dns server behavior?

I don't have any argument in favor of using the search path to
enable/disable device to use mDNS. Original version of the draft
suggested use of a new parameter, but the initiative group that met in
Adelaide a year ago recommended to use the search path.

> I suggest that, just as other zeroconf protocols, a host may either
> run this zeroconf protocol service or not.  This need not be something
> that can be turned off by DHCP, nor should it be - any more than v4LL
> autoconfiguration.

I don't agree. There must be a way to disable mDNS through DHCP, to
prevent mDNS traffic in well managed (i.e. non-zero-conf) corporate
environments, where the last thing users need is more network traffic.

> >It is not expected that a device "host.example.com." will be manually
> >configured to have additional name 
> "host.example.com.local.arpa." when
> >it is configured to use multicast DNS. Instead, a responder 
> with a name
> >"host.example.com." configured with ".local.arpa." suffix in 
> its domain
> >search configuration is authoritative for the name
> >"host.example.com.local.arpa.". I.e. when responder with the name
> >"host.example.com." receives an A type query for the name
> >"host.example.com.local.arpa." it authoritatively responds 
> to the query.
> 
> Why attache the suffix '.local.arpa' stuff?  Why not just multicast
> a request for 'host.example.com'?

As I mentioned above, I don't see any problems with sending multicast
queries for the names that don't end with ".local.arpa".

> >The same device may use multicast DNS queries for the name 
> resolution of
> >the names ending with ".local.arpa.", and unicast DNS 
> queries for name
> >resolution of all other names.
> 
> Why can't a resolver multicast *any* request as a last resort.  For 
> example if no DNS server responds.  This would be the effect of
> putting if the link-local mdns address as the last nameserver entry 
> in /etc/resolv.conf.  I think this makes tremendous sense and provides
> the primary benefit of using mdns: reliability.

I don't mind using your proposal as long as there is a way to disable
such behavior through DHCP in the corp environment to reduce unnecessary
traffic.

> 
> >It is required to verify the uniqueness of the host DNS name 
> when a host
> >boots, when its name is changed, or when it is configured to use
> >multicast DNS (such as when the domain search option is changed to
> >include ".local.arpa.").
> 
> Why is it required?  I could desire to have multiple devices respond
> to the same name for some conceivable application (the devices are
> all redundent identical stateless doodads, for example.)  
> 
> This may be desirable, but at most a SHOULD.
Agree.

> 
> >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).
> 
> Why not just look for an A or PTR RR. 

The original version of the draft suggested use of A type query to
detect name conflict, but the initiative group that met in Adelaide a
year ago recommended to use the SOA type query. I don't see much of a
benefit in SOA, since it doesn't solve the problem and if the sender
receives a response to the SOA query, it doesn't know whether the
response was sent by the sender's another network connection or by
another device that has name in conflict. The sender will have to issue
additional A type query (if A record is not included in the additional
section in the response to the SOA query) to detect whether there is a
device with conflicting name. Said this I agree with your comment to
change this section to use A query.

If there are any opponents to make this modification, please, speak up.

> If another mdns server 
> respondes to 
> the request, there's a conflict.  Do mdns servers need to 
> support SOA RR
> requests? 
Multicast DNS specification should not make any assumptions about the
type of records that could be queried over mDNS, but it doesn't mean
that multiple devices can't respond to the same query. Name conflict
(which this section of the draft attempts to prevent) refers to the
device hostnames only.

> The zeroconf requirements only state A and PTRs 
> are required.
> 

> >A host that has detected a name conflict MUST NOT use the name.
> 
> SHOULD NOT

agree
> 
> >Note that this name conflict detection mechanism doesn't prevent name
> >conflicts when previously separate networks are connected by 
> a bridge.
> >Name conflict in such situation is detected when a sender 
> receives more
> >than one response to its multicasted DNS query.
> 
> This is not catastrophic.  This is like getting back multiple results.

agree

> 
> 
> >8.  Acknowledgements
> >
> >The authors would like to thank Stuart Cheshire, Michael Patton, Erik
> >Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, 
> Erik Nordmark,
> >Myrong Hattig, Bill Manning and James Gilroy for comments on 
> this draft.
> 
> I believe that this section should read:
> 
> This work builds upon original work done on multicast DNS by 
> Bill Manning 
> and Bill Woodcock.  The authors gratefully acknowledge their 
> contribution
> to the current specification.  Constructive input has also 
> been received 
> from Mark Andrews, Stuart Cheshire, James Gilroy, Olafur Gudmundsson, 
> Erik Guttman, Myron Hattig, Thomas Narten and Erik Nordmark.

Sure. I'll update the Acknowledgements section in the next version of
the draft.

Thanks,
Levon.

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: Wed, 25 Apr 2001 11:56:48 +0200 (MET DST)

Levon,

> > >The responder includes in the additional and authority section of 
> > >the response the same records, as a DNS server would insert in the 
> > >response to the unicast DNS query.
> > 
> > Please reword:
<snip>
> authority sections is specified elsewhere.

OK.

> > response. That is, a null response or a negative response MUST 
> > NOT be sent.  The argument for this is given above.
> 

Please modify the following paragraph as follows:

- Sender MUST anticipate receiving no replies to some multicasted queries,
- in the event that no responders are available within the multicast
- scope, or in the event that no positive non-null responses exist to the
- transmitted query.

->

+ Responders MUST NOT send a null response or a negative response.
+
+ Senders MUST anticipate receiving no replies to some multicasted
+ queries, in the event that no responders are availabile within the
+ multicast scope.

> This behavior will prevent poorly written application from resending 
> the same query after it receives NXRRSET. I agree with your comment 
> that if sender resends the same query 5 times, with exponentially 
> increasing interval between them, then the mdsn query resolution may 
> take a few seconds, what makes negative caching not that useful. May 
> be we should recommend less number retries (e.g. 3 instead of 5)? In 
> this case we'll suppress larger number of useless multicast queries. 

Why can't we keep this simple?  If no reply comes back by the time the
mdns requester gives up (however long that is), the requester can treat 
this as a negative response. 

I do not see that caching helps, unless the caching is for a longer 
duration (on the order of minutes).  This is bad in a boot-up scenario, 
where all machines come up around the same time and need to resolve
each others names to access critical services.  Adding negative result
caching will then require minutes to get up and running instead of a 
few seconds, or cause clients to fail completely.

Please modify the following paragraph as follows:

- If no positive response is received, a resolver treats it as a response
- that no records of the specified type and class for the specified name
- exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT
- exceed 5 seconds.

->

+ If no response is received, a resolver treats it as a response that
+ no records of the specified type and class for the specified name
+ exist.

> Adelaide a year ago recommended to use the search path.

If we want a mechanism to disable multicast DNS, why not create an 
DHCP option to do just that.  I believe overloading search paths
with implied transmission semantics will lead to confusion.  Further,
why should search path and behavior be tied together?  Why couldn't 
a DNS server which exists on the same local link as the requestor 
respond to requests for local names?  

> environments, where the last thing users need is more network traffic.

mDNS as specified runs only in a *link-local* mode.  Are you suggesting
that mDNS could be a burden to link-local network traffic?  If so,
please substantiate.

Erik