Subject: I have a feeling that the rules for setting TC need tweaking

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Feb 2005 11:01:18 +1100

Currently the RFCs say don't set TC on truncation in the
	additional section.

	There are a number of cases where it is necessary to set TC
	for additional section truncation.

	* when using TSIG and after reserving enough space to fit
	the TSIG response there is not enough space left for the
	answer / authority sections.  This is logically equivalent
	to additional section truncation.

	* when using EDNS and after reserving enough space to fit
	the EDNS response there is not enough space left for the
	answer / authority sections.  This is logically equivalent
	to additional section truncation.

	* RFC 2181 precludes sending glue as a answer.  This leads
	to cases where, with big enough RRsets, you can't return
	the requested glue even as the first additional RRset.

	I propose that nameservers be allowed to set TC in these
	case.  For the glue case above it would only be if it will
	not fit as the first glue RRset in the additional section
	with or without space being reserved for TSIG and/or EDNS.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [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/>

---

From: Robert Elz <[email-masked]>
Date: Tue, 08 Feb 2005 13:02:10 +0700

I'm not sure what all the fuss is about here.   The "rules" for not
setting TC when an additional section is truncated are just to make
it clear that additional data is not supposed to be mandatory, and
forcing a TCP request to fetch it is just plain stupid.

It makes no sense though to try and prevent the server setting TC any
time it feels it needs to (it is the one that will suffer from having
to deal with TCP after all).

All that is needed is for the server to include nothing additional, and
set TC.   That's identical to a reply with a truncated answer/auth section,
and causes a TCP retry (the client cannot possibly tell that there wasn't
more needed for that section that simply didn't fit).

If you prefer, send a baby reply, with nothing but header with TC set in
it (no RR's, except the question, at all).

kre