Subject: Proposed resolution to Issue 82: Conflict merging

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

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

In Section 2.2, change:

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

To:

"  The sender MUST anticipate receiving multiple replies to the same
   LLMNR query, in the event that several LLMNR responders receive the
   query and respond with valid answers.  When multiple valid answers
   are received in response to a query (other than a uniqueness query),
   they are treated as follows:

[1]  Responses with the 'T' bit set are silently discarded.

[2]  If all the remaining responses have the 'C' bit set, the responses
     are concatenated and then treated in the same manner that multiple
     RRs received from the same DNS server would.

[3]  If one or more of the responses have both the 'C' and 'T' bits
     clear, a conflict has been detected.  The responses are
     concatenated, but are not cached.  A query for the same name, type
     and class is sent, with the 'C' bit set.  Conflict detection and
     resolution is described in more detail in Section 4.2."

-----------------------------------------------------------------------
Issue 82: Conflict Merging
Submitter: Thomas Narten
Submitter email address: [email-masked]
Date first submitted: March 8, 2004
Reference:
Document: LLMNR-38
Comment type: T
Priority: S
Section:  2.2
Rationale/Explanation of issue:
Section 2.2 states:

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

Is this really what you want in the case where responses conflict?

Merging of responses makes sense for RRs which are not expected to be
UNIQUE, but What about merging of responses from conflicting responders?

Merged conflicting responses will be cached according to the TTL, which
could result in persistence of inconsistencies.

Example: merging of SRV RRs from conflicting responders will result in
inconsistent weighting.

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