Subject: Resolution of proposed changes to mDNS-00 draft

From: Bernard Aboba <[email-masked]>
Date: Tue, 03 Jul 2001 17:21:38 -0700

Based on the vigorous discussion we've had over the last month or so,
we've gone back and tried to summarize many of the recommended changes to
the mDNS-00 draft, and the proposed resolutions.

Find enclosed a list of proposed changes and recommended
resolutions. In this list we've included changes for which we had
specific editing instructions and substitute text so that we could
understand exactly what text to modify if the change was accepted.

If an item is not on the list, it's probably because it is controversial
or a large item that is not easily encapsulated in a few paragraphs of
recommended edits. An example is mDNS configuration. For this one, we felt
that the best approach was for someone to come up with an alternate
proposal in order to help facilitate the discussion.  Erik Guttman has
graciously volunteered to act as lightening rod. Thanks, Erik!

In the list "Accept" recommendations are made for changes that we believed
had consensus. "Discuss" recommendations are for changes that may need
more discussion before coming up with a resolution and/or final text.

========================================================================

Recommended resolution of proposed changes to
draft-ietf-dnsext-mdns-00.txt

------------------------------------------------------------------------
Section 1
Submitted by: Erik Guttman, Dave Thaler
Justification: existing language does not specify possible limitations
of the current approach.

Change:

" This extension to the DNS protocol consists of a single change to the
  method of use, and no change to the current format of DNS packets.
  Namely, this extension allows multicast DNS queries to be sent to and
  received on port 53 using the LINKLOCAL addresses [2] for IPv4 and IPv6
  (below referred as the LINKLOCAL address), which are yet to be assigned
  by IANA. LINKLOCAL addresses are used to prevent propagation of
  multicast DNS traffic across routers, potentially flooding the network.
  Propagation of multicast DNS packets within the local subnet is
  considered sufficient to enable DNS name resolution, since the
  expectation is that if a network has a router, then this router can
  function as a DNS proxy, possibly implementing dynamic DNS.  Thus there
  is not expected to be a need for multicast DNS in networks with multiple
  subnets."

to:

" This extension to the DNS protocol consists of a single change to the
  method of use, and no change to the current format of DNS packets.
  Namely, this extension allows multicast DNS queries to be sent to and
  received on port 53.

 The messages are sent using the LINKLOCAL addresses [2] for IPv4 and IPv6
  (below referred as the LINKLOCAL address), which are yet to be assigned
  by IANA. LINKLOCAL addresses are used to prevent propagation of
  multicast DNS traffic across routers, potentially flooding the network.

  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.

  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.

  Once we have experience in mDNS deployment
  in terms of administrative issues, usability and impact on the network
  it will be possible reevaluate which multicast scopes are appropriate
  for use with mDNS."

Proposed Resolution: Accept
--------------------------------------------------------------------
Section 2:

Submitted by: Brian Zill
Justification: Use of the solicited node multicast addresses for
mDNS would reduce the multicast traffic handled by any particular
node.

Change:

"Namely, this extension allows multicast DNS queries to be sent to and
received on port 53 using the LINKLOCAL addresses [2] for IPv4 and IPv6
(below referred as the LINKLOCAL address), which are yet to be assigned
by IANA."
 
To:

"This extension allows multicast DNS queries to be sent to and
received on port 53 using a LINKLOCAL address [2] for IPv4 and
the "solicited node" LINKLOCAL multicast addresses for IPv6."

Proposed Resolution: Discuss
----------------------------------------------------------------
Submitted by: Erik Guttman, Dave Thaler
Justification: Current language does not fully specify retransmission
behavior.

"If the multicast query is not positively resolved ("positively resolved"
refers in this document to a response with the RCODE set to 0) during a
limited amount of time, then a sender MAY repeat the transmission of a
query in order to assure themselves that the query has been received by
a host capable of responding to the query. Repetition MUST NOT be
attempted more than 5 times, and the repetition SHOULD NOT be repeated
more often than once per 0.1 seconds to reduce unnecessary network
traffic. Retry intervals SHOULD be exponentially increased."

