Subject: LLMNR Issue 98: Usage Restrictions

From: Bernard Aboba <[email-masked]>
Date: Mon, 29 Aug 2005 21:55:19 -0700 (PDT)

LLMNR Issue 98 (Usage Restrictions) was submitted in IETF Last Call.  The 
text of the issue is enclosed below. 

The proposed resolution is as follows:

In section 2 change:

" An LLMNR sender MAY send a query for any name. By default, LLMNR
requests SHOULD NOT be sent unless one of these conditions are met:

[1] No manual or automatic DNS configuration has been performed.
If DNS server address(es) have been configured, then LLMNR
SHOULD NOT be used as the primary name resolution mechanism,
although it MAY be used as a secondary name resolution
mechanism. A dual stack host SHOULD attempt to reach DNS
servers overall protocols on which DNS server address(es) are
configured, prior to sending LLMNR queries. For dual stack
hosts configured with DNS server address(es) for one protocol
but not another, this inplies that DNS queries SHOULD be sent
over the protocol configured with a DNS server, prior to
sending LLMNR queries.

[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. Where a
single resolver call generates DNS queries for A and AAAA RRs,
an implementation MAY choose not to send LLMNR queries if any
of the DNS queries is successful. An LLMNR query SHOULD only
be sent for the originally requested name; the DNS searchlist
is not used to from additional LLMNR queries.

A typical sequence of events for LLMNR usage is as follows:

[a] DNS servers are not configured or attempts to resolve the
name via DNS have failed, after exhausting the searchlist.

[b] An LLMNR sender sends an LLMNR query to the link-scope
multicast address(es), unless a unicast query is indicated.
A sender SHOULD send LLMNR queries for PTR RRs via unicast,
as specified in Section 2.4.

[c] A responder responds to this query only if it is authoritative
for the domain name in the query. A responder responds to a
multicast query by sending a unicast UDP response to the sender.
Unicast queries are responded to as indicated in Section 2.4.

[d] Upon reception of the response, the sender processes it.

The sections that follow provide further details on sender and
responder behavior."

To:

"By default, LLMNR queries MAY be sent only when one of the following
conditions are met:"

[1] No manual or automatic DNS configuration has been performed.
If DNS server address(es) have been configured, then LLMNR
SHOULD NOT be used as the primary name resolution mechanism,
although it MAY be used as a secondary name resolution
mechanism. A dual stack host SHOULD attempt to reach DNS
servers overall protocols on which DNS server address(es) are
configured, prior to sending LLMNR queries. For dual stack
hosts configured with DNS server address(es) for one protocol
but not another, this inplies that DNS queries SHOULD be sent
over the protocol configured with a DNS server, prior to
sending LLMNR queries.

[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. Where a
single resolver call generates DNS queries for A and AAAA RRs,
an implementation MAY choose not to send LLMNR queries if any
of the DNS queries is successful. An LLMNR query SHOULD only
be sent for the originally requested name; a searchlist
is not used to form additional LLMNR queries.

Note: While these conditions are necessary for sending an LLMNR
query, they are not sufficient.  While an LLMNR sender MAY send
a query for any name, it also MAY impose additional conditions on
sending LLMNR queries.  A sender configured with a DNS server MAY
choose to send LLMNR queries only for unqualified names and for
fully qualified domain names within configured zones.

A typical sequence of events for LLMNR usage is as follows:

[a] DNS servers are not configured or attempts to resolve the
name via DNS have failed, after exhausting the searchlist.
Also, the name to be queried satisfies the
restrictions imposed by the implementation.

[b] An LLMNR sender sends an LLMNR query to the link-scope
multicast address(es), unless a unicast query is indicated,
as specified in Section 2.4.

[c] A responder responds to this query only if it is authoritative
for the domain name in the query. A responder responds to a
multicast query by sending a unicast UDP response to the sender.
Unicast queries are responded to as indicated in Section 2.4.

[d] Upon reception of the response, the sender processes it.

The sections that follow provide further details on sender and
responder behavior."

---------------------------------------------------------------------------
Issue 98: Usage Restrictions
Submitter: Dave Thaler
Submitter email address: [email-masked]
Date first submitted: August 18, 2005
Reference:
Document: LLMNR-42
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue: 

Section 2 describes the conditions under which LLMNR queries MAY be
sent. However, these conditions are necessary but are not sufficient;
an LLMNR sender is NOT REQUIRED to send LLMNR queries if the conditions
are satisfied. The specification needs to clarify this point.

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