On Mon, Mar 03, 2014 at 07:14:31AM -0800,
Paul Vixie p...@redbarn.org wrote
a message of 45 lines which said:
I don't think that a RRset can be possibly truncated. Either it is
truncated (not sent in its entirety) and the TC bit is set, the
resolver does not have to guess, or it is not
On Tue, Mar 04, 2014 at 05:32:09PM +1100,
Mark Andrews ma...@isc.org wrote
a message of 24 lines which said:
*Glue records are not optional in a referral.*
Why? A resolver can always reissue A and requests after receiving
NS RRsets without glue. This increase latency but it will work.
On 3 Mar 2014, at 18:46, Paul Vixie p...@redbarn.org wrote:
i know of code that's in widespread use which assumes that TC=1 means that
the last non-empty section was damaged but that it is safe to cache anything
found in earlier sections. this code is clearly wrong-headed, but as i said,
draft-ietf-dnsop-respsize-15.txt says:
Note that truncation of the additional data section might not be
signaled via the TC bit since additional data is often optional
Using the word truncation here is dangerous. By definition, there is
truncation only when the TC bit is set. Optimizing the
On Mar 3, 2014, at 3:14 PM, Paul Vixie p...@redbarn.org wrote:
are you advising (by implication) that a receiver who hears TC=1 with
ANCOUNT0 or NSCOUNT0 or ADCOUNT0 treat it as a FORMERR?
Hmm.
I always assumed that if TC=1, pretty much everything else in the response was
irrelevant since I
On Mar 3, 2014, at 1:52 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:
On Mon, Mar 03, 2014 at 10:46:25AM -0800, Paul Vixie wrote:
a protocol clarification (not a change, which dnsop can't by charter
make)
I really don't think our biggest problem is making the RFC publication
With RFC 103[45] DNS TC=1 indicated that the last section with content
is incomplete and earlier sections are complete. You can have TC=1
for failure to add glue records to the additional section in a
referral. *Glue records are not optional in a referral.*
With more modern DNS you need to
