Subject: [dnsop] dnsop-ipv6-dns-issues: handling of additional data and TTL w/ caching

From: Pekka Savola <[email-masked]>
Date: Wed, 14 Jul 2004 17:01:56 +0300 (EEST)

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 26 Jul 2004 12:44:35 +0300 (EEST)

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.

.