Subject: Proposed Resolution of LLMNR Issue 45: Handling of Unqualified Names

From: Bernard Aboba <[email-masked]>
Date: Sat, 13 Sep 2003 04:11:56 -0700 (PDT)

The text of Issue 45 is enclosed below.  The proposed fix is as follows:

In Section 2.1, change:

"An LLMNR sender MAY send a request for any name."

To:

"Section 3 describes the circumstances in which LLMNR requests may be
sent."

In Section 3, change:

 "LLMNR is a peer-to-peer name resolution protocol that is not intended as
 a replacement for DNS. By default, LLMNR requests SHOULD be sent only
 when no manual or automatic DNS configuration has been performed, when
 DNS servers do not respond, or when they respond to a query with RCODE=3
 (Authoritative Name Error) or RCODE=0, and an empty answer section.

 As noted in [DNSPerf], even when DNS servers are configured, a
 significant fraction of DNS queries do not receive a response, or result
 in negative responses due to missing inverse mappings or NS records that
 point to nonexistent or inappropriate hosts. Given this, support for
 LLMNR as a secondary name resolution mechanism has the potential to
 result in a large number of inappropriate queries without the following
 additional restrictions:

 [1] If a DNS query does not receive a response, prior to falling
 back to LLMNR, the query SHOULD be retransmitted at least
 once.

 [2] Where a DNS server is configured, by default a sender
 SHOULD send LLMNR queries only for names that are either
 unqualified or exist within the default domain. Where no
 DNS server is configured, an LLMNR query MAY be sent for
 any name.

 [3] A responder with both link-local and routable addresses
 MUST respond to LLMNR queries for A/AAAA RRs only with
 routable address(es). This encourages use of routable
 address(es) for establishment of new connections.

 [4] A sender SHOULD send LLMNR queries for PTR RRs
 via unicast, as specified in Section 2.3."

To:

"LLMNR is a peer-to-peer name resolution protocol that is not intended as
 a replacement for DNS. By default, LLMNR requests SHOULD be sent only
 when no manual or automatic DNS configuration has been performed, when
 DNS servers do not respond, or when they respond to a query with RCODE=3
 (Authoritative Name Error) or RCODE=0, and an empty answer section.
 An LLMNR sender may send a request for any name.

 As noted in [DNSPerf], even when DNS servers are configured, a
 significant fraction of DNS queries do not receive a response, or result
 in negative responses due to missing inverse mappings or NS records that
 point to nonexistent or inappropriate hosts. Given this, support for
 LLMNR as a secondary name resolution mechanism has the potential to
 result in a large number of inappropriate queries without the following
 additional restrictions:

 [1] If a DNS query does not receive a response, prior to falling
 back to LLMNR, the query SHOULD be retransmitted at least
 once.

 [2] A responder with both link-local and routable addresses
 MUST respond to LLMNR queries for A/AAAA RRs only with
 routable address(es). This encourages use of routable
 address(es) for establishment of new connections.

 [3] A sender SHOULD send LLMNR queries for PTR RRs
 via unicast, as specified in Section 2.3."

 Change section 3.1, from:

 "The same host MAY use LLMNR queries for the resolution of unqualified
 host names, and conventional DNS queries for resolution of other DNS
 names.

 If a name is not qualified and does not end in a trailing dot, for the
 purposes of LLMNR, the implicit search order is as follows:

 [1] Request the name with the current domain appended.
 [2] Request just the name.

 This is the behavior suggested by [RFC1536]. LLMNR uses this technique
 to resolve unqualified host names."

 To:

 "If a name is not qualified, for the purposes of LLMNR, the implicit
search order is as follows:

 [1] Request the name with the current domain appended.
 [2] Request the name with the root domain (".") appended.

This is the behavior suggested by [RFC1536]."

--------------------------------------------------------------
Issue 45: Handling of Unqualified Names
 Submitter name: Stuart Cheshire
 Submitter email address: [email-masked]
 Date first submitted: August 24, 2003
 Reference:
 Document: LLMNR-22
 Comment type: T
 Priority: S
 Section: Various
 Rationale/Explanation of issue:

 >Today, with the rise of home networking, there are an increasing number
 >of ad-hoc networks operating without a Domain Name System (DNS) server.

 I think this is side-stepping the real issue. The real issue is:

 >Today, with the rise of home networking, there are an increasing number
 >of home users who do not have ownership of any part of the name space
 >in which they can assign names.

 The whole section talking about "unqualified names" seems to be skirting
 around this issue without being willing to face it head-on and tackle it.
 Section 3.1 says:

>3.1. Unqualified names
 >
 >The same host MAY use LLMNR queries for the resolution of unqualified
 >host names, and conventional DNS queries for resolution of other DNS
 >names.
 >
 >If a name is not qualified and does not end in a trailing dot, for the
 >purposes of LLMNR, the implicit search order is as follows:
 >
 >[1] Request the name with the current domain appended.
 >[2] Request just the name.

 You can't "request just the name". There is no way to represent an
 unqualified name ("no trailing dot") in the DNS packet format. What you
 mean is:

 >[1] Request the name with the current domain appended.
 >[2] Request the name with the root domain (".") appended.

 What this means is that if a home user calls their TV "tv", and their FM
 radio receiver "fm", and their CD player "cd", their computer is going to
 be sending queries for the TLDs "tv.", "fm." and "cd." (Tuvalu, Federal
 State of Micronesia, and Democratic Republic of the Congo, respectively.)

 This seems like it invites chaotic uncontrolled pollution of the
 top-level name space.

 [BA] I assume you are referring to DNS queries for "tv." Presumably there
 is no harm in allowing LLMNR queries for this. The draft allows a host to
 resolve queries for unqualified names only via LLMNR, so this can be
 avoided. Are you suggesting that this behavior be recommended?

 Furthermore, because there is no way to represent an unqualified name in
 the DNS packet format, there is also no way to represent an unqualified
 name on the right-hand-side of a PTR, CNAME or SRV record. This means
 that if you do a LLMNR query for an SRV record with an "unqualified"
 name, what you get back is an SRV record containing a target host name
 that you can't use with LLMNR because it's not an "unqualified" name.

 [BA] Agreed. This should be fixed.

 >3.1. Unqualified names
 >
 >The same host MAY use LLMNR queries for the resolution of unqualified
 >host names

 Who makes the choice offered by that "MAY"? User? OS vendor? Application
 writer?

 [BA] The LLMNR implementation.

 >If a name is not qualified and does not end in a trailing dot,

 What does that mean? Do "fully qualified" and "ends in a trailing dot"
 mean the same thing, or is there a difference?

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