Subject: Proposed Resolution to Issue 78: UNIQUEness Probing

From: Bernard Aboba <[email-masked]>
Date: Sat, 19 Feb 2005 17:45:22 -0800 (PST)

The text of Issue 78, raised by Thomas Narten during the AD review, is
available here:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue%2078

A version of the document incorporating the proposed resolution is
available here:
http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-38c.txt

The proposed resolution is as follows:

Change the first part of Section 2.1.1 to:

"2.1.1. LLMNR header format

LLMNR queries and responses utilize the DNS header format defined in
[RFC1035] with exceptions noted 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   | Z|TC| U| C| 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. For advice on generation of pseudo-random values, please
consult [RFC1750].

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 in an LLMNR response,
then the sender SHOULD 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.

U UNIQUE - specifies that this message is a UNIQUEness query. The U
bit MUST NOT be set in an LLMNR response, and if set is ignored by
an LLMNR sender. If the U bit is set in an LLMNR query, this
indicates that the sender believes that it is authoritative for the
name. See Section 4.1 and 4.2 for discussion of name conflict
detection.

C Conflict - specifies that a sender has previously received multiple
LLMNR responses to this query. The C bit MUST NOT be set in an
LLMNR response, and if set is ignored by an LLMNR sender.
Responders do not respond to LLMNR queries with the 'C' bit set;
since no response is expected, LLMNR senders do not retransmit.

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

In Section 2.3, change:

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

To:

"[c] Responders MUST respond to LLMNR queries for names and addresses
they are authoritative for. This applies to both forward and reverse
lookups, with
the exception of queries with the 'C' bit set, which do not elicit a
response."

In Section 2.7, change:

"If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
then a sender SHOULD repeat the transmission of the query in order to
assure that it was received by a host capable of responding to it.
Retransmission of UDP queries SHOULD NOT be attempted more than 3
times. Where LLMNR queries are sent using TCP, retransmission is
handled by the transport layer."

To:

"If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
then a sender SHOULD repeat the transmission of the query in order to
assure that it was received by a host capable of responding to it.
Retransmission of UDP queries SHOULD NOT be
attempted more than 3 times. Where LLMNR queries are sent using
TCP, retransmission is handled by the transport layer.
Queries with the 'C' bit set MUST be sent over UDP and MUST NOT be
retransmitted."

In Section 2.9, change:

" In LLMNR, the additional section is only intended for use by EDNS0,
TSIG and SIG(0). As a result, senders MAY only include pseudo RR-
types in the additional section of a query; responders MUST ignore
the additional section of queries containing other RR types."

To:

"In LLMNR, the additional section is primarily intended for use by EDNS0,
TSIG and SIG(0). As a result, unless the 'C' bit is set,
senders MAY only include pseudo RR-types in the additional section
of a query; unless the 'C' bit is set, responders MUST ignore the
additional section of queries containing other RR types.

In queries where the 'C' bit is set, the sender SHOULD include
the conflicting RRs in the additional section. Since conflict
notifications are advisory, responders SHOULD log information
from the additional section, but otherwise MUST ignore the
additional section."

Change Section 4 and 4.1 to the following:

"4. Conflict resolution

The uniqueness of a resource record depends on the nature of the name
in the query and type of the query. For example it is expected that:

- multiple hosts may respond to a query for an SRV type record
- multiple hosts may respond to a query for an A or AAAA type
record for a cluster name (assigned to multiple hosts in
the cluster)
- only a single host may respond to a query for an A or AAAA
type record for a name.

By default, a responder SHOULD be configured to behave as though all
RRs are UNIQUE on each interface on which LLMNR is enabled.

When name conflicts are detected, they SHOULD be logged. To detect
duplicate use of a name, an administrator can use a name resolution
utility which employs LLMNR and lists both responses and responders.
This would allow an administrator to diagnose behavior and
potentially to intervene and reconfigure LLMNR responders who should
not be configured to respond to the same name.

4.1. Uniqueness Verification

