Subject: comments on mnds-00

From: Erik Guttman <[email-masked]>
Date: Wed, 28 Mar 2001 18:11:57 -0800 (PST)

Levon, Bernard,

Apologies if this is a duplicate message.

The following comments concern draft-ietf-dnsext-mdns-00.txt

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

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 suggest that a mdns name server serve only those names which the
host has been configured with - suggesting the addition of a local
name (alias).  This name can be used by protocols which advertise
local services, which are found via a link-local service discovery
protocol.  

The advantage of using a local name instead of a string representation 
of an IP address is that the local name will remain valid even when the 
host renumbers (which it could do at any time when using IPv4 link-local 
autoconfiguraion).  This alone is not a compelling reason to use local
names.

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

2. Given that, I do not understand the ambiguity. A host not 
   configured with a name would not respond to a request for it.  

>The responder MUST set the Hop Limit
>field in IPv6 header and TTL field in IPv4 header of all responses to
>the multicast DNS query to 255. The sender MUST verify that the Hop
>Limit field in IPv6 header and TTL field in IPv4 header of each response
>to the multicast DNS query is set to 255. If it is not, then sender MUST
>ignore such response.

Shouldn't IPv6 hop count / IPv4 TTL be 1 for link-local multicast dns?
If this is a 'clever trick' which will cause listeners to drop messages
after they've traversed a single router (they will always be less than 
255 in this case), I claim this is not a good idea.  A link-local 
protocol shouldn't be routed at all:  We choose an address we specify 
routers must not forward, and we send with hop count/ttl = 1 to further 
reduce this possibility.

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

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

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

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

>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'?

I thought '.local.arpa' allowed a separate namespace for queries
which would not be in the DNS.  If you append it, you effectively
alias names in the DNS to the local namespace - buying you nothing.

A host may have a '.local.arpa' name, entirely self administered,
*in addition* to its normal (fully qualified) domain name.  An 
mdns responder should respond to either.

In any case, why should the resolver search path effect responder
behavior?

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

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

>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.  If another mdns server respondes to 
the request, there's a conflict.  Do mdns servers need to support SOA RR
requests?  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

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

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

Erik

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

---

From: [email-masked]
Date: Thu, 29 Mar 2001 10:56:49 +0300

Is it possible and allowed for mDNS responders to send gratuitous responses?
This would solve the following problem that could occur in a Zeroconf
environment:

Say one device accesses a web-server, and both (mobile) devices have
configured a link-local IP address. In the middle of the session an address
conflict is detected and the server has to change its IP address, e.g. the
network joins another network, where a third device is using the same
link-local IP address as the web-server. The mobile device accessing the
web-server would not notice anything, except that it looks like the server
is not responding anymore. A solution to this would be a unicast DNS
response from the server (the mDNS responder) to the client, binding the
name to the new link-local IP address.

Nothing is stated about this in the draft, but it is also not explicitly
prohibited. Does anyone have an opinion on this?

Also one small comment on the draft:
> A device configured to be a "responder" may also be a 
> "sender". A device
> configured to not be a "responder" cannot be a "sender".
> 
> Multicast DNS usage is determined by the domain search configuration as
> well as by special treatment of the ".local.arpa." namespace.  Any
> device whose domain search configuration contains ".local.arpa." domain
> is configured to behave as "responder". A device configured to be a
> "responder" may also be a "sender". A device cannot be configured to
> behave as one (i.e. sender or responder), but not another.
The first statement says a responder MAY also be a sender, while the second
statement says a responder CANNOT be configured to behave as a responder
only, and not as a sender. There seems to be a conflict here. IMHO, a device
should be able to be responder only, when it will never do any name
resolution using mDNS itself, but responds to mDNS queries (as an example,
again the local web server).

Regards,
Sander

