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

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

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-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>