Subject: Proposed Resolution to LLMNR Issue 43: PTR queries and cluster names

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Aug 2003 14:38:15 -0700 (PDT)

The text of LLMNR Issue 43 is enclosed below.  The proposed resolution is
as follows:

In Section 2.3, change:

"b. The sender queries for a PTR RR."

To:

"b. The sender queries for the PTR RR of a fully formed
IP address within the "in-addr.arpa" or "ipv6.arpa" zones."

In Section 4, change:

"The sender MUST anticipate receiving multiple replies to the same LLMNR
query, in the event that several LLMNR enabled computers receive the
query and respond with valid answers. When this occurs, the responses
MAY first be concatenated, and then treated in the same manner that
multiple RRs received from the same DNS server would."

To:

"The sender MUST anticipate receiving multiple replies to the same LLMNR
query, in the event that several LLMNR enabled computers receive the
query and respond with valid answers. When this occurs, the responses
MAY first be concatenated, and then treated in the same manner that
multiple RRs received from the same DNS server would; the sender
perceives no inherent conflict from the receipt of multiple responses."

----------------------------------------------------------------------------
Issue 43: PTR queries and cluster names
Submitter name: Markku Savella
Submitter email address: [email-masked]
Date first submitted: August 4, 2003
Reference:
Document: LLMNR-22
Comment type: T
Priority: S
Section: 2.3, 4
Rationale/Explanation of issue:
2.3. Unicast queries and responses

Unicast queries SHOULD be sent when:

a. A sender repeats a query after it received a response
with the TC bit set to the previous LLMNR multicast query, or

b. The sender queries for a PTR RR.
....
---------------------------------------

Concerning 2.3 (b): How are you supposed to generate a unicast query
out of PTR query, which is NOT "*.in-addr.arpa" or "*.ip6.arpa"?

Thus, the section should be amended to include only PTR queries that
are actually constructed from full IP addresses? Other PTR queries
need to go via normal UDP?

---------------------------------------
....
4. Conflict resolution
....
- 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)
- only a single host may respond to a query for an A or AAAA
type record for a hostname.
....
---------------------------------------

The "cluster name" semantics is unclear to. How does a sender that
queries a name know whether the name is a "hostname" or "cluster
name"? Two choices:

a) it's implicitly a "cluster name", if multiple answers are received
(e.g. there will never be any conflict from sender viewpoint).

b) each host must be configured locally with the list of legal
"cluster names", and sender only accepts multiple answers for these
names.

I assume (a) is intended?

[BA] I agree that a unicast query should only be sent
for PTR RR queries for fully formed IP addresses within
*.in-addr.arpa or *.ipv6.arpa.

And yes, I believe that a name is inherently a cluster name
if multiple answers are received (so there is no conflict
from the sender viewpoint). Of course from the responder
viewpoint, it is different.

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

---

From: Markku Savela <[email-masked]>
Date: Thu, 14 Aug 2003 09:55:45 +0300

> From: Bernard Aboba <[email-masked]>

> IP address within the "in-addr.arpa" or "ipv6.arpa" zones."

You copied my typing error, should be "ip6.arpa" ?