[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Q-03: inclusion of KEY records in additional records section
At 12:46 -0400 4/24/03, David Blacka wrote:
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.
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
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.
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).
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?
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).
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?
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
A compiler-directive person living in an HTML-tagged world.
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>