Subject: [DNSOP] On some terminology in draft-ietf-dnsop-respsize (truncation)

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 3 Mar 2014 10:51:38 +0000

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 answer by
dropping non-necessary RRsets is *not* truncation. To quote RFC 2181,
"The TC bit should not be set merely because some extra information
could have been included, but there was insufficient room."

> will automatically requery for RRSets that are possibly truncated

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 truncated. There is
never an ambiguity. (Unless you use "truncation" in the sloppy sense I
criticized above.)

Editorial :

> RRSets are are never sent partially

One are too many :-)

---

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Mar 2014 07:14:31 -0800

> never an ambiguity. (Unless you use "truncation" in the sloppy sense I

are you advising (by implication) that a receiver who hears TC=1 with
ANCOUNT>0 or NSCOUNT>0 or ADCOUNT>0 treat it as a FORMERR?

---

From: David Conrad <[email-masked]>
Date: Mon, 3 Mar 2014 18:41:07 +0000

On Mar 3, 2014, at 3:14 PM, Paul Vixie <[email-masked]> wrote:
> are you advising (by implication) that a receiver who hears TC=1 with ANCOUNT>0 or NSCOUNT>0 or ADCOUNT>0 treat it as a FORMERR?

Hmm.

I always assumed that if TC=1, pretty much everything else in the response was irrelevant since I would be unable to trust what was there was complete. So I'd say 'no' and I don't see any ambiguity....

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Mar 2014 10:46:25 -0800

David Conrad wrote:
> On Mar 3, 2014, at 3:14 PM, Paul Vixie <[email-masked]
> <mailto:[email-masked]>> wrote:
> I always assumed that if TC=1, pretty much everything else in the
> response was irrelevant since I would be unable to trust what was
> there was complete. So I'd say 'no' and I don't see any ambiguity....

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, is in wide-spread use.

a protocol clarification (not a change, which dnsop can't by charter
make) might be that a sender should send empty response, authority, and
additional sections when setting TC=1, and that a receiver must act as
if the response, authority, and additional sections are empty if it sees
TC=1.

vixie

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Mar 2014 13:52:23 -0500

On Mon, Mar 03, 2014 at 10:46:25AM -0800, Paul Vixie wrote:
> make) 

I really don't think our biggest problem is making the RFC publication
mechanisms move.  If we determine this is a "change" in some sense
because it's clarifying the meaning of the protocol, we can send it up
via AD sponsorship or run it through the INT area WG or whatever.  I
think it's very valuable to get some clear idea of what we think
first, though.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 3 Mar 2014 14:00:23 -0500

> think it's very valuable to get some clear idea of what we think

We can also bring up the relevant restriction in the charter discussion Friday. If it's useful to be more flexible about this, we can work on making the case with our AD.

I really really really don't want this kind of thing to be a barrier to getting the work done. If people are willing to swap the document back in, review it a little more (this discussion is a good start, thank you!) and get whatever substantive work remains on it knocked down, your WG chairs are perfectly willing to work on the machinery.

Suzanne

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Mar 2014 17:32:09 +1100

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 remove the OPT/SIG(0)/TSIG records
first then the examine the resulting message to find the incomplete
message.  If you are using OPT/SIG(0)/TSIG you are required to
reserve space for those records when constructing the reply.

If you are paranoid or lazy you just retry on TC=1.  named is lazy
in this respect.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Tue, 4 Mar 2014 13:08:38 +0000

On 3 Mar 2014, at 18:46, Paul Vixie <[email-masked]> 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, is in wide-spread use.
> 

