[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

LLMNR Issue 62: RCODEs



Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: December 31, 2003
Reference:
Document: LLMNR-28
Comment type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue:

Is the RCODE in an LLMNR response always 0?

Since LLMNR responders only respond to queries for names for which
they are authoritative, LLMNR responders MUST NOT respond
with an RCODE of 3.

Since the UPDATE opcode is not supported, LLMNR
responders MUST NOT respond with an RCODE of 6-10.

But what about other RCODEs or situations in which DNSSEC or DNS
transaction security are used?

While I understand concerns about error storms,  without error codes,
it may be difficult to negotiate use of DNSSEC or diagnose problems.

In Section 2.1.1, change:

"RCODE
Response code -- this 4 bit field is set as part of LLMNR
responses. In an LLMNR query, the RCODE MUST be zero, and is
ignored by the responder. The RCODE MUST be zero in an
LLMNR response. Instead of sending a response with a
non-zero RCODE, an LLMNR responder MUST NOT respond to a
query. A sender receiving an LLMNR response with a
non-zero RCODE value MUST silently discard the response."

To:

"RCODE
     Response code -- this 4 bit field is set as part of LLMNR
     responses. In an LLMNR query, the RCODE MUST be zero, and is
     ignored by the responder.  Since LLMNR responders only respond to
     queries for names for which they are authoritative, LLMNR
     responders MUST NOT respond with an RCODE of 3.  Since the UPDATE
     opcode is not supported, LLMNR responders MUST NOT respond with an
     RCODE of 6-10.

     Where a query utilizes DNS transaction security [RFC2845]
     [RFC2930], RCODE values of 16-21 MAY be returned by an LLMNR
     responder."

Add Section 2.1.2:

"2.1.2.  EDNS0 support

LLMNR implementations supporting EDNS0 [RFC2671] MUST support extended
RCODE values.  Where an LLMNR query is sent utilizing EDNS0 an RCODE of
16 (BADVERS) MAY be sent in the response.

As noted in [RFC3225],  in the event an LLMNR responder returns an RCODE
of 1 (FORMERR), 2 (SERVFAIL) or 4 (NOTIMP) in response to a query that
has the DO bit set, an LLMNR sender SHOULD NOT expect DNSSEC security
RRs and SHOULD retry the query without EDNS0 in accordance with section
5.3 of [RFC2671]."

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