[dns-operations] DNSSEC impact on applications was Re: security-aware stub resolver
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