Subject: additional data [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt]

From: Pekka Savola <[email-masked]>
Date: Wed, 7 Apr 2004 10:01:32 +0300 (EEST)

Note: I did not see a clear resolution to this thread, so I did not 
reflect it in the document.  However, I'd be glad to make some changes 
if there was agreement on the wording.  Please continue.. :)

However, I made a few more editorial fixups from you Peter to the 
section:
 - clarified the difference of glue/additional data
 - added clarification on TC use

The revised paragraph is below.

4.5  Behaviour of Glue in Mixed IPv4/IPv6 Environments

   In the previous section, we discussed the effect of impartial data
   returned from the caches when the TTLs are not kept the same.  Now,
   we present another problem highlighted in the mixed IPv4/IPv6
   environments.

   Consider the case where the query is so long or the number of the
   additional records (originated from "glue") is so high that the
   response must either be truncated (leading to a retry with TCP) or
   some of the additional data removed from the reply.  However, note
   that if too much additional information that is not strictly
   necessary would be added, one should remove unnecessary information
   instead of setting TC bit for this "courtesy" information [17].
   Further, resource record sets are never "broken up", so if a name has
   4 A records and 5 AAAA records, you can either return all 9, all 4 A
   records, all 5 AAAA records or nothing.

   In the case of too much additional data, it might be tempting to not
   return the AAAA records if the transport for DNS query was IPv4, or
   not return the A records, if the transport was IPv6.  However, this
   breaks the model of independence of DNS transport and resource
   records, as noted in Section 1.2.

   This temptation would have significant problems in multiple areas.
   Remember that often the end-node, which will be using the records, is
   not the same one as the node requesting them from the authorative DNS
   server (or even a caching resolver).  So, whichever version the
   requestor ("the middleman") uses makes no difference to the ultimate
   user of the records.  This might result in e.g., inappropriately
   returning A records to an IPv6-only node, going through a
   translation, or opening up another IP-level session (e.g., a PDP
   context [37]).

   The problem of too much additional data seems to be an operational
   one: the zone administrator entering too many records which will be
   returned either truncated or impartial to the users.  A protocol fix
   for this is using EDNS0 [38] to signal the capacity for larger UDP
   packet sizes, pushing up the relevant threshold.  The operational fix
   for this is having the DNS server implementations return a warning
   when the administrators create the zones which would result in too
   much additional data being returned.

On Mon, 29 Mar 2004, Peter Koch wrote:
> Eric A. Hall wrote:
> 
> > Omitting all additional-data is not helpful.
> 
> could you elaborate, please? My intent was to shift the choice from the
> server, who can guess at best, to the client or the resolver acting on
> behalf of it, respectively.
> 
> Even the draft you cite
> 
> > http://www.ietf.org/internet-drafts/draft-hall-qtype-addr-01.txt says:
> 
> suggests this:
> 
> > |     record sets are to be provided. Both resource record sets MAY be
> > |     omitted from the additional-data section if necessary or desired.
> 
> 
> > In the case of other-application pointers (like MX addresses), it is far
> > better to omit the additional-data than it is to provide and cache
> > incomplete RRsets.
> 
> Incomplete RRSets are no option anyway.
> 
> -Peter
> .
> dnsop resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html