Subject: Re: Q-03: inclusion of KEY records in additional records section

From: David Blacka <[email-masked]>
Date: Thu, 24 Apr 2003 11:27:52 -0400

On Thursday 24 April 2003 01:44 am, Paul Vixie wrote:
> > Listed below in order of frequency of inclusion of KEY RRset
> > in additional section:
> > 	1. Always include covering KEY
> > 	2. Include covering KEY on referral only
> > 	3. Never
> > Please express preference on which rule to pick, and why.
> 
> #3.  the time the KEY is needed is the first time a validator sees a SIG
> with that keyname.  there is no way for a server to know when that's 
> occuring.  including it every time the SIG is exposed (as in #1 above)
> would waste resources.  including it only in the case of a referral (#2
> above) misses the target since the next key the validator will need is
> in the child zone and won't be the one you're including.

Would choosing option #1 waste resources that are important?  I can see how 
it will make response sizes larger, but so what?  Bandwidth gets cheaper 
over time, and DNS is already a near insignificant portion of overall IP 
traffic.  What other resources does this waste?

Choosing #3 forces more round trips.  Network latency has a fixed upper 
limit.  Of course, more round trips does not ncessarily mean more latency 
on the query as a whole, as clients can do parallel queries.

I'm just trying to make sure that we are optimizing the right thing here.

> > Should inability to include one or both of the KEY RRsets cause the
> > TC bit to be set ? (RFC2535 said no)
> 
> no.

If this remains true, then option #1 would effectively be an unenforceable 
recommendation.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Apr 2003 12:06:08 -0400

>on the query as a whole, as clients can do parallel queries.

I effectively disagreed with this - with the rationale that if we 
start out with the smaller answers we could 1) determine that they 
were sufficent or 2) observer that we need to do option 1.  If we 
start out with the larger answers, we might 1) not realize that 
smaller would be better or 2) not realize we made the right choice.

I also think that switching from #3 to #1 isn't that hard to deploy.

This all assumes that we have no sufficiently large test bed in which 
to try and measure the options.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

A compiler-directive person living in an HTML-tagged world.

---

From: David Blacka <[email-masked]>
Date: Thu, 24 Apr 2003 12:46:20 -0400

> smaller would be better or 2) not realize we made the right choice.

Ok, I think I get it.  You are saying that we don't know which approach is 
more efficient and we should be recommending a path that will make it 
apparent which approach is better.

> I also think that switching from #3 to #1 isn't that hard to deploy.

I agree, as long as the specification makes it clear the KEY rrsets MAY be 
included in the additional section of a response and that caches should 
accept, use and cache these RRsets.  If we go so far as to remove all 
additional processing considerations for KEY, then I think it would be 
difficult to switch.  Or maybe just useless to switch.

So, Ed, what I think you are driving toward is allowing servers to include 
KEY rrsets in the additional section (either all the time or just some of 
the time) but recommending that they do not.  Or am I going to far?

I like this, but I think it makes figuring out how to write an efficient 
client sort of harder.  Does the client, when querying a known or 
suspected secure zone for which it does not have a keyset issue a parallel 
query or not?  If we choose option #1 then maybe clients don't have to 
implement parallel queries?

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Apr 2003 13:31:06 -0400

>apparent which approach is better.

That is one of my arguments.  Thinking about it, I would have placed 
the architectural one and the IDS going ape ones first, but what you 
said above is the most important concern.  It might be that #1 is 
better than #3, but I can't see it and sort of feel that if we choose 
#3 now, the answer will be clear.

>... as long as the specification makes it clear the KEY rrsets MAY be

That's a vital point.  I am assuming that clients are agile (liberal 
in what they deal with while the servers are conservative in the 
range of answers they give).

>the time) but recommending that they do not.  Or am I going to far?

That's the right level.  I can't see banning the practice, but I'd 
like to discourage it if only to provide a 'control group' for the 
experiment (to see if #1 or #3 is the right approach).

>implement parallel queries?

My assumption, rightly or wrongly, is that this isn't a problem. 
Keep in mind that I'm one step up from a tourist when it comes to 
writing resolvers, the last one I did was 6 years ago and was just 
dig with a verifier.  I.e., I didn't dabble in parallelism in anyway 
and didn't try to optimize performance.  I do have a faint 
recollection of being shown, by another implementer, that a deadlock 
was possible if parallel queries went awry.

It would be good to get an opinion from someone who's given more 
recent thought to the implications of this on the resolver (as in - 
has cut code).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer