Subject: LLMNR Issue 70 (AD Review): Uniqueness

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 Sep 2004 10:44:15 -0700 (PDT)

The list of current LLMNR Issues and resolutions is available here:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

The text of Issue 70 is enclosed below.  The proposed resolution is as
follows:

In Section 2.2, add:

" 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 multiple
valid answers are received, they may first be concatenated, and then
treated in the same manner that multiple RRs received from the same
DNS server would; the sender perceives no inherent conflict in the
receipt of multiple responses."

Add the following definition to Section 1.2:

UNIQUE

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 only a single
responder is anticipated are referred to as UNIQUE.
Resource record uniqueness is configured on the responder,
and therefore uniqueness verification is the responder's
responsibility.

Replace Section 4 with the following:

"4.  Conflict resolution

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

   By default, a responder SHOULD be configured to behave as though all
   RRs are UNIQUE on each interface on which LLMNR is enabled.  Prior to
   including a UNIQUE resource record in a response, for each UNIQUE
   resource record in a given interface's configuration, the host MUST
   verify that there is no other host within the scope of LLMNR query
   propagation that can return a resource record for the same name, type
   and class on that interface.  Once a responder has verified the
   uniqueness of a UNIQUE resource record, if it receives an LLMNR query
   for that resource record, it MUST respond.

   To verify uniqueness, a responder MUST send an LLMNR query for each
   UNIQUE resource record.  If no response is received after a suitable
number of
   attempts (see Section 2.7), the responder can use the UNIQUE resource
record in
   response to LLMNR queries.  If a response is received, the responder
   MUST check whether the response arrived on an interface different
   from the one on which the query was sent.  If the response arrives on
   a different interface, the responder 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.

   Uniqueness verification is carried out when the host:

     - starts up or is rebooted
     - wakes from sleep (if the network interface was inactive
       during sleep)
     - is configured to respond to LLMNR queries on an interface
       enabled for transmission and reception of IP traffic
     - is configured to respond to LLMNR queries using additional
       UNIQUE resource records
     - verifies the acquisition of a new IP address and configuration
        on an interface

   The name conflict detection mechanism doesn't prevent name conflicts
   when previously partitioned segments are connected by a bridge. In
   order to minimize the chance of conflicts in such a situation, it is
   recommended that steps be taken to ensure name uniqueness. For
   example, the name could be chosen randomly from a large pool of
   potential names, or the name could be assigned via a process designed
   to guarantee uniqueness.

   When name conflicts are detected, they SHOULD be logged.  To detect
   duplicate use of a name, an administrator can use a name resolution
   utility which employs LLMNR and lists both responses and responders.
   This would allow an administrator to diagnose behavior and
   potentially to intervene and reconfigure LLMNR responders who should
   not be configured to respond to the same name."

----------------------------------------------------------------------
Issue 70: Uniqueness
Submitter: Thomas Narten
Submitter email address: [email-masked]
Date first submitted: August 27, 2004
Reference:
Document: LLMNR-34
Comment type: E
Priority: S
Section:  Various
Rationale/Explanation of issue:

> Every responder that responds to an LLMNR query AND includes a UNIQUE
> record in the response:

This is an odd use/defn. of UNIQUE. UNIQUE depends on there being only
one response. The words here seem to say that the responder (if it
cares) needs to ensure this. But the wording is weak. When does a
responder care about a UNIQUE record? If not, it won't bother doing
any steps.

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

What responder cares about this?

If you are trying to say that there are certain RRsets that must be
unique, then better just say that...

> cache. For each UNIQUE resource record in a given interface's
> configuration, 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.

again, I sense that a UNIQUE RR is something that needs to be
configured. Are there words to that effect somewhere?

> record, the host MUST respond. After the client receives a response,
> it MUST check whether the response arrived on an interface different
> from the one on which the query was sent. If the response arrives on
> a different interface, 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.

I'm confused. Is this part of the uniqueness verification algorithm?
It seems like the first sentence and the rest of the paragraph don't
quite go together.

> record, the host MUST respond. After the client receives a response,

Who is the client now? Is this not just requester?

> 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; the
> sender perceives no inherent conflict in the receipt of multiple
> responses.

Do you mean concatenate valid answers? it doesn't make sense to
concatenate various errors, ...

> 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

MAY seems wrong here. MAY is not about implementation choices (when
you receive them...)

--
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/>