Subject: comments on mnds-00

From: Erik Guttman <[email-masked]>
Date: Tue, 27 Mar 2001 15:47:03 -0800 (PST)

Levon, Bernard,

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=E0) 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=20
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=20
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? =20

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. =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
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=20
   should be dropped. =20

   Multicast discovery protocols which require all listeners to
   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

>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=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 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=20
section and an A record in the additional section of the response. =20
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.
=20
Why define this behavior?  This is complicated and will make little
difference when a single mdns request is already takes a few seconds=20
to complete.
 =20
>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."=20
>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=20
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=20
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=20
example if no DNS server responds.  This would be the effect of
putting if the link-local mdns address as the last nameserver entry=20
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.) =20

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=
=20
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=
=20
and Bill Woodcock.  The authors gratefully acknowledge their contribution
to the current specification.  Constructive input has also been received=20
from Mark Andrews, Stuart Cheshire, James Gilroy, Olafur Gudmundsson,=20
Erik Guttman, Myron Hattig, Thomas Narten and Erik Nordmark.

Erik
=20

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 28 Mar 2001 08:58:17 -0800 (PST)

> routers must not forward, and we send with hop count/ttl =3D 1 to further=

You seem to be touching on two issues:
1. should be able to span more than one link
2. even on one link the ttl 255 trick is undesired or broken.

Did I get that right?

The issue the 255 trick is addressing is attacks from far away by injecting
bogus unicast responses. Using ttl=1 doesn't address that.
Requiring that both source and destination be link local unicast/multicast
would accomplish close to the same thing as the ttl 255 trick,
but RFC 2461 uses non-link local addresses in some cases which is why
it mandates ttl 255.

  Erik