Subject: LLMNR Issue 97: Merging Responses

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Aug 2005 16:58:32 -0700 (PDT)

The text of LLMNR Issue 97 (submitted in IETF last call) is enclosed 
below.  The proposed resolution is as follows: 

Change Section 2.2 to the following:

"2.2. Sender Behavior

A sender MAY send an LLMNR query for any legal resource record type
(e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.

As described in Section 2.4, a sender MAY also send a unicast query.
Sections 2 and 3 describe the circumstances in which LLMNR queries
may be sent.

The sender MUST anticipate receiving no replies to some LLMNR
queries, in the event that no responders are available within the
link-scope. If no response is received, a resolver treats it as a
response that the name does not exist (RCODE=3 is returned).

When multiple valid LLMNR responses are received with the 'C' bit
set, they SHOULD be concatenated and treated in the same manner that
multiple RRs received from the same DNS server would be. However,
responses with the 'C' bit set SHOULD NOT be concatenated with
responses with the 'C' bit clear; instead, only the responses with
the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are
received along with error response(s), then the error responses are
silently discarded.

If error responses are received from both DNS and LLMNR, then the
lowest RCODE value should be returned. For example, if either DNS or
LLMNR receives a response with RCODE=0, then this should returned to
the caller.

Since the responder may order the RRs in the response so as to
indicate preference, the sender SHOULD preserve ordering in the
response to the querying application."

In Section 2.3, change:

"[g]  If a responder is authoritative for a name, it SHOULD respond with
     RCODE=0 and an empty answer section, if the type of query does not
     match a RR that the responder has."

To:

"[g] If a responder is authoritative for a name, it MUST respond with
     RCODE=0 and an empty answer section, if the type of query does not
     match a RR that the responder has."

In Section 2.7, change:

"If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
then a sender SHOULD repeat the transmission of the query in order to
assure that it was received by a host capable of responding to it.
Retransmission of UDP queries SHOULD NOT be attempted more than 3
times. Where LLMNR queries are sent using TCP, retransmission is
handled by the transport layer. Queries with the 'C' bit set MUST be
sent over multicast UDP and MUST NOT be retransmitted. Responses to
queries with the 'C' bit set are not taken into account within
retransmission timeout computations.

An LLMNR sender cannot know in advance if a query sent using
multicast will receive no response, one response, or more than one
response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
has been received, or if it is necessary to collect all potential
responses, such as if a uniqueness verification query is being made.
Otherwise an LLMNR sender SHOULD consider a multicast query answered
after the first response is received, if that response has the 'C'
bit clear.

However, if the first response has the 'C' bit set, then the sender
SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
responses. 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. A unicast query sender
considers the query answered after the first response is received, so
that it only waits for LLMNR_TIMEOUT if no response has been
received.

Since it is possible for a response with the 'C' bit clear to be
followed by a response with the 'C' bit set, an LLMNR sender SHOULD
be prepared to process additional responses for the purposes of
conflict detection and LLMNR_TIMEOUT estimation, even after it has
considered a query answered."

To:

"If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
then a sender SHOULD repeat the transmission of the query in order to
assure that it was received by a host capable of responding to it.
Retransmission of UDP queries SHOULD NOT be attempted more than 3
times. Where LLMNR queries are sent using TCP, retransmission is
handled by the transport layer. Queries with the 'C' bit set MUST be
sent over multicast UDP and MUST NOT be retransmitted. Since queries
with the 'C' bit set are not expected to elicit a response, these
queries do not affect retransmission timeout computations.

An LLMNR sender cannot know in advance if a query sent using
multicast will receive no response, one response, or more than one
response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
has been received, or if it is necessary to collect all potential
responses, such as if a uniqueness verification query is being made.
Otherwise an LLMNR sender SHOULD consider a multicast query answered
after the first response is received, if that response has the 'C'
bit clear.

However, if the first response has the 'C' bit set, then the sender
SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
responses. A unicast query sender considers the query answered after
the first response is received, so that it only waits for
LLMNR_TIMEOUT if no response has been received.

Since it is possible for a response with the 'C' bit clear to be
followed by a response with the 'C' bit set, an LLMNR sender SHOULD
be prepared to process additional responses for the purposes of
conflict detection and LLMNR_TIMEOUT estimation, even after it has
considered a query answered."

-----------------------------------------------------------------------
Issue 97: Merging Responses
Submitter: Yi Zhao
Submitter email address: [email-masked]
Date first submitted: August 11, 2005
Reference: 
Document: LLMNR-42
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:  

When both DNS and LLMNR fail to return an answer, what error should be 
returned? Does the error returned by DNS always take precedence? 

How are multiple responses combined if some responses have the 'C' bit set 
and others do not?  What if one or more responses contain errors or RRs in 
the authority or additional sections?

[BA]  Merging of Multiple Responses

If one response has an error (RCODE = 0 and no answer RRs), but the other
responses contain answers, the error should be discarded. 
It is possible for a sender to receive multiple responses to a query, some 
with the 'C' bit set, and some without the 'C' bit set.  

In this case I'd suggest that only responses with the 'C' bit set should 
be returned, since if there is a conflict between responders who believe 
their responses are UNIQUE, and responders who don't, then the UNIQUE 
responder will need to stop using the name. As a result, merging only the 
non-unique responses produces the most stable result. 

Which error is returned?

I think that the error returned is determined by the first authoritative
name server found.  For example, if DNS returns RCODE=3  and no RRs
in the answer section, and LLMNR returns RCODE=0 and no answers in the
RR section, then the implication is that the LLMNR responder is 
authoritative
for the name.  Therefore I think the error should be RCODE=0 not RCODE=3. 
If no answer is received from LLMNR, then I think the DNS error should
take precedence (RCODE=3).  This despite the statement in LLMNR-42
Section 2.2:

   The sender MUST anticipate receiving no replies to some LLMNR
   queries, in the event that no responders are available within the
   link-scope or in the event no positive non-null responses exist for
   the transmitted query.  If no positive response is received, a
   resolver treats it as a response that no records of the specified
   type and class exist for the specified name (it is treated the same
   as a response with RCODE=0 and an empty answer section).

The problem with this paragraph is that the lack
of a response is NOT treated the same as RCODE=0 and an empty anwer
section in conflict detection, nor in the merging of DNS and LLMNR
errors.  Receiving any response indicates that a responder exists that
is authoritative for the name, whereas receiving no response does not
imply this.  

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