[dns-operations] DNSSEC impact on applications was Re: security-aware stub resolver

Edward Lewis Ed.Lewis at neustar.biz
Tue May 27 17:51:36 UTC 2008

At 17:32 +0000 5/27/08, Paul Vixie wrote:

>reason than the problems the industry will have supporting it.  the first and
>last mile for a stub resolver has to be (a) secure and (b) capable of
>expressing validation failures apart from resolution failures.

Perhaps the issue here surrounds two differing viewpoints.

On the one hand, when you attached to a local network, the 
accuracy/integrity of the DNS is not your biggest concern.  The local 
network (including the collective admins designing and operating) may 
want you to rely on a local name server, dhcp server, etc., so they 
can manage the network better.  (Yes, and perhaps make more money by 
rewriting NXDOMAINs.)  No matter what, you are at the mercy of the 
router and firewall they run.

In that scenario, the stub might as well put it's faith in the last 
mile and the DNS iterative/recurisve/cache there.  Note that this 
scenario covers the "hotel LAN" problem, the coffee cafe, a 
residence, or an enterprise/office.

On the other hand, if you are in an environment in which the end 
points have specific security-sensitive missions, then the 
enforcement of security policy is best done "close to the vest."  In 
this case security is important enough to bear a higher cost, for the 
benefit of compartmentalizing it.  Usually this is just in defense 
departments or places were there is some financial or accountability 
needs to be met.

In this scenario, applications and/or smart stubs are the way to go.

It's not like one scenario is more right than the other.  I've worked 
in both, the birth of DNSSEC was more closely related to the latter 
(when you consider the funding, etc., of the early work).  I don't 
expect that there will be a conclusion to the debate between 
stubs-with-TSIG vs. stubs-that-validate because each has an 
environment in which they shine.

However, the first scenario is by far the most prevalent.  Therefore 
I don't expect to see the browser/email/et.al. clients adopt DNSSEC 
into the mainstream code base.
Edward Lewis                                                +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

More information about the dns-operations mailing list