Subject: LLMNR issue 95: Negative Caching

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Aug 2005 16:53:07 -0700 (PDT)

The text of LLMNR Issue 95 (submitted in IETF last call) is enclosed 
below.  The proposed resolution is as follows:

In Section 2.9, change:

"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 this SOA record MUST be equal to the
query name."

To: 
"Responders SHOULD insert an SOA record into the authority section of
a negative response, to facilitate negative caching as specified in
[RFC2308]. The TTL of this record is set from the minimum of the
MINIMUM field of the SOA record and the TTL of the SOA itself,
and indicates how long a resolver may cache the negative answer.
The owner name of the SOA record (MNAME) MUST be set
to the query name. The RNAME, SERIAL, REFRESH,
RETRY and EXPIRE values MUST be ignored by senders. 
Negative responses without SOA records SHOULD NOT be cached."

------------------------------------------------------------------------
Issue 95: Negative Caching
Submitter: Yi Zhao
Submitter email address: [email-masked]
Date first submitted: August 11, 2005
Reference: 
Document: LLMNR-42
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Which errors are negatively cached in LLMNR?  What determines how long 
they are cached for?  What are the recommended values in the fields for 
the SOA RR included in negative responses?  

[BA]  LLMNR-42 Section 2.9 says:

"  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 this SOA record MUST be equal to the
   query name."

According to RFC 2308, Section 2:

"  The most common negative responses indicate that a particular RRset
   does not exist in the DNS.  The first sections of this document deal
   with this case.  Other negative responses can indicate failures of a
   nameserver, those are dealt with in section 7 (Other Negative
   Responses)."

[RFC2308] Section 2.1, describes RCODE=3 (NXDOMAIN) errors.  Section 2.2
describes NODATA errors (RCODE=0 and no RRs in the answer section).  
Section 7.1 describes Server failure (optional) and 7.2 describes 
Dead/Unreachable server (optional) errors. 

LLMNR-42, Section 2.1.1 states:

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

I don't recommend attempting to negatively cache Server failure or 
Dead/Unreachable server errors in LLMNR.  Since an LLMNR response with
RCODE=3 is not permitted, the primary error to be 
negatively cached in LLMNR is NODATA (RCODE=0 and no RRs in the answer 
section).  Such a response can be received if an LLMNR responder 
is authoritative for a name but the queried RR does not exist.  
For example, a responder as an A RR, but no AAAA RR, and the query 
is for the AAAA RR.  Note that a conflict can be detected from 
an LLMNR response, even if no data is present, because a 
response indicates that the responder believes it is 
authoritative for the name.  

[RFC2308] Section 3 states:

   Name servers authoritative for a zone MUST include the SOA record of
   the zone in the authority section of the response when reporting an
   NXDOMAIN or indicating that no data of the requested type exists.
   This is required so that the response may be cached.  The TTL of this
   record is set from the minimum of the MINIMUM field of the SOA record
   and the TTL of the SOA itself, and indicates how long a resolver may
   cache the negative answer.  The TTL SIG record associated with the
   SOA record should also be trimmed in line with the SOA's TTL.

This logic for determining the TTL in negative caching is also used in 
LLMNR. 

SOA

The primary use of SOA in LLMNR is for negative caching.  Without 
returning
the SOA in a NODATA error, negative caching is not possible.  [RFC2308]
Section 5:

   Negative responses without SOA records SHOULD NOT be cached as there
   is no way to prevent the negative responses looping forever between a
   pair of servers even with a short TTL.

My advice is to include SOA RR in an LLMNR response so as to allow 
negative 
caching and set the MINIMUM field and the TTL to the same value as the 
default TTL for LLMNR responses. 

Suggestion for fields in the SOA RR:

MNAME:   This is the LLMNR Responder's name (same as the query)
RNAME:   Irrelevant to LLMNR. 
SERIAL:  Set to YYYYMMDDXXXXXXX where YYYY = year, MM = month, DD = day, 
XXXXXXX = a counter. 
REFRESH: Irrelevant to LLMNR (but can be set to same value as MINIMUM)
RETRY:   Irrelevant to LLMNR (but can be set to same value as MINIMUM)
EXPIRE:  Set to a larger value than the default TTL (e.g. one week).  
MINIMUM: Set to the same value as the default TTL for LLMNR responses.

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