[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: jelte@nlnetlabs.nl (Jelte Jansen)
Cc: dnssec@cafax.se
From: Bill Manning <bmanning@isi.edu>
Date: Mon, 10 May 2004 16:28:36 -0700 (PDT)
In-Reply-To: <40A00AEB.1010603@NLnetLabs.nl> from "Jelte Jansen" at May 11, 2004 01:06:19 AM
Sender: owner-dnssec@cafax.se
Subject: Re: dnssec: resolver - application communication

% The problem with returning a complete chain of trust is that it could be 
% way too big, even for EDNS0.

	Presuming facts not in evidence.

% Correct me if I'm wrong here, but I believe the proposal is something 
% like this:

	the proposal?  more like -a- proposal.

% The thought here is that we would spare the higher servers from 
% individual harassment by every single machine on the planet, and still 
% provide the most important piece of information (a result or a message 
% that it has failed), whilst allowing 'debugging' (dig++), and preventing 
% major spoofing (by having the forwarders do 'real' validation) and not 
% have every single application implement their own validation routines 
% (which the original proposal came down to), or demanding yet another 
% extension to the protocol (which would take, er, pretty long probably).

	"original proposal"  - which one?

	the tradeoff here is:

	"individual harassment by every single machine"
	vs
	"individual harassment by every single validator"

	remember that caching works and should be exploited
	here to our advantage.  I'm not opposed to having
	a well defined validation API that can be put into
	resolvers (caching or otherwise) or glued directly 
	into any given app. ... just like they can and do
	use their own resolver(s).

% 
% Jelte
% 


-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).


Home | Date list | Subject list