> a protocol clarification (not a change, which dnsop can't by charter make) might be that a sender should send empty response, authority, and additional sections when setting TC=1, and that a receiver must act as if the response, authority, and additional sections are empty if it sees TC=1.

I'm aware of a SIP ATA apparently in semi-widespread use amongst customers of a large independent ISP in Canada which (a) doesn't support TCP transport, (b) doesn't support EDNS(0), and (c) issues an IN/SRV query to bootstrap, the response to which is large and reliably features TC=1.

The ISP in question switched from BIND9 to Unbound in their resolver clusters, and the helpdesk phone started to ring.

BIND9 would return a truncated but non-empty response, which would be good enough for the ATA to work (from the user's perspective). Unbound would send empty ANSWER, AUTHORITY and ADDITIONAL sections, which left the ATA stranded and caused much end-user ire.

Clearly the ATA in question is quite broken (or, the service's SRV RRSet was unreasonably large considering the client limitations). Surely this is not the only broken situation of this type on the Internet, however.

The fact that the change from BIND9 to Unbound behaviour has been observed to result in a non-zero support cost is pertinent, I think, when imagining clarifications to the specification.

Joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Mar 2014 14:05:46 +0000

On Mon, Mar 03, 2014 at 07:14:31AM -0800,
 Paul Vixie <[email-masked]> wrote 

> ANCOUNT>0 or NSCOUNT>0 or ADCOUNT>0 treat it as a FORMERR?

No. And there is no path from what I wrote to this strange
conclusion. You can have several RRsets in an answer, and some can be
intact and complete.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Mar 2014 14:48:06 +0000

On Tue, Mar 04, 2014 at 05:32:09PM +1100,
 Mark Andrews <[email-masked]> wrote 
 a message of 24 lines which said:

> *Glue records are not optional in a referral.*

Why? A resolver can always reissue A and AAAA requests after receiving
NS RRsets without glue. This increase latency but it will work.

But there is more: in a referral, sending *all* the glue records *is*
optional.

% dig +bufsize=512 @f.root-servers.net A www.internautique.fr

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 <<>> +bufsize=512 @f.root-servers.net A www.internautique.fr
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29492
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 7
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.internautique.fr.	IN A

;; AUTHORITY SECTION:
fr.			172800 IN NS f.ext.nic.fr.
fr.			172800 IN NS d.nic.fr.
fr.			172800 IN NS d.ext.nic.fr.
fr.			172800 IN NS e.ext.nic.fr.
fr.			172800 IN NS g.ext.nic.fr.
fr.			86400 IN DS 20122 8 2 (
				A4208B55FFB352EDC816D9329283DD8BBDDE44C58539
				5AF9AA7275ABE3CF6795 )
fr.			86400 IN DS 35095 8 2 (
				23C6CAADC9927EE98061F2B52C9B8DA6B53F3F648F81
				4A4A86A0FAF9843E2C4E )
fr.			86400 IN RRSIG DS 8 1 86400 (
				20140312000000 20140304230000 33655 .
				PG6KEeoGIzsI1KnwWLFCjbmfy9Gvc8EyOlHaAR/vBMD9
				kGKZW68OczNt95JwpA0xTRBBH+4wdxNZhrIiScJ4vT/A
				mjrwt2sV1SPFl1+gdX0yynYVwFd+5aVhOsZO7Djo/KzZ
				3HmHxttWjZGnQDbok5sUNuPwcKu2zENiwDsIS9M= )

;; ADDITIONAL SECTION:
d.ext.nic.fr.		172800 IN A 192.5.4.2
d.nic.fr.		172800 IN A 194.0.9.1
e.ext.nic.fr.		172800 IN A 193.176.144.22
f.ext.nic.fr.		172800 IN A 194.146.106.46
g.ext.nic.fr.		172800 IN A 194.0.36.1
d.ext.nic.fr.		172800 IN AAAA 2001:500:2e::2

;; Query time: 180 msec
;; SERVER: 2001:500:2f::f#53(2001:500:2f::f)
;; WHEN: Wed Mar 05 14:46:51 GMT 2014
;; MSG SIZE  rcvd: 500

Note all the glue records were sent and, yet, BIND did not set TC=1.