Subject: Proposed resolution to Issue 37: Conflict detection

From: Bernard Aboba <[email-masked]>
Date: Sat, 10 May 2003 19:17:15 -0700 (PDT)

The text of Issue 37 is included below. The proposed resolution is as
follows:

In Section 4, change:

"Where a host is configured to respond to LLMNR queries on more than
one interface, each interface should have its own independent LLMNR
cache. For each UNIQUE resource record in a given interface's
cache..."

To:

"Where a host is configured to respond to LLMNR queries on more than
one interface, each interface should have its own independent LLMNR
resolver cache. For each UNIQUE resource record in a given
interface's configuration, the host MUST verify resource record
uniqueness on that interface..."

In Section 4.1, change:

"If host myhost is configured to use LLMNR on both interfaces, it will
send LLMNR queries on both interfaces.  When host myhost sends a query
for the host RR for name "A" it will receive a response from hosts on
both interfaces.

Host myhost will then forward a response from the first responder to the
second responder, who will attempt to verify the uniqueness of host RR
for its name, but will not discover a conflict, since the conflicting
host resides on a different link. Therefore it will continue using its
name.

Indeed, host myhost cannot distinguish between the situation shown in
Figure 2, and that shown in Figure 3 where no conflict exists."

To:

"If host myhost is configured to use LLMNR on both interfaces, it will
send LLMNR queries on both interfaces.  When host myhost sends a query
for the host RR for name "A" it will receive a response from hosts on
both interfaces.

Host myhost will then send the first responder's response to the
second responder, who will attempt to verify the uniqueness of host RR
for its name, but will not discover a conflict, since the conflicting
host resides on a different link.  Therefore it will continue using its
name.

Host myhost cannot distinguish between the situation shown in
Figure 2, and that shown in Figure 3 where no conflict exists."

-----------------------------------------------------------------
Issue 37: Conflict detection issues
Submitter: Markku Savela
Submitter email address: [email-masked]
Date first submitted: May 8, 2003
Reference: <[email-masked]>
Document: LLMNR-18
Comment type: T
Priority: S
Section: 4
Rationale/Explanation of issue:
In ...

> 4. Conflict resolution
> ...
> Where a host is configured to respond to LLMNR queries on more than
> one interface, each interface should have its own independent LLMNR
> cache. For each UNIQUE resource record in a given interface's
> cache, ...

I have a minor problem with the term "cache" in above. Normally, I
would associate the term "cache" in connection with resolver as a
place to store answers to the queries this node has sent. (And when a
node needs resolve some name, it first would check this cache, and
only do the real query if answer is not already cached).

Above paragraph seems to use "cache" as a place for storing the set
RR's "owned" by this node. A real recursive DNS server might use
cached values in answering queries, but the LLMNR only answers for
explicitly configured names, never for anything it has cached as a
result of a query.

Confused me, at least on first reading. Could perhaps read:

Where a host is configured to respond to LLMNR queries on more than
one interface, each interface should have its own independent LLMNR
configuration. For each UNIQUE resource record in a given
interface's configuration, the host MUST verify resource record
uniqueness on that interface....

> 4.1. Considerations for Multiple Interfaces
> ...
> ---------- ----------
>  |    |      |  |
> [A]   [myhost] [A]
>
>
> Figure 2. Off-segment name conflict

> If host myhost is configured to use LLMNR on both interfaces, it
> will send LLMNR queries on both interfaces. When host myhost sends
> a query for the host RR for name "A" it will receive a response from
> hosts on both interfaces.
>
> Host myhost will then forward a response from the first responder to
> the second responder, who will attempt to verify the uniqueness of
> host RR for its name, but will not discover a conflict, since the
> conflicting host resides on a different link. Therefore it will
> continue using its name.

I think the latter paragraph may be misleading, at least on first
reading I was startled: "Am I supposed to do conflict resolution
across interfaces!!?"

If LLMNR can detect it, it should not do any forwarding, if responses
come from different interfaces. (E.g. in above case, "clever" LLMNR
at "myhost" would not forward the 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/>