> -----Original Message-----
> From: ext Erik Guttman [mailto:[email-masked]]
> Sent: 28. March 2001 02:47
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]; [email-masked]
> Subject: comments on mnds-00
> 
> 
> Levon, Bernard,
> 
> >(e.g. A, PTR, etc=E0) for a name within the ".local.arpa." 
> domain to the
>                   ^
>               word cruft
> >LINKLOCAL address.
> 
> That is, there is no sense in unicasting this request elsewhere=20
> a host name which is not qualified with '.local.arpa'?  If this is=20
> be resolved locally, what is the point of mdns? =20
> 
> protocol. =20
> The advantage of using a local name instead of a string 
> representation=20
> of an IP address is that the local name will remain valid 
> even when the=20
> host renumbers (which it could do at any time when using IPv4 
> link-local=20
> 1. Multicast DNS servers should not send error replies - these=20
>    should be dropped. =20
> 
>    respond with a unicast error reply cause broadcast storms. =20
>    This is undesirable on a link-local network.  If mdns were=20
>    ever to be defined at a larger scope (say administrative=20
>    scope) in the future, this would be completely unacceptable. =20
>    The protocol has to return correct replies to correct=20
>    requests, that's all.
> 
> 2. Given that, I do not understand the ambiguity. A host not=20
>    configured with a name would not respond to a request for it. =20
> 
> after they've traversed a single router (they will always be 
> less than=20
> 255 in this case), I claim this is not a good idea.  A link-local=20
> protocol shouldn't be routed at all:  We choose an address we 
> specify=20
> routers must not forward, and we send with hop count/ttl =3D 
> 1 to further=
> =20
> reduce this possibility.
> 
> The responder SHOULD include an NS record for itself in the 
> authority=20
> section and an A record in the additional section of the response. =20
> =20
> difference when a single mdns request is already takes a few 
> seconds=20
> to complete.
>  =20
> >Any device whose domain search configuration contains 
> ".local.arpa."=20
> Why should the resolver search path IN ANY CASE determine the=20
> *in addition* to its normal (fully qualified) domain name.  An=20
> Why can't a resolver multicast *any* request as a last resort.  For=20
> putting if the link-local mdns address as the last nameserver entry=20
> all redundent identical stateless doodads, for example.) =20
> 
> Why not just look for an A or PTR RR.  If another mdns server 
> respondes to=
> =20
> This work builds upon original work done on multicast DNS by 
> Bill Manning=
> =20
> to the current specification.  Constructive input has also 
> been received=20
> from Mark Andrews, Stuart Cheshire, James Gilroy, Olafur 
> Gudmundsson,=20
> =20

---

From: Erik Guttman <[email-masked]>
Date: Thu, 29 Mar 2001 16:09:30 -0800 (PST)

Bernard,

>Given this reality, we feel that it is necessary for hosts to
>incorporate their own protection mechanisms, rather than relying on
>routers to do the right thing. Requiring TTL=255 provides a mechanism
>for hosts to protect themselves against off-segment attackers, since
>routers that do not recognize 169.254/16 as a linklocal prefix will
>still decrement TTL. 
>
>This issue exists not only for mDNS but also for all use of IPv4
>linklocal addresses. 

I am sensitive to your issue, but your proposed solution will not work.
Neither the sockets API nor XTI allows the receiver to determine the 
TTL of a received datagram.  This is not an issue for IPv6 neighbor 
discovery but it would be for any user-level application (like mdns).
The only way to implement this on most platforms would be to write 
mdns over raw IP sockets (yuck).

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n                   Email: [email-masked]
Sr Staff Engineer, Sun Microsystems               Cell # 415 420 4425

---

From: Erik Guttman <[email-masked]>
Date: Fri, 30 Mar 2001 10:41:49 -0800 (PST)

From: Bill Manning <[email-masked]>

>% could we have a document reference for this?

draft-ietf-zeroconf-ipv4-linklocal-02.txt is in working group
last call.  It will be a proposed standard Real Soon Now.

> draft-ietf-dhc-ipv4-autoconfig-04.txt, October 1998
This draft has expired and is not being pursued.  The right
draft to look at is the official, chartered, zeroconf draft.

> See: RFC 2563 for documentation on how to disable this feature.
This draft has not been implemented by any vendors I know of.
There is even interest in reclassifying this RFC as historic
as we are no longer supporting the idea of transitioning from
link local to dhcp configuration.  Rather link local should
be used exclusively or in addition to other configuration.

Erik