Subject: Proposed changes to mdns-06

From: Bernard Aboba <[email-masked]>
Date: Sun, 11 Nov 2001 09:54:05 -0800 (PST)

Proposed changes to mdns-06
===========================

Proposer: Dave Thaler
Date: 11/1/01
Section affected: 2

Rationale:
In various sections in the draft, it is assumed that link == Subnet. 
In IPv6, with multilink subnets, this may not necessarily be the
case. The use of the word "subnet" should therefore be changed to
"link" throughout the document.

Proposal:

Change the following text:

"Propagation of multicast DNS packets within the local subnet is
considered sufficient to enable DNS name resolution in small adhoc
networks."

To:

"Propagation of multicast DNS packets on the local link is
considered sufficient to enable DNS name resolution in small adhoc
networks." 

Recommendation: Accept
--------------------------------------------------------------------------------
Proposer: Dave Thaler
Date: 11/1/01
Section affected: 2

Rationale:
In various sections in the draft, it is assumed that link == Subnet. 
In IPv6, with multilink subnets, this may not necessarily be the
case. The use of the word "subnet" should therefore be changed to
"link" throughout the document.

Proposal:

Change the following text:

"In the future, mDNS may be defined to support greater than LINKLOCAL
multicast scope.  This would occur if LINKLOCAL mDNS deployment is
successful, the assumption that mDNS is not needed in multiple subnets
proves incorrect, and multicast routing becomes ubiquitous.  For
example, it is not clear that this assumption will be valid in large
adhoc networking scenarios."

To:

"In the future, mDNS may be defined to support greater than LINKLOCAL
multicast scope.  This would occur if LINKLOCAL mDNS deployment is
successful, the assumption that mDNS is not needed on multiple links
proves incorrect, and multicast routing becomes ubiquitous.  For
example, it is not clear that this assumption will be valid in large
adhoc networking scenarios." 

Recommendation: Accept
--------------------------------------------------------------------------------
Proposer: Dave Thaler
Date: 11/1/01
Section affected: 5.1
Rationale: Distinction between subnet and link needs to be made.

Proposal:

Change the following text:

"If host myhost is configured to use mDNS on both interfaces, it will
send mDNS queries on both interfaces.  When host myhost sends a query
for the host RR for name "A" it will receive a response from hosts on
both interfaces.  Host myhost will then forward a response from the
first responder to the second responder, who will attempt to verify the
uniqueness of host RR for its name, but will not discover a conflict,
since the conflicting host resides on a different subnet.  Therefore it
will continue using its name.

Indeed, host myhost cannot distinguish between the situation shown in
Figure 2, and that shown in Figure 3 where no conflict exists:

             [A]
            |   |
        -----   -----
            |   |
           [myhost]

   Figure 3. Multiple paths to same host

This illustrates that the proposed name conflict resolution mechanism
does not support detection or resolution of conflicts between hosts on
different subnets.  This problem can also occur with unicast DNS when a
multi-homed host is connected to two different networks with separated
name spaces. It is not the intent of this document to address the issue
of uniqueness of names within DNS."

To:

"If host myhost is configured to use mDNS on both interfaces, it will
send mDNS queries on both interfaces.  When host myhost sends a query
for the host RR for name "A" it will receive a response from hosts on
both interfaces.  Host myhost will then forward a response from the
first responder to the second responder, who will attempt to verify the
uniqueness of host RR for its name, but will not discover a conflict,
since the conflicting host resides on a different link.  Therefore it
will continue using its name.

Indeed, host myhost cannot distinguish between the situation shown in
Figure 2, and that shown in Figure 3 where no conflict exists:

             [A]
            |   |
        -----   -----
            |   |
           [myhost]

   Figure 3. Multiple paths to same host

This illustrates that the proposed name conflict resolution mechanism
does not support detection or resolution of conflicts between hosts on
different links.  This problem can also occur with unicast DNS when a
multi-homed host is connected to two different networks with separated
name spaces. It is not the intent of this document to address the issue
of uniqueness of names within DNS."

Recommendation: Accept
--------------------------------------------------------------------------------
Proposer: Bernard Aboba
Date: 11/1/01
Section affected: 2

Rationale:
It should not be assumed that
DHCPv6 will be implemented in IPv6 home networks. It is much more
likely that such networks will use stateless autoconfiguration.
Scenarios for IPv6 use of mDNS should be more completely described.

Proposal:

Change the following text:

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

To:

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

By implementing DHCPv4 as well as a DNS proxy and dynamic DNS,
routers can provide name resolution for the names of IPv4 hosts on the
local network. Where all IPv6 hosts also support IPv4, and the DNS 
proxy supports AAAA RRs, resolution for the names of IPv6 hosts 
on the local network can also be provided. 