Prior to including a UNIQUE resource record in a response, for each
UNIQUE resource record in a given interface's configuration, the host
MUST verify that there is no other host within the scope of LLMNR
query propagation that can return a resource record for the same
name, type and class on that interface.

Once a responder has verified the uniqueness of a UNIQUE resource
record, if it receives an LLMNR query for that resource record,
with the 'C' bit clear, it MUST respond.

Uniqueness verification is carried out when the host:

- starts up or is rebooted
- wakes from sleep (if the network interface was inactive
during sleep)
- is configured to respond to LLMNR queries on an interface
enabled for transmission and reception of IP traffic
- is configured to respond to LLMNR queries using additional
UNIQUE resource records
- verifies the acquisition of a new IP address and configuration
on an interface

To verify uniqueness, a responder MUST send an LLMNR query with the
'U' bit set for each UNIQUE resource record. If no response is
received, the sender retransmits the query, as specified in Section
2.7. If a response is received, the responder MUST NOT use the
UNIQUE resource record in response to LLMNR queries.

Periodically carrying out uniqueness verification in an attempt to
detect name conflicts is not necessary, wastes network bandwidth, and
may actually be detrimental. For example, if network links are
joined only briefly, and are separated again before any new
communication is initiated, temporary conflicts are benign and no
forced reconfiguration is required. Triggering a reconfiguration in
this case would not serve any useful purpose. LLMNR responders
SHOULD NOT periodically attempt uniqueness verification.

4.2. Conflict Detection and Defense

Hosts on disjoint network links may configure the same name for use
with LLMNR. If these separate network links are later joined or
bridged together, then there may be multiple hosts which are now on
the same link, trying to use the same name.

There are several mechanisms by which ongoing name conflicts may
be detected.

[a] Receipt of a query with the 'U' bit set. Whenever an LLMNR
responder receives an LLMNR query for a UNIQUE resource record
with the 'U' bit set, if the source IP address does not match
an IP address configured on that interface, this indicates a
conflict.

[b] Conflict notification queries. When an LLMNR sender
receives multiple LLMNR responses to a query, it MUST send another
query for the same resource record, this time with the 'C' bit set,
with the answers received included in the Additional section.

Queries with the 'C' bit set are considered advisory and responders
MUST verify the existence of a conflict by other means before acting
on it. A responder receiving a query with the 'C' bit set MUST NOT
respond.
If the resource record is not UNIQUE, then the responder MUST ignore
the query. If the resource record is UNIQUE, then the responder
MUST send its own query for the same resource record, with the
'U' bit set. If a response is received, or if a query with the
'U' bit set is received, then a conflict has been detected.

An LLMNR responder MUST NOT ignore conflicts once detected. An
LLMNR responder MUST respond to a conflict as
described in either [1] or [2] below:

[1] Upon detecting a conflict, an LLMNR responder MAY elect to
immediately stop using the conflicting UNIQUE resource record in
response to LLMNR queries.

The responder MAY also elect to configure a new name. However,
since name reconfiguration may be disruptive, this is not required,
and a responder may have been configured to respond to multiple
names so that alternative names may already be available.

[2] If a responder currently has reasons to prefer using the name, and
it has not seen any other conflicting LLMNR queries within the last
DEFEND_INTERVAL seconds, then it MAY elect to defend its name, by
recording the time that the conflicting LLMNR query was received,
and then sending a query for the UNIQUE resource record,
with the 'U' bit set if it had not already done so (e.g. if had
not already sent such a UNIQUEness query as part of the UNIQUEness
verification process).

Having done this, an LLMNR responder can then continue to use the
name normally without any further special action. However, if this
is not the first conflicting LLMNR query the responder has seen,
and the time recorded for the previous conflicting LLMNR query is
recent, within DEFEND_INTERVAL, then the LLMNR responder MUST
immediately cease using the conflicting resource records.

This is necessary to ensure that two hosts do not get stuck in an
endless loop with both hosts trying to defend the same name."

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