Subject: Resolution of comments on mdns-05

From: Bernard Aboba <[email-masked]>
Date: Thu, 4 Oct 2001 22:19:32 -0700 (PDT)

Changes proposed to draft-ietf-dnsext-mdns-05.txt
Bernard Aboba

---------------------------------------------------------------
Section 2:

Submitted by: Bernard Aboba
Justification: The specification is not clear about why mDNS
is not enabled by default for home networks where a DHCP server
is present. It is also not clear about whether mDNS is enabled
when there is a router, but no DHCP or DNS server (as might be
the case when using IPv6 with stateless autoconfig).  

Change:

"Propagation of multicast DNS packets within the local subnet is 
considered sufficient to enable DNS name resolution in small
adhoc networks. The assumption is that if a network has a router, 
then the network either has a DNS server or the router can function 
as a DNS proxy, possibly implementing dynamic DNS."

To:

"Propagation of multicast DNS packets within the local subnet is 
considered sufficient to enable DNS name resolution in small
adhoc networks. The assumption is that if a network has a router, 
then the network either has a DNS server support dynamic DNS, 
or the router can function as a DNS proxy. 
By implementing DHCP as well as a DNS proxy
and dynamic DNS, routers can provide name resolution for the 
names of the hosts on the local network. This functionality
is easily provided, and so in such cases it is assumed that
multicast DNS need not be enabled by default."

Proposed resolution: Accept

---------------------------------------------------------------
Section 3:

Submitted by: Levon Esibov
Justification: Sending a unicast query for a name ending with the
".local.arpa" suffix should be ok over any transport after a response
to a multicast request is received with the TC bit set, not just TCP.

Change:

"  a. A sender repeats a query over TCP after it received a response 
     to the previous multicast query with the TC bit set, or 
"

To:

"
  a. A sender repeats a query after it received a response 
     to the previous multicast query with the TC bit set, or 
"

Proposed resolution: Accept

---------------------------------------------------------------
Section 3:

Submitted by: Levon Esibov
Justification: Prohibiting DNS servers from listening to or
responding to mDNS queries seems a bit extreme. Why can't DNS
servers listen to and respond to queries for their own name?

Change:

"If a DNS server is running on a host, the host MUST NOT listen for
multicast DNS queries, to prevent the host from listening on port 53
and intercepting DNS queries directed to a DNS server. 
By default, a DNS server MUST NOT listen to multicast DNS queries."

To:

"If a DNS server is running on a host, only the DNS server MAY listen for
multicast DNS queries. Other services running on such a host MUST NOT listen
for multicast DNS queries on port 53, since otherwise they would intercept
DNS queries directed to a DNS server."

Proposed resolution: Discuss

---------------------------------------------------------------
Section 3.1:

Submitted by: Levon Esibov, Aidan Williams
Justification: In some cases, it might make sense to enable mDNS
by default, so this shouldn't be prohibited.

Change:

"
Multicast DNS usage can be configured manually or automatically. 
On interfaces where no manual or automatic configuration has been 
performed, multicast DNS is enabled by default."

To:

"Multicast DNS usage can be configured manually or automatically. 
On interfaces where no manual or automatic configuration has been 
performed, multicast DNS SHOULD be enabled by default."

Proposed resolution: Accept

---------------------------------------------------------------
Section 3.1:

Submitted by: Levon Esibov, Aidan Williams
Justification: A DNS server shouldn't be prohibited from answering
mDNS queries for its own name. Also, the prohibition on enabling
of mDNS in situations where there is configuration seems a bit harsh.

Change:

"If an interface has been configured via any automatic configuration
mechanism which is able to supply DNS configuration information,
then multicast DNS MUST NOT be used on that interface 
unless it has been explicitly
enabled, whether via that mechanism or any other. This
ensures that upgraded hosts do not change their default behavior,
without requiring the source of the configuration information to
be simultaneously updated. 
This implies that on the interface, the host will neither
listen on the DNS LINKLOCAL multicast address, nor will it 
send queries to that address.
For a DNS server, automatic configuration mechanisms
MUST NOT  enable multicast DNS on any interface."