Change to:

"If the multicast query is not positively resolved ("positively resolved"
refers in this document to a response with the RCODE set to 0) during a
limited amount of time, then a sender MAY repeat the transmission of a
query in order to assure themselves that the query has been received by
a host capable of responding to the query.

Repetition MUST NOT be attempted more than 3 times and SHOULD NOT
be repeated more often than once per second to reduce unnecessary
network taffic. Retry intervals SHOULD be exponentially increased,
starting from a value of 1 second."

Proposed resolution: Accept
----------------------------------------------------------------
Section 2.1
Submitted by: Erik Guttman, Levon Esibov
Justification: Error reply implosion possible with current text.

To the following paragraph:

"A response to a multicast query is composed in exactly the same manner
as a response to the unicast DNS query as specified in [4]. Responders
MUST never respond using cached data, and the AA (Authoritative Answer)
bit MUST be set. The response is sent to the sender via unicast."

add:

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

Proposed resolution: Accept
------------------------------------------------------------------------
Submitted by: Dave Thaler
Justification: Current text does not address the API issues involved
with setting and checking of TTL.

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

Change to:

"For IPv4 LINKLOCAL addressing, section 2.4 of [6] lays out the rules
with respect to source address selection, TTL settings, and acceptable
source/destination address combinations. IPv6 LINKLOCAL addressing is
described in [9]. mDNS queries and responses MUST obey the rules laid
out in these documents.

In composing an mDNS response, the responder MUST set the Hop Limit
field in the IPv6 header and the TTL field in IPv4 header of the
multicast DNS response 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 the response.

   Implementation note:
   In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL
   socket options are used to specify the TTL of outgoing unicast
   and multicast packets.  The IP_RECVTTL socket option is available
   on some platforms to receive the IPv4 TTL of received packets with
   recvmsg().  RFC 2292 specifies similar options for specifying and
   receiving the IPv6 Hop Limit.
"

Proposed Resolution: Accept

Note from Dave: BTW, the IP_RECVTTL option seems
to exist currently in Linux but not in BSD.  Don't know about any other
OSes.  There's nothing referencable that I can find, but anyone who does
a search on the web for it can easily find the Linux man page that
covers it.
------------------------------------------------------------------------
Submitted by: Erik Guttman
Justification: Specification of the cache period is unnecessary.

Change:

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

To:

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

Proposed resolution: Accept
-------------------------------------------------------------------------
Section 3
Submitted by: Bernard Aboba
Justification: current text is confusing and contradictory

In the paragraph:

"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. A DNS server MAY
listen and respond to multicast queries. By default, a DNS server MUST
NOT listen to multicast DNS queries. For a DNS server, the presence of
".local.arpa." in the domain search list MUST NOT enable multicast DNS."

Remove the sentence:

"A DNS server MAY listen and respond to multicast queries."

Proposed resolution: Accept
--------------------------------------------------------------------
Section 4
Submitted by: Bernard Aboba
Justification: Current text does not cover addressing limitations.

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

Change to:

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. If the destination
   address is a LINKLOCAL address, then the sender verifies use of a
   LINKLOCAL source address. 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.

Proposed resolution: Accept
-------------------------------------------------------------------
Section 5

Submitted by : Levon Esibov
Justification: Use of dynamic update for conflict detection is a
cleaner approach.

Change:

"The uniqueness of the host DNS name MUST be verified 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.").

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 of
type SOA for its own name (i.e. for the name it is authoritative for).
If the query is not positively resolved then the host assumes authority
for the name. If the query is positively resolved, then the host should
verify that the name specified in the RDATA of the SOA record in the
answer section of the response is its own host name.  If the host
verifies this, then it assumes authority for its name.  If the returned
name does not match its host name, then a conflict has been detected. In
order to resolve the name conflict, the host will change its name.

