>>>>> On Fri, 23 Apr 2004 13:13:54 +0300 (EEST),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
> Thanks for the insistence. I think this should address your
> concerns..
Thanks for your patience. The 06pre revision basically looks fine,
and I can live with it.
However, IMO it could use further clarification on missing records in
the additional section.
As someone has already pointed out in this list (if I remember
correctly), the level of the problem of missing additional records
differs between "glue" records and other additional data.
The "glue" case: consider a zone delegation with the following
configuration:
child.example.com. IN NS ns.child.example.com.
ns.child.example.com. IN A 192.0.2.1
ns.child.example.com. IN A 192.0.2.2
...
ns.child.example.com. IN A 192.0.2.X
ns.child.example.com. IN AAAA 2001:db8::1
ns.child.example.com. IN AAAA 2001:db8::2
...
ns.child.example.com. IN AAAA 2001:db8::Y
(where X and Y are some large numbers)
when a caching resolver tries to resolve a name under
child.example.com, it will get the NS record from the parent zone
(example.com.) and the glue A and AAAA RRset. If either or both
RRsets must be removed from the additional section and the caching
resolver cannot get an appropriate RRset for transport available for
the resolver, this is a critical problem; there is no other workaround
for this problem. (The problem can happen even without AAAA (or A),
and in that sense, this is not specific to IPv6. But adding AAAA can
increase the risk of missing additional data, so this is a kind of
IPv6-related problem.)
On the other hand, in the case of other additional data, just like
described in the example of Section 4.5, the problem is not critical;
the final user (application) of the missing record can issue another
query to fetch it. Even though it makes additional delay or
consumption of network resource, at least we have a workaround.
So, the desirable logic in Sections 4.4 and 4.5 is, IMO, as follows:
- Section 4.4
+ there are two types of problems caused by missing additional
data.
+ one of the problems is critical. the other can cause suboptimal
results, but there are workarounds
+ for both problems, a protocol fix (EDNS0) and an operational fix
can be considered.
+ for the non critical problem, the application should be careful to
not make the problem critical (perhaps we should move the last
paragraph of Section 4.5 here)
(other considerations, such as the one described in the second
paragraph of the current document)
- Section 4.5
different TTLs for A and AAAA can cause a similar problem as the
non-critical one described in Section 4.4. Using the same TTL might
be useful to minimize the problematic cases. Still, applications
should be careful enough.
Again, I can live with the current text in 06pre. I'd leave it to you
whether to adopt the revised logic.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
