FYI --
In the interest of avoiding crossposting, I made this query for
feedback on DNSEXT list only, as the issue was mostly related on the
protocol implementations.
Obviously, feedback/experience from DNSOP community would be welcome
as well.
---------- Forwarded message ----------
Date: Wed, 29 Jun 2005 21:00:36 +0300 (EEST)
From: Pekka Savola <[EMAIL PROTECTED]>
To: [email protected]
Subject: RFC2181 section 9.1: TC bit handling and additional data
Hi,
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.
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):
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?
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?
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?
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?
RFC2181 states:
9. The TC (truncated) header bit
The TC bit should be set in responses only when an RRSet is required
as a part of the response, but could not be included in its entirety.
The TC bit should not be set merely because some extra information
could have been included, but there was insufficient room. This
includes the results of additional section processing. In such cases
the entire RRSet that will not fit in the response should be omitted,
and the reply sent as is, with the TC bit clear. If the recipient of
the reply needs the omitted data, it can construct a query for that
data and send that separately.
Where TC is set, the partial RRSet that would not completely fit may
be left in the response. When a DNS client receives a reply with TC
set, it should ignore that response, and query again, using a
mechanism, such as a TCP connection, that will permit larger replies.
An example of the critical additional data is shown below (where getting both
the A and AAAA RRsets is critical w.r.t. to the NS RR):
child.example.com. IN NS ns.child.example.com.
ns.child.example.com. IN A 192.0.2.1
ns.child.example.com. IN AAAA 2001:db8::1
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--
to unsubscribe send a message to [EMAIL PROTECTED] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
