Subject: Proposed resolution to LLMNR Issue 86: NITs

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Jul 2005 00:18:24 -0700 (PDT)

The text of LLMNR Issue 86 is enclosed below.  This and other LLMNR Issues
are tracked on the LLMNR web site:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

The proposed resolution is as follows:

In Section 2.1, change:

"LLMNR implementations MUST
accept UDP queries and responses as large as the smaller of the link
MTU or 8192 octets."

To:

"LLMNR implementations MUST
accept UDP queries and responses as large as the smaller of the link
MTU or 9000 octets."

In Section 2.1.1, change:

"T Tentative. The 'T'entative bit is set in a response if the
responder is authoritative for the name, but has not yet verified
the uniqueness of one or more of the resource record(s) in the
answer section. A responder MUST ignore the 'T' bit in a query, if
set. When a response with the 'T' bit set is received in response
to a uniqueness query, a conflict has been detected and a responder
MUST resolve the conflict as described in Section 4.1."

To:

"T Tentative. The 'T'entative bit is set in a response if the
responder is authoritative for the name, but has not yet verified
the uniqueness of one or more of the resource record(s) in the
answer section. A responder MUST ignore the 'T' bit in a query, if
set. If a uniqueness query elicits a response with the 'T' bit set,
a conflict has been detected and a responder MUST resolve the conflict
as described in Section 4.1. Otherwise, a response with the 'T' bit
set is silently discarded by the sender."

In Section 2.1.1, change:

"If an LLMNR responder is authoritative for the name in a multicast
query, but an error is encountered, the responder SHOULD send an
LLMNR response with an RCODE of zero, no RRs in the answer section,
and the TC bit set. This will cause the query to be resent using
TCP, and allow the inclusion of a non-zero RCODE in the response to
the TCP query. Responding with the TC bit set is preferable to not
sending a response, since it enables errors to be diagnosed."

To:

"If an LLMNR responder is authoritative for the name in a multicast
query, but an error is encountered, the responder SHOULD send an
LLMNR response with an RCODE of zero, no RRs in the answer section,
and the TC bit set. This will cause the query to be resent using
TCP, and allow the inclusion of a non-zero RCODE in the response to
the TCP query. Responding with the TC bit set is preferable to not
sending a response, since it enables errors to be diagnosed. Errors
include those defined in [RFC2845], such as BADSIG(16), BADKEY(17)
and BADTIME(18)."

In Section 2.3, change:

"An SOA RR is synthesized only when a
responder has another RR as well; the SOA RR MUST NOT be the only RR
that a responder has."

To:

"An SOA RR is synthesized only when a
responder has another RR in addition to an SOA RR;
the SOA RR MUST NOT be the only RR
that a responder has."

In Section 4.1, change:

" If no response is received, the sender retransmits the query, as
specified in Section 2.7. If a response is received with the 'T' bit
clear, the responder MUST NOT use the name in response to LLMNR
queries received over any protocol (IPv4 or IPv6). If a response is
received with the 'T' bit set, the responder MUST check if the source
IP address in the response, interpreted as an unsigned integer, is
less than the source IP address in the query."

To:

" If no response is received, the sender retransmits the query, as
specified in Section 2.7. If a response is received, the sender
MUST check if the source address matches the address of any of its
interfaces; if so, then the response is not considered a conflict,
since it originates from the sender.

If a response is received with the 'T' bit clear, the responder
MUST NOT use the name in response to LLMNR queries
received over any protocol (IPv4 or IPv6). If a response is
received with the 'T' bit set, the responder MUST check if the source
IP address in the response, interpreted as an unsigned integer, is
less than the source IP address in the query."

-----------------------------------------------------------------------------------
Issue 86: NITs
Submitter: Stuart Cheshire
Submitter email address: [email-masked]
Date first submitted: May 25, 2005
Reference:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00984.html
Document: LLMNR-40
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
Some other general comments and questions:

   LLMNR implementations MUST
   accept UDP queries and responses as large as the smaller of the link
   MTU or 8192 octets.

I suggest 9000 bytes, the Ethernet jumbo frame size, as a natural packet
size to pick. Allowing 40 bytes for IPv6 header and 8 for UDP header,
that leaves 8952 for the DNS message, which allows for an 8K resource
record to be carried (should such a thing ever be needed in future).

[BA] OK.

   T Tentative.  The 'T'entative bit is set in a response if the
     responder is authoritative for the name, but has not yet verified
     the uniqueness of one or more of the resource record(s) in the
     answer section.  A responder MUST ignore the 'T' bit in a query, if
     set.  When a response with the 'T' bit set is received in response
     to a uniqueness query, a conflict has been detected and a responder
     MUST resolve the conflict as described in Section 4.1.

The document says nothing about how response with the 'T' bit set are to
be interpreted by senders. Should they be ignored, or used in answer to
the question?

[BA] If a sender receives a response to a normal query with the 'T' bit
set, the response is ignored.

     If an LLMNR responder is authoritative for the name in a multicast
     query, but an error is encountered, the responder SHOULD send an
     LLMNR response with an RCODE of zero, no RRs in the answer section,
     and the TC bit set.

What kind of error is this anticipating? Either the responder knows the
answer, or it does not. Some example of a plausible error would motivate
this section.

[BA] Examples include error codes sent in response to TSIG queries.
   Upon configuring an IP address, responders typically will synthesize
   corresponding A, AAAA and PTR RRs so as to be able to respond to
   LLMNR queries for these RRs.  An SOA RR is synthesized only when a
   responder has another RR as well

Another RR in addition to A, AAAA and PTR?

[BA] Another RR in addition to SOA.
   If no response is received, the sender retransmits the query, as
   specified in Section 2.7.  If a response is received with the 'T' bit
   clear, the responder MUST NOT use the name in response to LLMNR
   queries received over any protocol (IPv4 or IPv6).  If a response is
   received with the 'T' bit set, the responder MUST check if the source
   IP address in the response, interpreted as an unsigned integer, is
   less than the source IP address in the query.

This suffers from auto-immune response, in the case where a machine has
both Ethernet and wireless connections, and (unknown to the machine) the
Ethernet and wireless networks are bridged together.

[BA] Right. The check need only be done if the source address is
different than the address of one of the host's interfaces.

--
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: Bernard Aboba <[email-masked]>
Date: Tue, 19 Jul 2005 06:48:48 -0700 (PDT)

Here is a revised resolution:

In Section 2.1, change:

To:

"LLMNR implementations MUST
accept UDP queries and responses as large as the smaller of the link
MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
octets for the header, VLAN tag and CRC)."

To:

To:

In Section 2.3, change:

To:

In Section 4.1, change:

To: