Subject: Proposed resolution to LLMNR Issue 59: Miscellaneous Issues

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Jan 2004 08:19:56 -0800 (PST)

The text of LLMNR Issue 59 is enclosed below.

The proposed fix is as follows:'

In Section 2.2, change:

"In conventional DNS terminology a DNS server authoritative for a zone is
authoritative for all the domain names under the zone root except for
the branches delegated into separate zones. Contrary to conventional
DNS terminology, an LLMNR responder is authoritative only for the zone
root."

To:

"In conventional DNS terminology a DNS server authoritative for a zone is
authoritative for all the domain names under the zone apex except for
the branches delegated into separate zones. Contrary to conventional
DNS terminology, an LLMNR responder is authoritative only for the zone
apex."

In Section 2.2, change:

"Responders SHOULD respond to LLMNR queries for names and addresses
they are authoritative for. This applies to both forward and
reverse lookups."

To:

"Responders MUST respond to LLMNR queries for names and addresses
they are authoritative for. This applies to both forward and
reverse lookups."

Add the following paragraph to Section 2.2:

"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; the SOA RR MUST NOT be the only
RR that a responder has.

However, in general whether RRs are manually or
automatically created is an implementation decision."

Change Section 2.7 from:

"The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response. A default value of 0 is
recommended in highly dynamic environments (such as mobile ad-hoc
networks). In less dynamic environments, LLMNR traffic can be reduced
by setting the TTL to a higher value.

Due to the TTL minimalization necessary when caching an RRset, all TTLs
in an RRset MUST be set to the same value."

To:

"The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response. A default value of 30 seconds
is RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
networks), the TTL value may need to be reduced.

Due to the TTL minimalization necessary when caching an RRset, all TTLs
in an RRset MUST be set to the same value."

Add the following section:

"2.1. LLMNR packet format

LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for
both queries and responses.  LLMNR implementations SHOULD send UDP
queries and responses only as large as are known to be permissible
without causing fragmentation.  When in doubt a maximum packet size of
512 octets SHOULD be used.  LLMNR implementations MUST accept UDP
queries and responses as large as permitted by the link MTU.

2.1.1. LLMNR header format

LLMNR queries and responses utilize the DNS header format defined in
[RFC1035] with exceptions noted below:

  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  | Z|TC| Z| Z| Z| Z| Z|   RCODE   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:

ID   A 16 bit identifier assigned by the program that generates any kind
     of query.  This identifier is copied from the query to the response
     and can be used by the sender to match responses to outstanding
     queries. The ID field in a query SHOULD be set to a pseudo-random
     value.

QR   A one bit field that specifies whether this message is an LLMNR
     query (0), or an LLMNR response (1).

OPCODE
     A four bit field that specifies the kind of query in this message.
     This value is set by the originator of a query and copied into the
     response.  This specification defines the behavior of standard
     queries and responses (opcode value of zero).  Future
     specifications may define the use of other opcodes with LLMNR.
     LLMNR senders and responders MUST support standard queries (opcode
     value of zero).  LLMNR queries with unsupported OPCODE values MUST
     be silently discarded by responders.

TC   TrunCation - specifies that this message was truncated due to
     length greater than that permitted on the transmission channel.
     The TC bit MUST NOT be set in an LLMNR query and if set is ignored
     by an LLMNR responder.  If the TC bit is set an LLMNR response,
     then the sender MAY use the response if it contains all necessary
     information, or the sender MAY discard the response and resend the
     LLMNR query over TCP using the unicast address of the responder as
     the destination address.  See  [RFC2181] and Section 2.4 of this
     specification for further discussion of the TC bit.

Z    Reserved for future use.  Implementations of this specification
     MUST set these bits to zero in both queries and responses.  If
     these bits are set in a LLMNR query or response, implementations of
     this specification MUST ignore them.  Since reserved bits could
     conceivably be used for different purposes than in DNS,
     implementors are advised not to enable processing of these bits in
     an LLMNR implementation starting from a DNS code base.

