Subject: Proposed Resolution to LLMNR Issue 30: Why is Dynamic Update Needed?

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Apr 2003 09:13:12 -0700 (PDT)

The LLMNR Issues List is available at:

http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

During the LLMNR Issue Conference call of 4/16/03, the
only advantage that could be ascribed to Dynamic Update
was that responses to a dynamic update request might be
more likely to fit within a single UDP packet than
responses to an LLMNR query. This reason was felt to
be insufficient for the added complexity and potential
interoperability problems resulting from use of dynamic
update. Even where the response to an LLMNR query is larger
than can fit in a UDP packet (so that the TC bit is set),
it is not clear that the LLMNR sender needs to make
an additional request, since the essential information
(that a conflict exists) is already known.

On the hand, there are numerous potential interoperability issues
that could result from use of Dynamic Update. So the downside outweighs
any potential benefit.

As a result, it is proposed that use of Dynamic Update
be eliminated.

The proposed resolution is to change the text of Section 4
to the following:

"4.  Conflict resolution

The sender MUST anticipate receiving multiple replies to the same LLMNR
query, in the event that several LLMNR 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.

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 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 an SRV type record
   - multiple hosts may respond to a query for an A or AAAA 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 or AAAA
     type record for a hostname.

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

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

Where a host is configured to respond to LLMNR queries on more than one
interface, each interface should have its own independent LLMNR cache.
For each UNIQUE resource record in a given interface's cache, the host
MUST verify resource record uniqueness on that interface.  To accomplish
this, the host MUST send an LLMNR query for each UNIQUE resource record.

By default, a host SHOULD be configured to behave as though all RRs are
UNIQUE.  Uniqueness verification is carried out when the host:

  - starts up or
  - is configured to respond to the LLMNR queries on an interface or
  - is configured to respond to the LLMNR queries using additional
    UNIQUE resource records.

When a host that owns a UNIQUE record receives an LLMNR query for that
record, the host MUST respond.  After the client receives a response, it
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 LLMNR queries.  If not, then it MUST NOT use the UNIQUE
resource record in response to LLMNR queries.

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 LLMNR 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 LLMNR scope is authoritative for
the same name, using the mechanism described above.  Based on the
result, the host detects whether there is a name conflict and acts
accordingly."

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>