Subject: Proposed Resolution of LLMNR Issue #42: Authority and additional section processing

From: Bernard Aboba <[email-masked]>
Date: Mon, 21 Jul 2003 15:05:43 -0700 (PDT)

The text of Issue #42 is enclosed below.  In my opinion, the changes are
compelling, and I would like to propose that they be accepted.  Any
objections?

A version of the draft with the changes applied is available at:
http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-22.txt

-------------------------------------------------------------------------
Issue 42: Authority and additional section processing
Submitter name: Andreas Gustafsson
Submitter email address: [email-masked]
Date first submitted: July 14, 2003
Reference:
Document: LLMNR-21
Comment type: T
Priority: S
Section: 2.3, 2.7
Rationale/Explanation of issue:

The mdns draft is vague when it comes to how the authority and
additional sections of the DNS(-like) message are used. These
sections have well-known and well-defined uses in the DNS protocol,
but it is far from clear that these are relevant to and appropriate
for LLMNR.

In particular, section 2.3 currently says:

Unicast queries SHOULD be sent when:
[...]
b. The sender's LLMNR cache contains an NS resource record that
enables the sender to send a query directly to the hosts

I have several issues with this:

1. Responder behavior

The above text seems to assume that responders have NS records and
glue address records associated with them and include them in
responses. The following text in section 2.7 could be interpreted as
requiring the responder to do that:

In the additional and authority section of the response the
responder includes the same records as a DNS server would insert in the
response to the unicast DNS query.

However, doing this seems redundant and wasteful - if the responder is
authoritative for some given name N, the response NS record would
always be of the form "N NS N", which carries no actual information.

I also find the requirement to include additional section data "as a
DNS server would" problematic. Other parts of the mdns specification
takes great care to ensure that LLMNR responders only respond to
queries for the name for which it is authoritative, yet the provision
for additional section data seems to allow a responder to send
additional records whose owner name is not within the server's
authority.

2. Sender behavior

The text in section 2.3 (b) also seems to assume that senders will
have NS records cached, presumably ones responders sent in the
authority sections of previous responses. However, the specification
does not actually require such caching, and I would argue that it is
wasteful for the same reason as sending the NS record is wasteful - it
would always be of the form "N NS N" and carry no actual information.

3. Additional failure modes

Using unicast based on cached NS records as specified in section 2.3
(b) introduces new failure modes; for example, if a responder detaches
from the network and reattaches with a different IP address, queries
will be sent to the old address and LLMNR resolution will fail until
the NS TTL has expired.

4. Additional security issues

If a sender caches arbitrary records from the authority and additional
section, this allows a malicious responder to trivially inject
information pertaining to another responder in the sender's cache.

5. No reduction in multicast traffic

While it may at first glance seem that the text of 2.3 (b) would
reduce the amount of multicast traffic, in fact it does not. To
illustrate, consider the case of a type A lookup. To avoid the
failure mode described above, you would have to make the NS record TTL
no longer than the A record TTL, which means the unicast would never
actually happen since any time an A record times out in the LLMNR
sender's cache, the corresponding NS records have also timed out. On
the other hand, if you don't care about the possibility of failure,
you can achieve the same reduction in multicast traffic without using
NS records, simply by increasing the TTL of the A record.

6. Increased complexity

Implementing the logic of 2.3 (b) would needlessly complicate the
sender implementation.

Requested change:

Remove item b. in section 2.3.

Remove the following sentence in section 2.7:

In the additional and authority section of the response the
responder includes the same records as a DNS server would insert in the
response to the unicast DNS query.

Add a new section as follows:

2.8. Use of the authority and additional sections

Unlike the DNS, LLMNR is a peer-to-peer system and does not have a
concept of delegation. In LLMNR, the NS resource record type may
be stored and queried for like any other type, but it has no
special delegation semantics as it does in the DNS. Responders
MAY have NS records associated with the names for which they are
authoritative, but they SHOULD NOT include these NS records in
the authority sections of responses.

Responders SHOULD insert an SOA record into the authority section of a
negative response, to facilitate negative caching as specified in
RFC2308. The owner name of of this SOA record MUST be equal to the
query name.

Responders SHOULD NOT perform DNS additional section processing.

Senders MUST NOT cache RRs from the authority or additional
section of a response as answers, though they may be used for
other purposes such as negative caching.

--
Andreas Gustafsson, [email-masked]

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