Subject: OPT RR placement

From: Brandon Black <[email-masked]>
Date: Mon, 24 Mar 2008 16:25:13 -0500

Hi,

A question about edns0 and truncations and the placement of OPT RRs: My 
best understanding of where and how to truncate DNS responses to an 
EDNS0 query (based on the most recent relevant RFCs/drafts and the 
recent edns0 bis) is basically:

   If an RR being added to the Answers section would cause the packet to 
exceed the client's supported edns0 size, then you send a response with 
the TC bit set and no RRs (other than the copied question obviously). 
This is basically identical to how you would handle the same query for 
non-edns clients.

   If an RR being added to the Authority section would exceed the edns0 
size, leave the Authority section empty and set the TC bit (but preserve 
the answers).  In addition if the answer section alone was >512 (but 
within the edns0 size), then clear that out as well (empty response + TC 
again).  Again this is basically how you would handle the same query for 
non-edns clients.

What seems currently ambiguous to me is what do to about crossing the 
edns0 size barrier during Additional section processing.  It seems the 
most reasonable behavior would depend largely on where the OPT RR is 
placed within the additional section.  If your implementation puts the 
OPT RR first in the additional section, then a logical answer would be:

   If adding the OPT RR itself would cause the packet to exceed the 
client's supported edns0 size, then fall back to non-edns response, 
which again means that if one or both of the preceding sections were 
 >512, setting TC and clearing them out as necessary.
   But if the OPT RR fits, then one could conceivably add additional RRs 
until the edns0 size limit is reached, and simply send "what fits" 
without a TC bit.

But I don't see any recommendation for putting the OPT RR first, and 
BIND's behavior is the opposite on short packets (OPT RR last), although 
I didn't yet test how it would arrange things in this particular case.

-- Brandon

--
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: Mark Andrews <[email-masked]>
Date: Tue, 25 Mar 2008 11:11:01 +1100

> I didn't yet test how it would arrange things in this particular case.

	BIND reserves space for the OPT and TSIG/SIG records in the
	response.  They always fit.  OPT is logically part of the
	header.  TSIG/SIG are authentication mechanisms.
 
	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brandon Black <[email-masked]>
Date: Mon, 24 Mar 2008 19:34:12 -0500

> 	header.  TSIG/SIG are authentication mechanisms.

Hmmm yes I see that now, thank you.  I've built up some test zones to 
explore how BIND (this particular install of 9.4.1 in any case) does 
these things to help me interpret what the standards are calling for 
(there are a few related to this).  This has clarified some things but 
made other things less clear.

Should TC be set if all of the Answers fit, but the auth RRs don't fit?

Should partial RRsets be included in Answers if that's all that can be fit?

My reading of this list and the RFCs (and some of the upcoming drafts) 
says that the answers to both questions should be no, but BIND 9.4.1 
seems to say yes to the first question in all cases, and it seems to say 
yes to the second in response to a non-edns query (but no in response to 
an edns query).

I should add that everything I'm talking about is relative to how an 
authoritative-only server should operate - caching isn't an issue for me 
(thankfully), and the BIND I'm looking at for behavioral reference is 
configured with:

   recursion no;
   additional-from-cache no;
   additional-from-auth yes;

-- Brandon

---

From: Robert Elz <[email-masked]>
Date: Tue, 25 Mar 2008 11:03:44 +0700

Date:        Mon, 24 Mar 2008 19:34:12 -0500
    From:        Brandon Black <[email-masked]>
    Message-ID:  <[email-masked]>

  | Should TC be set if all of the Answers fit, but the auth RRs don't fit?

That depends upon the purpose of the auth RRs - there are times when they're
required for the answer, in which case the answer to your question would be
yes, but in general, no (provided that any RRset that is added in the auth
section is complete - it can be complete, or omitted (if not essential),
it can't be partial).

  | Should partial RRsets be included in Answers if that's all that can be fit?

Not unless TC is set, ever - if TC is set, it doesn't matter what is in
the answer, so it is generally best (more effecient) to send nothing, but
that's an implementation choice.

Having said all that, setting TC is never truly fatal, just adds lots of
overhead and delays, so erring on the side of setting it more than necessary
is the safe way.

kre

---

From: Wouter Wijngaards <[email-masked]>
Date: Tue, 25 Mar 2008 13:48:36 +0100

Hi Brandon,

Brandon Black wrote:
| Mark Andrews wrote:
|>     BIND reserves space for the OPT and TSIG/SIG records in the
|>     response.  They always fit.  OPT is logically part of the
|>     header.  TSIG/SIG are authentication mechanisms.

NSD (and unbound) perform similarly; they reserve space for the OPT (and
TSIG) RRs in advance.

Filling up with data is done by adding RRsets, in full or not at all,
until the size limit is reached. If an answer or authority section RRset
does not fit the TC bit is set, otherwise the TC bit is not set.

It is not valid to give an answer lacking its authority section. You
have to set the TC bit then. Because DNSSEC needs NSECs, negatives need
SOA, and other cases.

Yes

| Should partial RRsets be included in Answers if that's all that can be
fit?
No partial RRsets in the answer section. set the TC bit.
No partial RRsets in other sections.

Best regards,
~   Wouter