On Wed, 28 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H wrote:
> So, I'd totally revise the beginning of this section (including the
> first and second paragraphs) as follows:
I agree with you.
I've taken almost all of what you suggest, with a few touches; the
most important of them were:
- remove the mostly redundant "In other words" paragraph, integrate
it with the earlier numbered list.
- add an explicit note that it would be better to omit all of
courtesy additional data (now that we have a semantic difference)
rather than returning only some RRsets.
- I didn't understand what you wrote about the all "all the
latter three cases", so I reworded that.
- some minor changes.
(See below for text.)
> One additional comment: reconsidering the entire context, I guess the
> first sentence of the following paragraph should be clarified:
>
> 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.
>
> to, e.g.,
>
> In the case of too much "courtesy" additional data, ...
Did we (as WG) already agree that it's better to set TC bit than
return only some RRsets of critical additional data? I'd love that
kind of resulution, but for now, I put "(whether courtesy or
critical)" there. If folks have strong feelings of this, let's start
a new thread explicitly only about this.
In any case, I've updated the documents at the same locations, and
included the current section 4.4. below.
=====
4.4 Behaviour of Additional Data in IPv4/IPv6 Environments
Consider the case where the query name is so long, the number of the
additional records (originated from "glue") is so high, or for other
reasons that the entire response would not fit in a single UDP
packet. In some cases, the responder truncates the response with the
TC bit being set (leading to a retry with TCP), in order for the
querier to get the entire response later.
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
[19].
Also notice that there are two kinds of additional data:
1. "critical" additional data; this must be included (all the
possible RRsets) in all scenarios, and
2. "courtesy" additional data; this could be sent in full, with only
a few RRsets, or with no RRsets, and can be fetched separately as
well, but which could lead to non-optimal results.
Meanwhile, resource record sets (RRsets) 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. Notice that for
the "critical" additional data getting all the RRsets can be
critical.
An example of the "courtesy" additional data is A/AAAA records in
conjunction of MX records as shown in the next section; an example of
the "critical" additional data is shown below (where the lack of
either A or AAAA RRsets can be critical):
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
In the case of too much additional data (whether courtesy or
critical), 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 authoritative
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 [20]).
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 missing some RRsets to the users. A
protocol fix for this is using EDNS0 [40] to signal the capacity for
larger UDP packet sizes, pushing up the relevant threshold. Further,
DNS server implementations should rather omit courtesy additional
data completely rather than including only some RRsets. An
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.
Additionally, to avoid the case where an application would not get an
address at all due to non-critical additional data being omitted, the
applications should be able to query the specific records of the
desired protocol, not just rely on getting all the required RRsets in
the additional section.
====
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
