[dns-operations] security-aware stub resolver

[bmanning at vacation.karoshi.com]

On Thu, May 22, 2008 at 12:48:46PM -0700, David Conrad wrote:
> Joe,
> 
> On May 22, 2008, at 11:25 AM, Joe Abley wrote:
> > I had assumed that the "DNSSEC deployed" world would involve stub
> > resolvers setting RD=1 and DO=1, and validators setting DO=1, and
> > authority-only servers serving up security information. You seem to be
> > saying that the final utopia in your mind looks different.
> 
> I personally believe the correct answer here is that stub resolvers go  
> away, being replaced with validating caching resolvers.  Most of the  
> historical rationale that drove stub resolvers, namely client-side CPU  
> and memory limitations have long since been resolved (pun intended).   
> Bandwidth could be a consideration, although multi-layer caching/ 
> forwarding architectures could address this.
> 
> As we've seen repeatedly, unless you run your own caching server, you  
> can't really trust the response.  Particularly if you rely on your  
> ISP...
> 
> Regards,
> -drc


	here, we agree.  there is a not-so subtle difference btwn
	a resoultion and validation heirarchy.  as paul pointed out,
	the reason IEEE gave us 10G local lans was to hold the validation
	traffic for those resolvers who used a third-party validator.

	the ephemeral, system-call "stub" resolver will be augmented
	by something that has state and a cache.  i don;t think the
	legacy stub resovler will disappear, i suspect it will move 
	to embedded devices which have cpu/memory/power constraints
	(think active RFID tags).

	the choices are still, UNBOUND and BIND

--bill