RCODE
     Response code -- this 4 bit field is set as part of LLMNR
     responses.  In an LLMNR query, the RCODE MUST be zero, and is
     ignored by the responder.  The response to a multicast LLMNR query
     MUST have RCODE set to zero.  A sender MUST silently discard an
     LLMNR response with a non-zero RCODE sent in response to a
     multicast query.

     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 preferrable to
     not sending a response, since it enables errors to be diagnosed.

     Since LLMNR responders only respond to LLMNR queries for names for
     which they are authoritative, LLMNR responders MUST NOT respond
     with an RCODE of 3; instead, they should not respond at all.

     LLMNR implementations MUST support EDNS0 [RFC2671] and extended
     RCODE values.

QDCOUNT
     An unsigned 16 bit integer specifying the number of entries in the
     question section. A sender MUST place only one question into the
     question section of an LLMNR query.  LLMNR responders MUST silently
     discard LLMNR queries with QDCOUNT not equal to one.  LLMNR senders
     MUST silently discard LLMNR responses with QDCOUNT not equal to
     one.

ANCOUNT
     An unsigned 16 bit integer specifying the number of resource
     records in the answer section.  LLMNR responders MUST silently
     discard LLMNR queries with ANCOUNT not equal to zero.

NSCOUNT
     An unsigned 16 bit integer specifying the number of name server
     resource records in the authority records section.  Authority
     record section processing is described in Section 2.9.

ARCOUNT
     An unsigned 16 bit integer specifying the number of resource
     records in the additional records section.  Additional record
     section processing is described in Section 2.9."

Delete the following sentence from Section 2.2:

"An LLMNR query is composed in exactly the same manner and with the same
packet format as a DNS query. "

Delete the following sentence from Section 2.3:

"A response to an LLMNR query is composed in exactly the same manner and
with the same packet format as a response to a DNS query. "

Add the following to the IANA considerations section 6:

"This specification creates one new name space:  the reserved bits in the
LLMNR header.  These are allocated by IETF Consensus, in accordance with
BCP 26 [RFC2434]."

Add the following to the normative reference section:

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
RFC 2181, July 1997.

[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.

[RFC2845] Vixie, P., et al., "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, May 2000.

[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
2930, September 2000.

[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
December 2001.

--------------------------------------------------------------------------
Issue 59: Miscellaneous Issues
Submitter name: Olafur Gudmundsson
Submitter email address: [email-masked]
Date first submitted: December 17, 2003
Reference:
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02305.html
Document: LLMNR-27
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

The draft could benefit from addition of a section gathering
in one place all the requirements relating to the use of the
DNS packet format for LLMNR. For example, use of the TC bit
is not defined and neither are the AD and CD bits (which I
assume are set to zero).

In Section 2.2, change:

"In conventional DNS terminology a DNS server authoritative for a zone is
authoritative for all the domain names under the zone root except for
the branches delegated into separate zones. Contrary to conventional
DNS terminology, an LLMNR responder is authoritative only for the zone
root."

To:

"In conventional DNS terminology a DNS server authoritative for a zone is
authoritative for all the domain names under the zone appex except for
the branches delegated into separate zones. Contrary to conventional
DNS terminology, an LLMNR responder is authoritative only for the zone
appex."

In Section 2.2, change:

"Responders SHOULD respond to LLMNR queries for names and addresses
they are authoritative for. This applies to both forward and
reverse lookups."

To:

"Responders MUST respond to LLMNR queries for names and addresses
they are authoritative for. This applies to both forward and
reverse lookups."

Add the following paragraph to Section 2.2:

"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; the SOA RR MUST NOT be the only
RR that a responder has.

However, in general whether RRs are manually or
automatically created is an implementation decision."

Change Section 2.7 from:

"The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response. A default value of 0 is
recommended in highly dynamic environments (such as mobile ad-hoc
networks). In less dynamic environments, LLMNR traffic can be reduced
by setting the TTL to a higher value.

Due to the TTL minimalization necessary when caching an RRset, all TTLs
in an RRset MUST be set to the same value."

To:

"The responder should use a pre-configured TTL value in the records
returned in the LLMNR query response. A default value of 30 seconds
is RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
networks), the TTL value may need to be reduced.

Due to the TTL minimalization necessary when caching an RRset, all TTLs
in an RRset MUST be set to the same value."

--
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: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 20 Jan 2004 11:48:00 -0500

>The text of LLMNR Issue 59 is enclosed below.

I agree that the changes below address all the issues raised by me
on this ticket.

         Olafur