Subject: Proposed resolution to LLMNR Issue 88: Names vs. RRSETs

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Jul 2005 23:33:58 -0700 (PDT)

The text of LLMNR Issue 88 is enclosed below.  This and other LLMNR issues
are tracked on the LLMNR Issues page:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

The proposed resolution is as follows:

In Section 2.1.1, change:

"    In an LLMNR response, if one or more resource records in the answer
     section is UNIQUE, then the 'C' bit is clear, otherwise it is set."

To:

"     In an LLMNR response, if the name is considered UNIQUE,
     then the 'C' bit is clear, otherwise it is set."

In Section 4, change:

"The uniqueness of a resource record MAY depend on the nature of the
name in the query and type of the query. For example, multiple hosts
may respond to a query for an A or AAAA type record for a cluster
name (assigned to multiple hosts in the cluster). By default, a
responder SHOULD be configured to behave as though all RRs are UNIQUE
on each interface on which LLMNR is enabled."

To:

"By default, a responder SHOULD be configured to behave as though its name
is UNIQUE on each interface on which LLMNR is enabled. However, it is
also possible to configure multiple responders to be authoritative for
the same name. For example, 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)."

In Section 4.1, change:

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

Once a responder has verified the uniqueness of a UNIQUE resource
record, if it receives an LLMNR query for that resource record, with
the 'C' bit clear, it MUST respond, with the 'T' bit clear. Prior to
verifying uniqueness, a responder MUST set the 'T' bit in responses."

To:

"Prior to sending an LLMNR response with the 'T' bit clear,
a responder configured with a UNIQUE name MUST verify that
there is no other host within the scope of LLMNR query propagation
that is authoritative for the same name on that interface.

Once a responder has verified that its name is UNIQUE, if it receives an
LLMNR query for that name, with the 'C' bit clear, it MUST respond,
with the 'T' bit clear. Prior to verifying that its name is UNIQUE,
a responder MUST set the 'T' bit in responses."

In Section 4.2, change:

" If the query is for UNIQUE resource record(s), then the responder
MUST send its own query for the same name, type and class, with the
'C' bit clear. If a response is received, then a conflict has been
detected."

To:

"If the query is for a UNIQUE name, then the responder
MUST send its own query for the same name, type and class, with the
'C' bit clear. If a response is received, then a conflict has been
detected."

--------------------------------------------------------------------------
Issue 88: Names vs. RRSETs
Submitter: Stuart Cheshire
Submitter email address: [email-masked]
Date first submitted: May 25, 2005
Reference:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html
Document: LLMNR-40
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

     Since LLMNR responders only respond to LLMNR queries for names for
     which they are authoritative...

Is this NAMES for which they are authoritative, or RRSETs (i.e.
name+type+class) for which they are authoritative? In some places the
document implies that a responder 'owns' a name exclusively, for all
types and classes with that name, and in others it seems to assume that
the unit of logical ownership is the RRSET.

[BA] It is NAMES, not RRSETs. That way a host does not have to attempt to
track which RRSETs are in conflict. It can send a uniqueness
verification query for any RRSET and if it gets a response, it
doesn't have to parse the answer section. As a result, the
type and class are not relevant for conflict detection.

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