Subject: Revised resolution to LLMNR Issue 59: Miscellaneous Issues

From: Bernard Aboba <[email-masked]>
Date: Thu, 1 Jan 2004 11:41:54 -0800 (PST)

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

Add Sections 2.1 and 2.1.1:

"2.1.  LLMNR packet format

LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for
both queries and responses.  Although [RFC1035] restricts DNS queries
and responses to 512 octets in length, since LLMNR operates only on the
local link, this restriction is not applicable.  LLMNR implementations
MUST accept 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] and [RFC2535], as illustrated below:

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   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.

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 kind of query in this message.
     This value is set by the originator of a query and copied into the
     response.  LLMNR senders and responders MUST support standard
     queries (opcode value of zero).  LLMNR queries MUST NOT be sent
     with other OPCODE values, and if sent, MUST be ignored by
     responders.

AA   Authoritative Answer. This bit is valid in LLMNR responses, and
     specifies that the responder is an authority for the domain name in
     the question section.  Since responders only respond to LLMNR
     queries for names and addresses they are authoritative for, the AA
     bit MUST be set in LLMNR responses.  If a sender receives a
     response with the header containing the AA bit not set, the sender
     MUST act as though the AA bit was set.  The AA bit MUST NOT be set
     in LLMNR queries, and MUST be ignored by LLMNR 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 a 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
     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.

RD   Recursion Desired.  The RD bit MUST NOT be set in an LLMNR query or
     response.  If a responder receives an LLMNR query with the header
     containing the RD bit set, the responder MUST act as though the RD
     bit was not set.   LLMNR senders MUST ignore the RD bit in LLMNR
     responses.

RA   Recursion Available.  The RA bit MUST NOT be set in an LLMNR query
     or response.  If the RA bit is set in an LLMNR response, it MUST be
     treated by the sender as though it was not set.  LLMNR responders
     MUST ignore the RA bit in LLMNR queries.

Z    Reserved for future use.  MUST be zero in all LLMNR queries and
     responses.  If these bits are set in an LLMNR query or response,
     they MUST be ignored.

AD   Authentic Data.  The AD bit, defined in [RFC3655], MUST NOT be set
     in an LLMNR query or response.  If the AD bit is set in an LLMNR
     query, it MUST be ignored by the responder.  If the AD bit is set
     in an LLMNR response, LLMNR senders MUST act as though the AD bit
     were not set.

CD   Checking Disabled. The CD bit, defined in [RFC2535], MUST NOT be
     set in an LLMNR query or response.  If the CD bit is set in an
     LLMNR query, it MUST be ignored by the responder.  LLMNR senders
     MUST ignore the CD bit in LLMNR responses.

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 RCODE MUST be zero in an
     LLMNR response.  Instead of sending a response with a
     non-zero RCODE, an LLMNR responder MUST NOT respond to a
     query.  A sender receiving an LLMNR response with a
     non-zero RCODE value MUST silently discard the response.

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 ignore
     questions after the first question.

ANCOUNT
     An unsigned 16 bit integer specifying the number of resource
     records in the answer section.

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."

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.

[RFC3655] Wellington, B. and G. Gudmundsson, "Redefinition of the DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.

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