A host that has detected a name conflict MUST NOT use the name. This
means that the host MUST NOT respond to multicast queries for that name
and MUST NOT respond to other multicast queries with resource records
within the RDATA field that contain the conflicted name (for example,
the PTR record).

Note that this name conflict detection mechanism doesn't prevent name
conflicts when previously partitioned segments are connected by a
bridge.  In such a situation, name conflicts are detected when a sender
receives more than one response to its multicast DNS query.  In this
case, the sender sends the first response that it received to all
responders that responded to this query except the first one, using
unicast. A host that receives a response to a query for its own name,
even if it didn't send such a query, sends a multicast query for the SOA
record of the name that it is authoritative for. Based on the response,
the host detects the name conflict and acts according to the description
above."

To:

"There are some scenarios when multiple responders MAY respond to the same
query. There are other scenarios when only one responder may respond to a
query. Resource records for which the latter queries are submitted are
referred to as UNIQUE throughout this document.  The uniqueness of a
resource record depends on a nature of the name in the query and type of
the query. For example it is expected that

- multiple hosts may respond to a query for a SRV type record
- multiple hosts may respond to a query for an A type record for a cluster
  name (assigned to multiple hosts in the cluster)
- only a single host may respond to a query for an A type record for a
  hostname.

Every responder that responds to a multicast DNS query and/or dynamic
update request AND includes a UNIQUE record in the response MUST:

1. Verify that there is no other host within the scope of the multicast
DNS query propagation that can return a DNS record for the same name, type
and class.
2. Responders MUST NOT include a UNIQUE resource record in the
response without having verified its uniqueness.

Where a host is configured to respond to multicast DNS queries on more
than one interface, the host MUST verify resource record uniqueness on
each interface for each UNIQUE resource record that could be used on that
interface. To accomplish this, the host MUST multicast a dynamic
DNS update request as specified in RFC 2136 [RFC 2136] for each new UNIQUE
resource record. Uniqueness verification is carried out when the host:
  - host starts up or
  - is configured to respond to the multicast DNS queries on some
    interface  or
  - is configured to respond to the multicast DNS queries using additional
    UNIQUE DNS records.

Below we describe the data to be specified in the dynamic update request
sections.

  Header section: contains values according to [RFC 2136].

  Zone Section
    The zone name in the zone section MUST be set to the name of the
        UNIQUE record.
    The zone type in the zone section MUST be set to SOA.
    The zone class in the zone section MUST be set to the class of the
        UNIQUE record.

  Prerequisite Section
    This section MUST contain a record set whose semantics are described
    in RFC 2136, Section 2.4.3 =93RRset Does Not Exist=94 of [RFC 2136]
    requesting that no RRs with a NAME and TYPE of the UNIQUE record can
    exist.

  Update Section
    This section MUST be left empty.

  Additional Section
    This section is set according to RFC 2136.

When a host that owns a UNIQUE record receives a dynamic
update request that requests that the UNIQUE resource record set does
not exist, the host MUST respond via unicast with the YXRRSET error,
according to the rules described in Section 3 of RFC 2136 [RFC 2136].

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.

Note that this name conflict detection mechanism doesn't prevent name
conflicts when previously partitioned segments are connected by a
bridge.  In such a situation, name conflicts are detected when a sender
receives more than one response to its multicast DNS query.  In this
case, the sender sends the first response that it received to all
responders that responded to this query except the first one, using
unicast. A host that receives a query response containing a UNIQUE
resource record that it owns, even if it didn't send
such a query, MUST verify that no other host within the multicast DNS
scope is authoritative for the same name, using the dynamic DNS update
request mechanism described above.

Based on the result, the host detects whether there is a name conflict and
acts as described above."

Proposed resolution: Discuss

---------------------------------------------------------------------
Section 5.1
Submitted by: Bernard Aboba
Justification: Need additional text addressing name conflict scenarios
in multihomed hosts

Add the following section:

"5.1.  Considerations for Multiple Interfaces

A multi-homed host may elect to configure multicast DNS on only one of
its active interfaces. In many situations this will be adequate.
However, should a host wish to configure multicast DNS on more than one
of its active interfaces, there are some additional precautions it
MUST take. Implementers who are not planning to support multicast DNS
on multiple interfaces simultaneously may skip this section.

A multi-homed host checks the uniqueness of UNIQUE records as described
in Section 5.

The situation is illustrated in figure 1 below:

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

   Figure 1. Linklocal name conflict

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

Since names are only unique per-link, hosts on different links could be
using the same name.  The situation is illustrated in figure 2 below.

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

   Figure 2. Off-segment name conflict

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.
This illustrates that the proposed name conflict resolution mechanism
does not support 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."

Proposed resolution: Accept

---------------------------------------------------------------------------
Section 5.2
Submitted by: Erik Guttman

Add the following section:

"5.2 Alternatives for solving the multihomed name ambiguity problem

  Unfortunately, simple solutions to this problem do not exist.
  Existing APIs for name resolution and communicating between hosts
  via the socket interface do not expose which interface information
  pertains to. [S]  Following the example in Figure 2, if an application
  on 'myhost' issues the request gethostbyname("A").  mDNS requests will
  be sent from both interfaces and the resolver library will return a
  struct hostent data structure:

     struct hostent {
         char    *h_name;         /* canonical name of host */
         char    **h_aliases;     /* alias list */
         int     h_addrtype;      /* host address type */
         int     h_length;        /* length of address */
         char    **h_addr_list;   /* list of addresses */
     };

  This will include the addresses for both hosts responding to the name
  'A'.  There is no way to determine or influence which interface was
  used to retrieve which address, given the above interface.

  There are some non-solutions to the ambiguous name problem:

   - disallowing multihomed hosts to use mDNS on more than one interface
   - suggesting multihomed hosts to elect to act as IP bridges
   - suggesting multihomed hosts behave as routers to pass mDNS

  While a multihomed host could function as a bridge or router, this
  should be a configured behavior and has profound implications on
  network topology.  Forwarding packets should not be done simply to
  address a link-local protocol limitation.  Avoiding the use of mDNS
  on more than one interface of multihomed devices does, however,
  dissolve the problem:  One cure for double vision is removing the
  second eye.

  There are three possible solutions to the ambigious name problem:

  Approach               Solution                  Assessment

  Do not consider        Applications could        This 'breaks' DNS.
  ambiguity a problem.   come to expect that       It removes the
                         names may be ambiguous.   proper correspondence
                         They would have to        of a domain name
                         establish application     with a RR set from
                         layer naming mechanisms.  an application's
                                                   perspective.

  Resolve the problem.   Enhance mDNS to include   This would require
                         additional messages so    mDNS to deviate from
                         multihomed hosts can      DNS.  This entails
                         hosts of conflicting      further standards
                         names.                    development.

  The mDNS protocol specification already allows for 'gratuitous
  reply messages' (see Section 5).  It is not that much further to
  go to specify behavior by which a multihomed host could send
  gratuitous reply messages on behalf of mDNS servers on distinct
  links to which the host is attached.  This would entail changing
  the conflict resolution algorithm and has profound security
  implications.

  Cope with the problem. This can only be done by  This fails to
                         creating new APIs and     support existing
                         new application software  apps and requires
                         to make use of them.      a substantial API
                                                   standardization
                                                   effort.

  New APIs for name resolution would return the interface associated
  with the each item in the result.  Applications would have to use
  socket (XTI, etc.) interfaces to explicitly select which interfaces
  to use for communication.  From the perspective of a multihomed host
  neither names nor addresses are guaranteed to be unique, though the
  tuple {interface,name} and {interface,address} will be unique."

Proposed Resolution: Discuss.

Note: Text relating to APIs is at variance with a previously accepted
change.

--------------------------------------------------------------------
Section 7
Submitted by: Bernard Aboba
Justification: Addressing limitations should be discussed.

Change:

"In all received packets, the Hop Limit field in IPv6 and the
TTL field in IPv4 is verified to contain 255, the maximum legal value."

To:

"In all received responses, the Hop Limit field in IPv6 and the
TTL field in IPv4 are verified to contain 255, the maximum legal value.
Since routers decrement the Hop Limit on all packets they forward,
received packets containing a Hop Limit of 255 must have originated
from a neighbor. Packets destined for a LINKLOCAL address are
verified to have been sent from a LINKLOCAL source address."

Proposed resolution: Accept
---------------------------------------------------------------------
References
Submitted by: Erik Gutttman
Justification: Current spec does not cite these documents, which are
relevant.

Add:

  [A] Huston, G., "Management Guidelines & Operational Requirements for
   the Internet Infrastructure Domain ("ARPA")", draft-iab-arpa-02.txt,
   May 2001, A work in progress.

  [S] Stevens, W. R., "Unix Network Programming, Networking APIs: Sockets
  and XTI", Prentice Hall, Upper Saddle River, NJ, USA, 1998.

Proposed resolution: accept
----------------------------------------------------------------------
Operational recommendations

Submitted by: Erik Guttman, Levon Esibov
Justification: Need section (or separate BCP document) on operational
recommendations.

Add the following section (or include this in a separate draft):

X.0 Operational Recommendations

X.1 Recommendations to IANA concerning the operation of the ARPA
subdomain:

    ARPA domain servers MUST NOT reply to requests for
    subdomains of '.local.arpa'.

X.2  Recommendations concerning the operation of the protocol  object
regis=
try

    There are no protocol object registry requirements implied by the
    'local.arpa' namespace.  This 'arpa' sub-domain exists to support
    locally administered resources.  These resources are not protocol
    objects per se, unlike for example, PTR RRs in 'in-addr.arpa'.
    The resources constitute arbitrary DNS RRs served by mDNS servers
    themselves.

Proposed resolution: Accept (within a separate BCP document)
------------------------------------------------------------------------
Section 6
Submitted by: Erik Guttman
Justification: ARPA guidelines section is required.

Add the following text:

" This document specifies the use of a new sub-domain of the "ARPA"
  domain.  According to Section 2.1 of the ARPA Guidelines [A], this
  specification requires description and justification.

  The 'local.arpa' domain is used to distinguish a local namespace.
  This namespace differs from others in the following respects:

    - Name servers responding to requests for names in this
      domain have different rules concerning authority.  As
      explained in Section 2.1, mDNS servers have limited
      scope of authority, not extending to sub-domains of
      domain they are authoritative for.

    - Hosts may derive their own names in this namespace,
      independent of centralized authorization and registration
      (as defined in section 3 and section 5).

    - There is no delegation or administrative structure to
      sub-domains of '.local.arpa'.

  How protocol objects are mapped into lookup keys:

    Names are associated with resources which can be requested
    according to the DNS protocol.  However, recursive lookup
    is impossible.  Further, mDNS specifies only the use of
    multicast to transmit these requests.

Proposed Resolution: Accept
----------------------------------------------------------------------

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

---

From: Robert Elz <[email-masked]>
Date: Wed, 04 Jul 2001 03:59:46 -0700

Date:        Tue, 03 Jul 2001 17:21:38 -0700
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | Submitted by: Erik Guttman, Dave Thaler
  | Justification: Current language does not fully specify retransmission
  | behavior.

  | Repetition MUST NOT be attempted more than 3 times and SHOULD NOT
  | be repeated more often than once per second to reduce unnecessary
  | network taffic. Retry intervals SHOULD be exponentially increased,
  | starting from a value of 1 second."
  | 
  | Proposed resolution: Accept