For IPv6, stateful autoconfiguration is the most likely 
mechanism for configuration within small adhoc networks. 
It is possible that such networks will contain IPv6-only hosts, and 
that DHCPv6 will not be used. In this case, in order to
support resolution for the names of IPv6-only hosts on the local network,
the DNS proxy will need to support dynamic client update as well as 
DNS over IPv6. While DNS proxies do not support dynamic client update 
today, it is believed that this functionalty is implementable. 

Since using the above mechanisms it is possible for small
networks with a router to enable DNS name resolution, it is assumed that 
multicast DNS need not be enabled by default." 

Recommendation: Accept
--------------------------------------------------------------------------------
Proposer: Levon Esibov
Date: 11/1/01
Section affected: 2

Rationale:
This paragraph is outside the scope of the draft and should be removed.

Proposal:

Remove the following text:

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

Recommendation: Discuss
--------------------------------------------------------------------------------
Proposer: Levon Esibov
Date: 11/1/01
Section affected: 2
Rationale: Sentence is redundant

Proposal:

Remove:

"Namely, this extension allows multicast DNS queries to be sent to and
received on port 53."

Since this is repeated in the next paragraph.

Recommendation: Accept
--------------------------------------------------------------------------------
Proposer: Levon Esibov
Date: 11/1/01
Section affected: 2.1.2
Rationale: Clarification required

Proposal:

Replace:

"A response to an mDNS query MUST have RCODE set to
zero, since mDNS responders MUST NOT send error replies in response to
mDNS queries."

With the following:

"A response to an mDNS query MUST have RCODE set to
zero. mDNS responders may respond only to queries which
they can resolve positively."

Recommendation: Accept
--------------------------------------------------------------------------------
Proposer: Levon Esibov
Date: 11/1/01
Section affected: 3
Rationale: Current text prevents a DNS server from responding to queries for
           its own name. This restriction can be loosened.

Proposal:

Change the following text:

"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, then responder MUST NOT listen
for the multicast DNS queries on the same IP addresses on which the DNS
server listens,  since otherwise they would intercept DNS queries
directed to a DNS server. The DNS server MUST respond to the multicast DNS
queries only for the RRSets owned by the host on which the server is
running, but MUST NOT respond for the records for which the server is authoritative."

Recommendation: Accept
--------------------------------------------------------------------------------
Proposer: Levon Esibov
Date: 11/1/01
Section affected: 3.1
Rationale: DNS discovery also occurs on a per interface basis, so it is not
           global as the current text indicates.

Proposal:

Change the following text:

"For IPv6, the stateless DNS discovery mechanisms described in "IPv6
Stateless DNS Discovery" [19] can be used to discover whether multicast
DNS is globally enabled or disabled."

To:

"For IPv6, the stateless DNS discovery mechanisms described in "IPv6
Stateless DNS Discovery" [19] can be used to discover whether multicast
DNS should be enabled or disabled."

Recommendation: Accept
--------------------------------------------------------------------------------
Proposer: Levon Esibov
Date: 11/1/01
Section affected: 2.1.1
Rationale: Description of IPv6 multicast address behavior should be in section
           2.1.1 instead of 2.1.2

Proposal:

Change the following text:

"The RD (Recursion Desired) bit MUST NOT be set. If a
responder receives a query with the header containing RD set bit, the
responder MUST ignore the RD bit."

To:

"The RD (Recursion Desired) bit MUST NOT be set. If a
responder receives a query with the header containing RD set bit, the
responder MUST ignore the RD bit.

The IPv6 LINKLOCAL address a given responder  listens to, and to which a sender
sends, is a link-local multicast address formed as follows: The name of
the resource record in question is expressed in its canonical form (see
RFC 2535 [15], section 8.1), which is uncompressed with all alphabetic
characters in lower case.  The first label of the resource record name
is then hashed using the MD5 algorithm (see RFC 1321 [16]).  The first
32 bits of the resultant 128-bit hash is then appended to the prefix
FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name multicast
address".  (Note: this procedure is intended to be the same as that
specified in section 3 of "IPv6 Node Information Queries" [14]).  A
responder that listens for queries for multiple names will necessarily
listen to multiple of these solicited name multicast addresses."

Recommendation: Accept
--------------------------------------------------------------------------------
Proposer: Levon Esibov
Date: 11/1/01
Section affected: 2.1.2
Rationale: If descripton of IPv6 multicast address behavior is in section 2.1.1,
           it need not also be in section 2.1.2.

Proposal:

Remove the following text:

