Subject: Re: Clarification Request (Truncation)

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 1 Feb 2008 11:59:31 +0100

On Tue, Jan 29, 2008 at 06:59:15PM -0500,
 Kevin Darcy <[email-masked]> wrote 
 a message of 31 lines which said:

> So, if an authoritative nameserver responds to a QTYPE=SOA query,
> with the SOA RR in the Answer Section, but cannot fit all of the
> apex NS records of the zone into the Authority Section, should it
> set TC or not?

IMHO, yes, strong YES. Doing otherwise would violate the atomicity of
the NS RRset. 

I admit I was not able to find text in an RFC about this atomicity
(RFC 2181, 5.1, only talks about the Answer section). Somehting to add
to the "profile" document? Thou MUST NOT split a RRset *or* set TC if
you do?

--
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: Robert Elz <[email-masked]>
Date: Fri, 01 Feb 2008 19:48:15 +0700

Date:        Fri, 1 Feb 2008 11:59:31 +0100
    From:        Stephane Bortzmeyer <[email-masked]>
    Message-ID:  <[email-masked]>

  | IMHO, yes, strong YES. Doing otherwise would violate the atomicity of
  | the NS RRset.

No, you're considering the incorrect alternative.   That is, you're
assuming the choice is between including the SOA in the annswer,
incomplete NS RRSet in the auth, and setting TC, and including the SOA
in the answer, incomplete NS RRSet in the auth, and TC==0.

That's not what is being questioned here, that choice isn't worth
asking about, the second alternative is clearly wrong.

The actual choice being asked about is

	a) SOA in answer, incomplete NS RRSet in Auth, TC set
	b) SOA in answer, nothing in auth, TC==0

Of those, (b) is the better option, and the one 2181 says that servers
should implement.   (a) also works, but is sub-optimal.

That is, in this case, the NS records in the auth section do nothing
really useful (beyond priming the cache of the resolver), and the better
choice is to omit them, and send the answer the resolver requested
without TC, so it isn't forced into a TCP repeat of the query.

  | I admit I was not able to find text in an RFC about this atomicity
  | (RFC 2181, 5.1, only talks about the Answer section). Somehting to add
  | to the "profile" document? Thou MUST NOT split a RRset *or* set TC if
  | you do?

See section 9.

kre

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 01 Feb 2008 16:05:50 -0500

> to the "profile" document? Thou MUST NOT split a RRset *or* set TC if
Sorry, I wasn't completely clear. The two alternatives, as kre has point 
out, are:

1) Authority Section empty, TC clear
2) Authority Section has a partial RRset, TC set

Option #2 will cause most (all?) implementations to automatically retry 
via TCP, which is unnecessary if the SOA RR (the answer to the question) 
was returned in the Answer Section.

- Kevin

---

From: Pekka Savola <[email-masked]>
Date: Sat, 2 Feb 2008 10:04:35 +0200 (EET)

On Fri, 1 Feb 2008, Kevin Darcy wrote:
> Sorry, I wasn't completely clear. The two alternatives, as kre has point out, 
> are:
>
> Option #2 will cause most (all?) implementations to automatically retry via 
> TCP, which is unnecessary if the SOA RR (the answer to the question) was 
> returned in the Answer Section.

We had this discussion though from a slightly different perspective 
when we were writing RFC 4472; section 4.4 and appendix B may be of 
interest.

One of the key points here is that RFC2181 says an implementation 
should _discard_ the response that came with TC bit set and retry with 
TCP.  If TCP fails, you have no answer -- in contrast to option 1) 
above where two UDP queries would succeed.  So, option 1) seems like a 
more robust approach from the practical perspective.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings