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
