Proposed Resolution to LLMNR Issue 37: Conflict Detection Issues

Proposed Resolution to LLMNR Issue 37: Conflict Detection Issues

Post by Brad Hard » Sat, 10 May 2003 17:19:40



=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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

I'd actually prefer to see a behavioural description, rather than something=
=20
that pre-supposes a particular implementation. That is, something of the=20
form:
If a Host is configured to respond to LLMNR queries on more than one=20
interface, queries to an interface (must / must not) have X effect on repli=
es=20
to other interfaces.

Brad

BTW: I assume that "interface" means "logical interface" if we have 801.1q=
=20
VLAN in operation.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+u2SdW6pHgIdAuOMRAvDpAKCGFKzeuHrzApZOkmcSUx8mrwJthgCfbQIS
IlFDaNnQ7LfzbRvtYUnJvf8=3D
=3DDgSD
=2D----END PGP SIGNATURE-----

--

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

 
 
 

Proposed Resolution to LLMNR Issue 37: Conflict Detection Issues

Post by Bernard Abob » Sat, 10 May 2003 09:38:50


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

Date first submitted: May 8, 2003

Document: LLMNR-18
Comment type: T
Priority: S
Section: 4
Rationale/Explanation of issue:
In ...

Quote:> 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....

Quote:> 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!).

--

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