Subject: Proposed Resolution to Issue 83: Conflict definition

From: Bernard Aboba <[email-masked]>
Date: Sun, 13 Mar 2005 06:31:28 -0800 (PST)

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

In Section 1.2, change the definition of UNIQUE to the following:

"UNIQUE
There are some scenarios when multiple responders may respond to a
query. There are other scenarios when only one responder may
respond to a query. A responder considers a name to be UNIQUE if
multiple responses are not expected in response to a query for a
name, regardless of the type and class."

Change Section 4 to the following:

"4.  Conflict Resolution

   A responder considers a name to be UNIQUE if multiple responses are
   not expected in response to a query for that name, regardless of the
   type and class.  By default, a responder SHOULD be configured to
   behave as though its names are UNIQUE on each interface on which
   LLMNR is enabled.

   When responding to a query for a UNIQUE name, the 'C' bit is clear in
   the response.  Where the name in the query is not UNIQUE, an LLMNR
   responder sets the 'C' bit in the response.  For example, where
   multiple responders may respond to a query for an A or AAAA type
   record for a cluster name (assigned to multiple hosts in the
   cluster), the 'C' bit is set in the response, regardless of the type
   and class of the query.

   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 83: Conflict Definition
Submitter: Markku Savela
Submitter email address: [email-masked]
Date first submitted: March 5, 2005
Reference:
Document: LLMNR-38
Comment type: T
Priority: S
Section: 1.2
Rationale/Explanation of issue:

Could we just base the "uniqueness" just for plain <name>, and not to
<name,RR> combination? I'm not quite sure what the proposed resolution
actually recommends now...

-----
4.1. Uniqueness Verification

Prior to including a UNIQUE resource record in a response with the
'T' bit clear, 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.
----

Seems to indicate, that uniquenes is <name,RR> feature, but later

----
To verify uniqueness, a responder MUST send an LLMNR query with the
'C' bit clear, over all protocols on which it responds to LLMNR
queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
uniqueness of a name by sending a query for the name with type='ANY'.
seems to indicate, that uniqueness is name only. (If not, then sending
ANY won't work, because ANY does not need to return all RR's...)

[Bernard Aboba]
I agree that uniqueness is based on the name, not the <name,RR>
combination.

> 4.1. Uniqueness Verification
>
> Prior to including a UNIQUE resource record in a response with the
> 'T' bit clear, 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.
> ----
>
> Seems to indicate, that uniquenes is <name,RR> feature, but later

What this is trying to say is that the uniqueness of each RR must be
verified in order to prevent a name conflict. Since sending an ANY
query is only a SHOULD, it also might be possible to send individual
queries. However, regardless of how it is done, if a conflict is
detected, the name is not used in response to any query.

Is there a way to make this more clear?

[Markku Savela]

If uniqueness is for name only, the test becomes very simple: send
query using the name for whatever RR you want to use. The actual type
of RR used in the query does not matter.

Any other node that thinks it owns the name, will answer to the
query. If it does not have any matching type of RR, the answer section
is just empty.

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