On 3/23/2004 12:05 PM, David Meyer wrote:
> This is a WG Last Call (WGLC) for comments on "Operational
> Considerations and Issues with IPv6 DNS",
>
> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-04.txt
>
> Please review the document carefully, and send your feedback to
> the list. Please also indicate whether or not you believe that
> this document is ready to go to the IESG for Informational.
I disagree with the implication of section 4.5, but only mildly:
| 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 ("glue") records 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. 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 [31]).
The "best" scenario is for additional-data associated with DNS-specific
RRs (such as NS RRs) to give preference to the current network type, and
for additional-data associated with application RRs (such as MX RRs) to
interleave a randomized subset of network type addresses.
Short of going into all of that, however, the default position should be
to favor the network type in use, since that is likely to be the network
type in use for followup queries. If the data is *really* important, it
will be explicitly requested anyway, so there is no loss no matter what.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