To:

"If an interface has been configured via any automatic configuration
mechanism which is able to supply DNS configuration information,
then multicast DNS SHOULD NOT be used on that interface 
unless it has been explicitly
enabled, whether via that mechanism or any other. This
ensures that upgraded hosts do not change their default behavior,
without requiring the source of the configuration information to
be simultaneously updated. 
This implies that on the interface, the host will neither
listen on the DNS LINKLOCAL multicast address, nor will it 
send queries to that address."

Proposed resolution: Accept

---------------------------------------------------------------
Section 5:

Submitted by: Levon Esibov
Justification: not isn't capitalized when it has standards language meaning.
"the" is missing from the sentence.

Change:

"After client receives an YXRRSET response to its dynamic update request that a 
UNIQUE resource record does not exist, the host MUST not use the UNIQUE 
resource record in responses to multicast queries and dynamic update requests."

To:

"After the client receives an YXRRSET response to its dynamic update request that a 
UNIQUE resource record does not exist, the host MUST NOT use the UNIQUE 
resource record in responses to multicast queries and dynamic update requests."

Proposed resolution: Accept

---------------------------------------------------------------

Section 5.1:

Submitted by: Levon Esibov
Justification: name conflicts will only exist in situations where
hosts use a name on an interface. If the name is not used, then
conflicts will not occur. 

Change:

"In this situation, the multi-homed myhost will probe for, and defend,
its host name on both interfaces. A conflict will be detected on one
interface, but not the other, and as a result, the multi-homed myhost
will not be able to respond with a host RR for "myhost."

To:

"In this situation, the multi-homed myhost will probe for, and defend,
its host name on both interfaces. A conflict will be detected on one
interface, but not the other, and as a result, the multi-homed myhost
will not be able to respond with a host RR for 'myhost', unless the
host is configured to use the 'myhost' name only on the left (see
Figure 1) network connection."

Proposed resolution: Discuss

---------------------------------------------------------------

Section 7:

Submitted by: Levon Esibov
Justification: Recursive resolution of mDNS queries shouldn't
be allowable. Rather than replying with non-authoritative NXDOMAIN,
it makes more sense for a DNS server not to reply at all. 

Change:

"
    - DNS servers SHOULD NOT forward queries for domain names 
      in the local.arpa domain - if the server cannot answer 
      the query from its own database, it should reply with a  
      non-authoritative NXDOMAIN.
"

To:

"
    - DNS servers SHOULD NOT forward or recursively resolve 
      queries for domain names in the local.arpa domain - if the 
      server cannot answer  the query from its own database, 
      it MUST NOT reply.
"

Proposed resolution: Accept

---------------------------------------------------------------

Section 9:

Submitted by: Levon Esibov
Justification: The current specification wording doesn't distinguish
between behavior of mDNS senders and ordinary hosts.

Change:

"The  mechanism specified in this draft does not require use of the
DNSSEC, which means that the responses to the multicast DNS queries may
not be authenticated. If a network contains a "signed key distribution
center" for all (or at least some) of the DNS zones that the responders
are authoritative for, then hosts on such a network are
configured with the key for the top zone, "local.arpa." (hosted by
"signed keys distribution center") and may use DNSSEC for authentication
of the responders using DNSSEC."

To:

"The  mechanism specified in this draft does not require use of
DNSSEC. As a result, responses to multicast DNS queries MAY NOT
be authenticated. If a network contains a "signed key distribution
center" for some of the DNS zones that the responders
are authoritative for, and senders on that network are
configured with the key for the top zone "local.arpa." (hosted by
"signed keys distribution center"), then senders MAY authenticate
the responses using DNSSEC."

Proposed resolution: Accept

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