Pekka Savola;
> Let's take an issue separately from the rest. Me and Jinmei discussed
> this, but were OK with as it is. However, if WG has clear opinions,
> now might be time for modifying the text and/or recommiding changes to
> the additional data processing.
OK.
> As described by ipv6-dns-issues, section 4.4, 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.
The classification is not enough.
For an authoritative server answering a query, there are
"glue", that is, "critical", additional data and all the
other additionals are "courtesy". So, please don't invent
new terminologies and just say "glue".
For a resolver receiving a response, it is not distinguishable
whether A for NS of referral response is "glue" or not. On the
other hand, for resolvers, there can be "safe" and "unsafe"
additonal data distinguishable. "safe" data is on node in
or below the zone of the current server (zone of a server
is available from SLIST). Other data is "unsafe".
To make "safe" data really safe, which can not be expected
with the current implementations, there are additional
requirements. An authoritative server should add additionals
if it is "glue" and only if it is "glue", "authoritative" or
cached as "safe". A resolver should cache data as "safe" only
if additional data in an answer is "safe". A resolver should
cache data as "glue" tagged with the referral point, if
additional data in an answer is not "safe" but the answer is
referral and the additional is on address information of
reffered name servers. A resolver never use "glue" locally,
except for resolver's internal use for the tagged referral.
Other servers should add additionals only if they are cached
"safe" or the answer is referral and data is available in
cache as "glue" tagged with the answer's referral point.
As for migration, once your resolver and relaying/caching
servers are properly implemented, you can get safe data
from a zone with properly implemented authoritative servers
at the zone and all the decendant zones. Or, if an
authoritative server never use "safe" cache, you can ge safe
data from a zone with properly implemented authoritative
servers.
Complicated?
Masataka Ohta
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
