Subject: Proposed Resolution of LLMNR Issue 91: Clarifications

From: Bernard Aboba <[email-masked]>
Date: Fri, 15 Jul 2005 20:52:02 -0700 (PDT)

The text of LLMNR issue 91 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, change:

"However, a host configured as a responder MUST act as a
sender to verify the uniqueness of names as described in Section 4."

To:

"However, a host configured as a responder MUST act as a
sender, if only to verify the uniqueness of names as described in Section
4."

Change:

" [2] All attempts to resolve the name via DNS have
failed after exhausting the searchlist. This
can occur because DNS servers did not respond, or
because they responded to DNS queries with RCODE=3
(Authoritative Name Error) or RCODE=0, and an empty
answer section. A dual stack host SHOULD attempt to
reach DNS servers over all protocols on which
DNS server address(es) are configured, prior
to use of LLMNR."

To:

"[2] All attempts to resolve the name via DNS
on all interfaces have failed after
exhausting the searchlist. This can occur
because DNS servers did not respond, or
because they responded to DNS queries with RCODE=3
(Authoritative Name Error) or RCODE=0, and an empty
answer section. A dual stack host SHOULD attempt to
reach DNS servers over all protocols on which
DNS server address(es) are configured, prior
to use of LLMNR."

In Section 2.1.1:

Change:

"In an LLMNR query, the RCODE MUST be zero, and is ignored by the
responder. "

To:

"In an LLMNR query, the sender MUST set RCODE to zero;
the responder ignores the RCODE and assumes it to be zero."

Add to NSCOUNT:

"LLMNR responders MUST silently discard LLMNR queries with NSCOUNT not
equal to zero."

In Section 4.2, change:

"After stopping the use of a name, the responder MAY
elect to configure a new name. However, since name reconfiguration
may be disruptive, this is not required, and a responder may have
been configured to respond to multiple names so that alternative
names may already be available."

To:

"After stopping the use of a name, the responder MAY
elect to configure a new name. However, since name reconfiguration
may be disruptive, this is not required, and a responder may have
been configured to respond to multiple names so that alternative
names may already be available. A host that has stopped the use
of a name may attempt uniqueness verification again after the
expiration of the TTL of the conflicting response."

------------------------------------------------------------------------------
Issue 91: Clarifications
Submitter: Yi Zhao
Submitter email address: [email-masked]
Date first submitted: July 14, 2005
Reference:
Document: LLMNR-40
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Here are some questions.

1. Page 7
Regarding C bit: what happens if in the first response C=1, and in the
second response C=0?
Is a conflict detected with discard as Page 19 suggests?

[BA] Since the first Response is C=1, the sender waits for LLMNR_TIMEOUT.
On receiving the second one, a conflict is detected and the sender resends
the query with the 'C' bit set.  The sender concatenates both responses
together and returns the answer.

2. Page 8
Regarding RCODE:
     In an LLMNR query, the RCODE MUST be zero, and is
     ignored by the responder.
What does ignored mean here? Discard of the query by responder?  If not,
why MUST RCODE be zero?

[BA] Ignored means "act as though the RCODE is zero" in a query.

3. Page 8
Regarding NSCOUNT: what should the responder do to sanity check this?
Should the responder discard the query if the NSCOUNT is not zero as with
ANCOUNT?

[BA] The responder should silently discard the packet.

3.1 Page 9
Regarding ARCOUNT: what should a responder do to sanity check this? Should
responder discard query if C-bit is not set and ARCOUNT is non-zero like
ANCOUNT?
I assume it is only used by responders.

[BA] ARCOUNT may be non-zero even in queries where the 'C' bit is clear.
See section 2.9.

4. Page 5
Regarding configuration:

However, a host configured as a responder MUST act as a
sender to verify the uniqueness of names as described in Section 4.
It does not mean the host must resolve names as a sender, right?  The host
could be configured as a responder but send queries to verify uniqueness.

[BA] Yes. It should say "MUST act as a sender, if only to verify the
uniqueness of names as described in Section 4."

5. Page 5
Regarding when LLMNR is used. As a failover method, how do we define a
failure in DNS? If I received any records, it is not a failure, right? Is
it possible to receive records from one DNS server on one interface, but
fail on another interface? Can we say that response from any DNS server is
complete for all interfaces and protocols?
I am just not clear here.

[BA] Yes, if RRs are received from any DNS server on any interface or
protocol then LLMNR should not be used.

6. Page 19:
Regarding conflict detection and defense:
Is that a MUST or SHOULD for the sender to send back notification? Is that
a "MAY"?

[BA] It is a SHOULD in Section 4.2:

" In order to enable ongoing detection of name conflicts, when an LLMNR
sender receives multiple LLMNR responses to a query, it MUST check if
the 'C' bit is clear in any of the responses. If so, the sender
SHOULD send another query for the same name, type and class, this
time with the 'C' bit set, with the potentially conflicting resource
records included in the additional section."

7. Page 18 & 19:
Regarding conflict detection:
If the host finds a conflict and stops answering queries for its name, how
can the host enable itself again since it has no clue if the conflicting
host is still present?

[BA] The host can continue to answer queries for non-conflicting names and
also can do uniqueness verification again, if any of the events described
in section 4.1 occur.  After the TTL of the conflicting RR expires, the
host can also attempt uniqueness verification again.

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