RFC2181 section 9.1: TC bit handling and additional data

[Pekka Savola <pekkas@netcore.fi>]

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