I don't mind that, but specifying "exponentially increased" for
something that can't be attempted more than 3 times doesn't achieve
very much at all ... in particular, delays of 1 second then 1.01 seconds,
then 1.02 seconds is exponentially increasing (just way down at the very
flat part of the curve...)   Even flatter numbers could be chosen.
With so few attempts, just specifying "increased" is really enough.
For someone who uses bigger increases, is it really important to anything
that they choose 1, 2 and 3.00001 second delays, rather than 1, 2,
and 3 second delays?  The latter is a linear increase, so clearly isn't
exponential, whereas 1, 2, and 3.00001 is (or can be justified as being so).

  | Submitted by: Dave Thaler
  | Justification: Current text does not address the API issues involved
  | with setting and checking of TTL.

  |    Implementation note:
  |    In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL
  |    socket options are used to specify the TTL of outgoing unicast
  |    and multicast packets.  The IP_RECVTTL socket option is available
  |    on some platforms to receive the IPv4 TTL of received packets with
  |    recvmsg().  RFC 2292 specifies similar options for specifying and
  |    receiving the IPv6 Hop Limit.
  | "

Personally, I think that is way too much detail, even for an implementation
note.

  | -------------------------------------------------------------------
  | Section 5
  | 
  | Submitted by : Levon Esibov
  | Justification: Use of dynamic update for conflict detection is a
  | cleaner approach.

  | Proposed resolution: Discuss

Yes, do that.

  | ---------------------------------------------------------------------
  | Section 5.1
  | Submitted by: Bernard Aboba
  | Justification: Need additional text addressing name conflict scenarios
  | in multihomed hosts
  | 
  | Add the following section:
  | 

  |      ----------  ----------
  |       |      |    |     |
  |      [A]    [myhost]   [A]
  | 
  | 
  |    Figure 2. Off-segment name conflict
  | 
  | 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,

What?   Since when did anyone ever forward mDNS responses anywhere,
under any circumstances?   What is this supposed to be achieving?

Surely when myhost gets the two response over 2 different interfaces
what it does is implementation defined (pick the first, pick the
last, return both, return an error, all are possible).

Unless and until we get some experience with this, that shows that one
approach works best, leaving it implementation defined is best.

  | ---------------------------------------------------------------------------
  | Section 5.2
  | Submitted by: Erik Guttman
  | 
  | Add the following section:
  | 
  | "5.2 Alternatives for solving the multihomed name ambiguity problem
  | 

  |   While a multihomed host could function as a bridge or router, this

It could be configured as a router.    A host with multiple interfaces
that is configured as a bridge is (at least if all its interfaces are
involved in bridging) only singly homed.   The bridge operates at the
link level, "homing" for what it matters here applies at the network
level - there should be only one network layer interface to a bridged
network (whether the bridging happens in the same hardware, or different
hardware).   That there are some badly broken bridge implementations
around is irrelevant to this.

  |   There are three possible solutions to the ambigious name problem:
  | 
  |   Approach               Solution                  Assessment
  | 
  |   Do not consider        Applications could        This 'breaks' DNS.
  |   ambiguity a problem.   come to expect that       It removes the
  |                          names may be ambiguous.   proper correspondence
  |                          They would have to        of a domain name
  |                          establish application     with a RR set from
  |                          layer naming mechanisms.  an application's
  |                                                    perspective.
  | 
  |   Resolve the problem.   Enhance mDNS to include   This would require
  |                          additional messages so    mDNS to deviate from
  |                          multihomed hosts can      DNS.  This entails
  |                          hosts of conflicting      further standards
  |                          names.                    development.

  |   Cope with the problem. This can only be done by  This fails to
  |                          creating new APIs and     support existing
  |                          new application software  apps and requires
  |                          to make use of them.      a substantial API
  |                                                    standardization
  |                                                    effort.

There's another, simply acknowledge the problem ... if the name is
ambiguous, treat it just the same as if it didn't exist at all.
That is, we can't decide where to go, so we go nowhere.

I'd prefer omitting all of this, and just specifying it as being
implementation defined for now.  Let's not try solving all the
world's problems in one go.

  | ----------------------------------------------------------------------
  | Operational recommendations
  | 
  | Submitted by: Erik Guttman, Levon Esibov
  | Justification: Need section (or separate BCP document) on operational

  | X.0 Operational Recommendations
  | 
  | X.1 Recommendations to IANA concerning the operation of the ARPA
  | subdomain:
  | 
  |     ARPA domain servers MUST NOT reply to requests for
  |     subdomains of '.local.arpa'.

