Subject: Resend: Re: RFC2181 section 9.1: TC bit handling and additional data

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 01 Aug 2005 17:44:14 +0900

Apparently this was blocked or dropped due to sender address mismatch.

I'm trying to resend it with (seemingly) correct address.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

Subject: Re: RFC2181 section 9.1: TC bit handling and additional data
From: JINMEI Tatuya / 神明達哉<[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: [email-masked]
Date: Thu, 28 Jul 2005 22:29:51 +0900

>>>>> On Wed, 29 Jun 2005 21:00:36 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

> We would like to get some additional feedback especially on what's in 
> the implementations out there (the recommendations in the 
> specification seem clear enough).

> Specific questions (offlist responses are also fine):

Answers about ISC BIND 9.3.1 and 8.4.6, and NSD 2.3.0 (authoritative
only).  I actually confirmed the behavior with a test zone and test
queries for question 1, but the rest of the answers were just based on
code inspection (so I could be wrong).

>   1. how does your implementation (or the implementations you're
>      familiar with) handle the case of critical additional data
>      (example below) when the response doesn't fit.

>      a) set TC bit and remove all the additional data RRsets
>      b) set TC bit and remove some additional data RRsets so
>         the size is small enough
>      c) something else, what?

ISC BIND 9.3.1: c). remove some additional data RRsets so the size is
small enough.  does NOT set TC bit.  prefer A glues over AAAA glues by
default for each glue name.  configurable via the preferred-glue
option.

ISC BIND 8.4.6: c) same as BIND 9.3.1.

NSD 2.3.0: c) remove some additional RRs of some additional data
RRsets.  does NOT set TC bit.  The main difference from BIND is that
NSD can return a partial RRset in the additional section without
setting the TC bit (is this valid?).  Always prefer A glues over AAAA
glues (no configurable option).

>   2. how does your implementation (or the implementations you're
>      familiar with) handle the case of courtesy additional data
>      (e.g., CNAME) when the response doesn't fit.

>      a) remove the all the additional data RRsets if some of them don't
>         fit, don't set TC bit.
>      b) remove some of the additional data RRsets if the response
>         then fits, don't set TC bit.
>      c) set TC bit and [do something, what?]
>      d) something else, what?

ISC BIND 9.3.1: b).  Actually, BIND 9.3.1 does not differentiate
critical and courtesy additional data, although it prefers some
critical data (e.g., glues) over some courtesy data (e.g., DNSSEC
RRs).

ISC BIND 8.4.6: b) (same as BIND 9.3.1, although the preference logic
may be slightly different).

NSD 2.3.0: same as the answer to question 1.  does not differentiate
critical and courtesy additional data, although it prefers some
critical data over some courtesy data.

>   3. if your implementation (or the implemenations you're familiar
>      with) receives a response with TC bit set and an additional
>      section, what does it do?

>      a) ignore everything in the response, and re-query using TCP.
>      b) keep some or all of the data in the response, re-query using
>         TCP (additional details would be welcome).
>      c) something else, what?

ISC BIND 9.3.1 a)

ISC BIND 8.4.6 a) (there seem to be some exceptional cases, but I
think we can ignore such cases in this discussion).

>   4. do you know of any implementations which either do not set the TC
>      bit when all the critical additional data RRsets don't fit, or do
>      not ignore the whole response when the TC bit was set?

As for the former, BIND 8/9 and NSD never sets the TC due to
additional data.

As for the latter, none, as far as I know.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

APPENDIX: test details about question 1

- tested zone: ".example"
  It has a delegation to the child.example zone with one NS
  "ns.child.example", which has 15 AAAA glues and 9 A glues.
  I've checked the response from each tested server to
  dig @server's_address www.child.example +norec

- zone file
$TTL 518400

@ IN	SOA	ns.example. root.example. (
				  2005021601 ;serial
				  1800 ;refresh every 30 min
				  900 ;retry every 15 min
				  604800 ;expire after a week
				  86400 ;minimum of a day
				  )

	IN NS ns
ns	IN A  127.0.0.1

child	IN NS ns.child
ns.child IN AAAA 2001:db8::1
ns.child IN AAAA 2001:db8::2
ns.child IN AAAA 2001:db8::3
ns.child IN AAAA 2001:db8::4
ns.child IN AAAA 2001:db8::5
ns.child IN AAAA 2001:db8::6
ns.child IN AAAA 2001:db8::7
ns.child IN AAAA 2001:db8::8
ns.child IN AAAA 2001:db8::9
ns.child IN AAAA 2001:db8::a
ns.child IN AAAA 2001:db8::b
ns.child IN AAAA 2001:db8::c
ns.child IN AAAA 2001:db8::d
ns.child IN AAAA 2001:db8::e
ns.child IN AAAA 2001:db8::f
ns.child IN A 192.0.2.1
ns.child IN A 192.0.2.2
ns.child IN A 192.0.2.3
ns.child IN A 192.0.2.4
ns.child IN A 192.0.2.5
ns.child IN A 192.0.2.6
ns.child IN A 192.0.2.7
ns.child IN A 192.0.2.8
ns.child IN A 192.0.2.9

