Hi, (also to dnsext WG)
Thomas Narten provided extensive feedback on draft-ietf-dnsop-ipv6-dns-issues at IESG evaluation, and I've tried to address his comments (see the I-D tracker) in: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-08pre-diff.html http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-08pre.txt but there are still a few where it might be useful to get feedback from the WG(s). Most of the discussion was on section 4.4 on the handling of additional data -- a subject that was already discussed briefly on the list around May 6, but did not have a clear conclusion (thread below): http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00406.html I've tried to summarize the discussion below *) Now, Thomas brought up a lot of the same issues at IESG evaluation, and I thought we should try again to see if there could be some consensus on how to move forward. .... I think we have achieved at least the follows (please yell if not the case): a) If some critical additional data RRsets wouldn't fit, you set the TC bit even if some RRsets did fit. b) If some courtesy additional data RRsets wouldn't fit, you never set the TC bit, but rather remove (at least some of) the courtesy RRsets. c) DNS servers should implement sanity checks on the resulting glue, e.g., to disable circular dependencies. Then the responding servers can use at-or-below-a-zone-cut criterion to determine whether the additional data is critical or not. Now, there are still (IMHO) many open issues: 1) if some critical additional data RRsets would fit, but some wouldn't, and TC has to be set (see above), should one rather remove the additional data that did fit, keep it, or leave unspecified? 2) if some courtesy additional data RRsets would fit, but some wouldn't, and some will have to be removed from the response (no TC is set, see above), what to do -- remove all courtesy RRsets, keep all that fit, or leave unspecified? 3) is it acceptable to use the transport used in the DNS query as a hint which records to keep if not removing all the RRsets, if: a) having to decide which critical additional data to keep, or b) having to decide which courtesy additional data to keep? 4) (this issue was discussed in section 4.5) if one RRset has TTL of 100 seconds, and another the TTL of 300 seconds, what should the caching server do after 100 seconds? Keep returning just one RRset when returning additional data, or discard the other RRset from the cache? 5) How do we move forward from here? If we manage to get to some form of consensus, how do we record it: a) just in draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational category only!), b) a separate BCP or similar by DNSEXT WG(?), clarifying and giving recommendations, c) something else, what? Thoughts, opinions, etc.? Fire away! (I'm trying to submit a revised document prior to the cut-off in any case, no matter how this turns out..) A few of my personal thoughts below the summary. *) a summary attempt of the past discussion below. ======== Edward Lewis (on dnsop) thought that omitting vs including courtesy additional data was a tradeoff at the server end (issue about handling the new query vs potentially misleading the client), and that TC bit should only be set if critical additional data was left behind. Robert Elz thought that the servers could add also add full RRsets, even if not all of them, if they want to. Similarly, he would rather return only part of the courtesy data than set the TC bit. He was of two minds about whether to set TC bit when all of courtesy additional data won't fit (but slightly leaning on TC bit, except if some additional data could fit and be included in a round-robin fashion); Robert also called for measurements on this. Paul Vixie thought that just simply setting TC bit if anything doesn't fit is a good idea if we don't have measurements to justify another kind of approach. Matt Larson commented on the definition of glue; the responding server can know whether the data is critical just by looking whether it's at-or-below-a-zone-cut. Masataka Ohta commented that this isn't sufficient if e.g. "org" zone is served by an "edu" server and vice versa. Mark Andrews rebutted that we don't have to support all the combinations if it makes managing the DNS impossible; DNS server software have included checks to avoid circular dependencies. Masataka Ohta also participated in the discussion, and Andreas Gustafsson clarified Paul Vixie's comment. ========= As for my personal take, if interested: My argument is that it would be best to return everything, or as little as possible. Not whatever you think you feel like you want to send. The reasoning here is that that if the user/application is interested in both A and AAAA records (this doesn't matter if (s)he's only interested in one), the DNS should either try to ensure (as far as possible) it's giving a full view, or just basically say to the user, "query yourself what you want, here's the critical info you need for those queries". This is based on the assumption that if the DNS servers start second-guessing what kind of information the end-user would prefer (e.g., by looking at the transport used), it's likely going to go wrong because the DNS server asking for the records from the second-guessing DNS server is likely going to be acting as a recursive resolver, and it doesn't really indicate *at all* which IP version the application wants to prefer (or not), or which kind IP version is available in the first place. So, relating to the questions above: 1) not much preference here 2) remove all courtesy data 3) I'd rather not to look at the transport used, but 3.a) would be acceptable, 3.b) not (per 2) 4) I'd prefer discarding all the RRsets from the cache when the one with the shortest TTL one times out, this ensures an "everything or nothing" approach. 5) A separate document might be good so that this doesn't get lost within an Informational document. -- 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