"The IPv6 LINKLOCAL address a given responder  listens to, and to which a sender
sends, is a link-local multicast address formed as follows: The name of
the resource record in question is expressed in its canonical form (see
RFC 2535 [15], section 8.1), which is uncompressed with all alphabetic
characters in lower case.  The first label of the resource record name
is then hashed using the MD5 algorithm (see RFC 1321 [16]).  The first
32 bits of the resultant 128-bit hash is then appended to the prefix
FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name multicast
address".  (Note: this procedure is intended to be the same as that
specified in section 3 of "IPv6 Node Information Queries" [14]).  A
responder that listens for queries for multiple names will necessarily
listen to multiple of these solicited name multicast addresses."

Recommendation: Accept
--------------------------------------------------------------------------------
Proposer: Levon Esibov
Date: 11/1/01
Section affected: 5
Rationale: currrent text is too strict with respect to conflicts on alternate
           interfaces.

Proposal:

Change the following text:

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

To:

"After client receives an YXRRSET response to its dynamic update
request that a UNIQUE resource record does not exist, the host MUST check
whether the response arrived on another interface. If this is the
case, then the client can use the UNIQUE resource record in response 
to multicast queries and dynamic update requests. If not, then it 
MUST NOT use the UNIQUE resource record in response to 
multicast queries and dynamic update requests."

Recommendation: Accept
--------------------------------------------------------------------------------
Proposer: Levon Esibov
Date: 11/1/01
Section affected: 3.1
Rationale: 

The following paragraph means that mDNS will not work in home
environments with an ISP-provided DHCP server unless it is
upgraded. 

Proposal:
Delete the following paragraph:

"If an interface has been configured for a given protocol via any
automatic configuration mechanism which is able to supply DNS
configuration information, then multicast DNS SHOULD NOT be used on that
interface for that protocol 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."

Recommendation: Discuss
--------------------------------------------------------------------------------
Proposer: Erik Guttman and Levon Esibov
Date: 10/28/01
Section affected: 3
Rationale: 

The proposed change allows us to completely avoid use of ".local.arpa",
aliasing, etc. Note that this suggestion *does* change the search order
behavior, by  adding a new rule to just try the name.  But section 3 of
mdns-06 also changes the rules, by requiring the adding of local.arpa
suffixes to the search order.
    
Proposal: 

Replace section 3 text:

"
    Multicast DNS usage is determined by special treatment of the
    ".local.arpa."  namespace. The sender treats queries for ".local.arpa."
    as a special case.  A sender MUST NOT send a unicast query for names
    ending with the ".local.arpa." suffix except when:
 
      a. A sender repeats a query after it received a response
         to the previous multicast query with the TC bit set, or
 
      b. The sender's cache contains an NS resource record that enables
         the sender to send a query directly to the hosts
         authoritative for the name in the query.
  
    It is not expected that a host named "host.example.com." will be
    manually configured to have the 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.". For example,
    when a 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.
 
    The same host MAY use multicast DNS queries for the resolution of names
    ending with ".local.arpa.", and unicast DNS queries for resolution of
    all other names. When a user or application requests a DNS client to
    resolve a dot-terminated name that contains a ".local.arpa" suffix, the
    query for such a name MUST be multicast and the name SHOULD NOT be
    concatenated with any suffix."
 
with the following text:
 
   A mDNS "sender" MAY multicast requests for any name.  If the  name
   to be resolved does not end in a trailing dot, for the purposes
   of mDNS, the implicit search order is as follows:

       A.   If the name contains at least one dot, then submit the name itself

       B.   For each DNS suffix in the suffix search list submit the name with
            the current suffix appended.

       C.   If the name contains no dots, then submit just the name.

    The name resolution process should stop as soon as query is
    resolved.
 
Recommendation: Discuss
--------------------------------------------------------------------------------
Proposer: Dave Thaler
Date: 11/1/01
Section affected: 7
Rationale: 

Removal of references to "local.arpa"
    
Proposal: Delete section 7.
 
Recommendation: Discuss

--------------------------------------------------------------------------------
Proposer: Dave Thaler
Date: 11/1/01
Section affected: 2.1
Rationale: 

Removal of references to "local.arpa"
    
Proposal: 

Change section 2.1 text from:

"Responders MUST respond to multicast queries to those and only those
names for which they are authoritative. As an example, computer
"host.example.com.local.arpa." is authoritative for the domain
"host.example.com.local.arpa.". On receiving a multicast DNS A record
query for the name "host.example.com.local.arpa." such a host responds
with A record(s) that contain IP address(es) in the RDATA of the record.

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." unless the host is
configured with multiple names, including "host.example.com.local.arpa."
and "child.host.example.com.local.arpa.". The purpose of limiting the
name authority scope of a responder is to prevent complications that
could be caused by coexistence of two or more hosts with the names
representing child and parent (or grandparent) nodes in the DNS tree,
for example, "host.example.com.local.arpa." and
"child.host.example.com.local.arpa.".

