Hi, Unfortunately there weren't follow-ups to this, so I just had to revise the draft on my own the best I could and submit:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-08.txt Various htmlwdiffs are available at: http://www.netcore.fi/pekkas/ietf/temp/ Comments are still appreciated. On Wed, 14 Jul 2004, Pekka Savola wrote: > (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
