Subject: LLMNR Issue 73 (AD Review): RCODEs/TSIG/DNSSEC

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 Sep 2004 10:53:04 -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 73 is enclosed below.  The proposed resolution is as
follows:

In Section 2.9 , change:

"Responders SHOULD NOT perform DNS additional section processing,
except as required for EDNS0 and DNSSEC."

To:

"In LLMNR, the additional section is only intended for use by EDNS0, TSIG
and SIG(0). As a result, senders MAY only include pseudo RR-types in the
additional section of a query; responders MUST ignore the additional
section of queries containing other RR types."

Change Section 5.4 to:

"LLMNR implementations MAY support TSIG and/or SIG(0) security mechanisms.
Since LLMNR does not support "delegated trust" (CD or AD bits), and
LLMNR senders are unlikely to be DNSSEC-aware, in practice LLMNR is not
compatible with DNSSEC.

Since LLMNR implementations MAY NOT support TSIG or SIG(0),
responses to LLMNR queries may be unauthenticated. If
authentication is desired, and a pre-arranged security configuration
is possible, then IPsec ESP with a null-transform MAY be used to
authenticate unicast LLMNR queries and responses or LLMNR responses
to multicast queries. In a small network without a
certificate authority, this can be most easily accomplished through
configuration of a group pre-shared key for trusted hosts."

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

> LLMNR implementations MUST support EDNS0 [RFC2671] and extended
> RCODE values.

Is this necessary? Earlier, the spec says non-zero RCODEs must be
ignored. Isn't an EDNS0 extended RCODE by definition non-zero (I
couldn't quite tell from a quick check, but that would seem to be the
case.)

> Responders SHOULD NOT perform DNS additional section processing,
> except as required for EDNS0 and DNSSEC.

DNSSEC is a part of this?

> If an LLMNR responder is authoritative for the name in a multicast
> query, but an error is encountered, the responder SHOULD send an
> LLMNR response with an RCODE of zero, no RRs in the answer section,
> and the TC bit set. This will cause the query to be resent using
> TCP, and allow the inclusion of a non-zero RCODE in the response to
> the TCP query. Responding with the TC bit set is preferable to not
> sending a response, since it enables errors to be diagnosed.

Don't follow the above. "but an error" is general (not just for too
much data to fit in response). Why would requerying with TCP get a
better response?

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