;; Query time: 0 msec
;; SERVER: 127.0.0.1#10053(127.0.0.1)
;; WHEN: Thu Jul 28 22:25:46 2005
;; MSG SIZE  rcvd: 196

- response from BIND 9.3.1
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10928
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 9

;; QUESTION SECTION:
;www.child.example.		IN	A

;; AUTHORITY SECTION:
child.example.		518400	IN	NS	ns.child.example.

;; ADDITIONAL SECTION:
ns.child.example.	518400	IN	A	192.0.2.1
ns.child.example.	518400	IN	A	192.0.2.2
ns.child.example.	518400	IN	A	192.0.2.3
ns.child.example.	518400	IN	A	192.0.2.4
ns.child.example.	518400	IN	A	192.0.2.5
ns.child.example.	518400	IN	A	192.0.2.6
ns.child.example.	518400	IN	A	192.0.2.7
ns.child.example.	518400	IN	A	192.0.2.8
ns.child.example.	518400	IN	A	192.0.2.9

;; Query time: 0 msec
;; SERVER: 127.0.0.1#10053(127.0.0.1)
;; WHEN: Thu Jul 28 22:26:32 2005
;; MSG SIZE  rcvd: 196

- response from BIND 8.4.6
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63072
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 9

;; QUESTION SECTION:
;www.child.example.		IN	A

;; AUTHORITY SECTION:
child.example.		518400	IN	NS	ns.child.example.

;; ADDITIONAL SECTION:
ns.child.example.	518400	IN	A	192.0.2.1
ns.child.example.	518400	IN	A	192.0.2.2
ns.child.example.	518400	IN	A	192.0.2.3
ns.child.example.	518400	IN	A	192.0.2.4
ns.child.example.	518400	IN	A	192.0.2.5
ns.child.example.	518400	IN	A	192.0.2.6
ns.child.example.	518400	IN	A	192.0.2.7
ns.child.example.	518400	IN	A	192.0.2.8
ns.child.example.	518400	IN	A	192.0.2.9

- response from NSD 2.3.0

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31241
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 20

;; QUESTION SECTION:
;www.child.example.		IN	A

;; AUTHORITY SECTION:
child.example.		518400	IN	NS	ns.child.example.

;; ADDITIONAL SECTION:
ns.child.example.	518400	IN	A	192.0.2.1
ns.child.example.	518400	IN	A	192.0.2.2
ns.child.example.	518400	IN	A	192.0.2.3
ns.child.example.	518400	IN	A	192.0.2.4
ns.child.example.	518400	IN	A	192.0.2.5
ns.child.example.	518400	IN	A	192.0.2.6
ns.child.example.	518400	IN	A	192.0.2.7
ns.child.example.	518400	IN	A	192.0.2.8
ns.child.example.	518400	IN	A	192.0.2.9
ns.child.example.	518400	IN	AAAA	2001:db8::1
ns.child.example.	518400	IN	AAAA	2001:db8::2
ns.child.example.	518400	IN	AAAA	2001:db8::3
ns.child.example.	518400	IN	AAAA	2001:db8::4
ns.child.example.	518400	IN	AAAA	2001:db8::5
ns.child.example.	518400	IN	AAAA	2001:db8::6
ns.child.example.	518400	IN	AAAA	2001:db8::7
ns.child.example.	518400	IN	AAAA	2001:db8::8
ns.child.example.	518400	IN	AAAA	2001:db8::9
ns.child.example.	518400	IN	AAAA	2001:db8::a
ns.child.example.	518400	IN	AAAA	2001:db8::b

(Note that the AAAA RRset is incomplete)

;; Query time: 0 msec
;; SERVER: 127.0.0.1#10053(127.0.0.1)
;; WHEN: Thu Jul 28 22:28:00 2005
;; MSG SIZE  rcvd: 504

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 28 Jul 2005 20:04:58 +0900

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

>>>>> On Thu, 28 Jul 2005 11:46:34 +0300 (EEST), 

>> Did you get sufficient information about these questions?  As far as I
>> know, there has been no public response on the list.  If there has
>> been no off-list response either, I'll try to answer the questions on
>> one implementation I know of a bit.

> There has been no response at all.  I guess everyone is hoping someone 
> else will be responding.  I'd really appreciate any responses.

Okay.  One quick question:

Does this mean "if the implementation receives a response with TC bit
set and *with* a (non empty) additional section..."?

					JINMEI, Tatuya

--
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: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 28 Jul 2005 17:10:37 +0900

> In the process of finalizing draft-ietf-dnsop-ipv6-issues-xx.txt, 
> we've had off-list discussion about TC bit handling when the 
> criticial/courtesy additional data section should include both A and 
> AAAA records.

					JINMEI, Tatuya