In this example (unless this limitation is introduced) a multicast query
for an A record for the name "child.host.example.com.local.arpa." would
result in two authoritative responses: name error received from
"host.example.com.local.arpa.", and a requested A record - from
"child.host.example.com.local.arpa.". To prevent this ambiguity,
multicast enabled hosts could perform a dynamic update of the parent (or
grandparent) zone with a delegation to a child zone. In this example a
host "child.host.example.com.local.arpa." would send a dynamic update
for the NS and glue A record to "host.example.com.local.arpa.", but this
approach significantly complicates implementation of multicast DNS and
would not be acceptable for lightweight hosts."

To:

"Responders MUST
respond to multicast queries to those and only those names for which
they are authoritative. As an example, computer
"host.example.com." is authoritative for the domain
"host.example.com.". On receiving a multicast DNS
A record query for the name "host.example.com." such a host
responds with A record(s) that contain IP address(es) in the
RDATA of the record.

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." is not authoritative for
the name "child.host.example.com." unless the host is
configured with multiple names, including "host.example.com."
and "child.host.example.com.". The purpose of limiting the
name authority scope of a responder is to prevent complications
that could be caused by coexistence of two or more hosts with the
names representing child and parent (or grandparent) nodes in the DNS
tree, for example, "host.example.com." and
"child.host.example.com.". 

In this example (unless this
limitation is introduced) a multicast query for an A record for the name
"child.host.example.com." would result in two authoritative
responses: name error received from "host.example.com.", and
a requested A record - from "child.host.example.com.". To
prevent this ambiguity, multicast enabled hosts could perform
a dynamic update of the parent (or grandparent) zone
with a delegation to a child zone. In this example a host
"child.host.example.com." would send a dynamic update for
the NS and glue A record to "host.example.com.", but this
approach significantly complicates implementation of multicast DNS
and would not be acceptable for lightweight hosts."
 
Recommendation: Discuss

--------------------------------------------------------------------------------
Proposer: Dave Thaler
Date: 11/1/01
Section affected: 4
Rationale: 

Removal of references to "local.arpa"
    
Proposal: 

Change the text of section 4 from:

"The sequence of events for multicast DNS usage is as follows:

1. If a sender needs to resolve a query for a name
  "host.example.com.local.arpa", then it sends a multicast query to the
   LINKLOCAL multicast address.

2. A responder responds to this query only if it is authoritative
   for the domain name "host.example.com.local.arpa". The responder sends
   a response to the sender via unicast over UDP.

3. Upon the reception of the response, the sender verifies that the Hop
   Limit field in IPv6 header or TTL field in IPv4 header (depending on
   the protocol used) of the response is set to 255. The sender then
   verifies compliance with the addressing requirements for IPv4,
   described in [18], and IPv6, described in RFC 2373 [9]. If these
   conditions are met, then the sender uses and caches the returned
   response. If not, then the sender ignores the response and continues
   waiting for the response."

To:

"The sequence of events for multicast DNS usage is as follows:

1. If a sender needs to resolve a query for a name 
  "host.example.com", then it sends a multicast query to the
   LINKLOCAL multicast address. 

2. A responder responds to this query only if it is authoritative
   for the domain name "host.example.com". The responder sends
   a response to the sender via unicast over UDP.

3. Upon the reception of the response, the sender verifies that the Hop
   Limit field in IPv6 header or TTL field in IPv4 header (depending on
   the protocol used) of the response is set to 255. The sender then 
   verifies compliance with the addressing requirements for IPv4, 
   described in [18], and IPv6, described in RFC 2373 [9]. If these 
   conditions are met, then the sender uses and caches the returned 
   response. If not, then the sender ignores the response and continues 
   waiting for the response." 

Recommendation: Discuss
--------------------------------------------------------------------------------
Proposer: Dave Thaler
Date: 11/1/01
Section affected: 2.1.1
Rationale: Removal of "local.arpa" references

Change:

"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
LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a
responder receives a query with the header containing RD set bit, the
responder MUST ignore the RD bit."

To:

"A sender sends multicast DNS query for any legal Type of resource record
(e.g. A, PTR, etc.) to the LINKLOCAL address.  The RD (Recursion
Desired) bit MUST NOT be set. If a responder receives a query with the
header containing RD set bit, the responder MUST ignore the RD bit.

--------------------------------------------------------------------------------
Proposer: Dave Thaler
Date: 11/1/01
Section affected: 9
Rationale: Removal of "local.arpa" references

Change:

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

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
hosted by "signed keys distribution center", then senders MAY
authenticate the responses using DNSSEC."

Recommendation: Discuss
--------------------------------------------------------------------------------

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