Subject: Some comments on draft-ietf-dnsext-mdns-18.txt

From: Markku Savela <[email-masked]>
Date: Thu, 8 May 2003 16:47:56 +0300

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 responces
come from different interfaces. (E.g. in above case, "clever" LLMNR
at "myhost" would not forward the responce!).

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