This is the last thing that we want.   All that can possibly achieve is
to have the hosts that are sending the queries, sending more of them,
on the assumption that the query might have been lost.   There MUST be
a reply (just like any other DNS query) - which at the very least will
cause the current query to be terminated, and if we're lucky, might even
be cached for a while, and prevent some future queries being sent to the
ARPA servers.   Further, it would be making a truly silly special case
in the server implementations for that domain.

  | Section 6
  | Submitted by: Erik Guttman
  | Justification: ARPA guidelines section is required.
  | 
  | Add the following text:

There needs to be something in here to prevent hosts sending queries
for this domain to the ARPA servers (that's where it needs to be stopped
not at the ARPA servers).

That could be by specifying that the domain is only to be uses for mDNS
servers, and much never be used by the conventional DNS protocols.
That I think is going a bit too far - I can see uses for purely local
names using the regular DNS, as long as the servers involved are
configured to serve the domain, so they don't forward queries.   But I
guess we could just have both local.arpa and private.arpa (or any other
name dreamed up) in the search list with the first one being used in
mDNS queries, and then the second being used via regular DNS.   But if
I'm doing that, I might as well just use private.ARPA for the mDNS lookup
as well...

I'm actually starting to believe that the issue of names for entities
not using the global DNS for resolution, and the issue of resolution
methods for nodes that have no access to (or don't want to use) the
global DNS are 100% independent, and should be treated separately.

That is, I think I'd be removing all references to local.arpa from this
doc, and defining that in a doc of its own - just so the two things
don't get confused.

That both mechanisms will often be wanted by the same nodes is a
coincidence, and not one that warrants the two specs being merged.

kre

---

From: erik guttman <[email-masked]>
Date: Wed, 04 Jul 2001 10:09:47 -0700

> not at the ARPA servers).

mdns uses 'local.arpa.' because it needs a namespace so
 - names can be generated/determined by hosts automatically
 - resolvers can recognize to use mdns, not use DNS to issue 
   unicast requests with 'recursion desired.'

It was believed that assigning 'local.arpa' for this purpose
was easier than requesting a new TLD.  Is this true?!

The purpose of the IANA guidelines section is to emphasize that the
server authoritative for 'local.arpa' will not be delegate authority 
for any of its subdomains.  Recursive lookups through the ARPA domain 
server should fail,  for that reason.  I agree that they should not 
fail silently.

Correctly implemented mDNS resolvers will not issue recursive 
(or iterative) DNS lookups on names ending with '.local.arpa.'  
But it will happen.

> configured to serve the domain, so they don't forward queries.   

Without allowing (unicast) DNS requests for 'local.arpa.' qualified
names, 
existing DNS resolvers would be unable to look up these names.

Local DNS servers could receive updates from local mDNS stub servers.
In this case, you would get the same results unicasting or multicasting
a request.  Not a bad thing :-)

Erik

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 04 Jul 2001 23:48:31 -0700

> exponential, whereas 1, 2, and 3.00001 is (or can be justified as being so).

Do you have a proposal for better text? Or do we just clarify, by saying
"1, 2, 4 seconds"?

> under any circumstances?   What is this supposed to be achieving?

I'll let Levon respond to this one. But I think the purpose was to alert
one node that there was a conflict. However, as noted later on, all that
will result is that the node will probe and not find a conflict (since the
conflict is off link). So it doesn't fix the problem. 

> approach works best, leaving it implementation defined is best.

Yes. There's no obvious answer. Do you have proposed modified text?

> world's problems in one go.

I agree with this, especially since it seems largely intractable ;)

> in the server implementations for that domain.

Do you have a proposal for modified text?

> not at the ARPA servers).

Do you have a suggestion for the "something"?