[dns-operations] Where to find "DNS resolution path corruption"?

[David Dagon]

On Tue, Feb 19, 2008 at 09:16:15AM +0100, Stephane Bortzmeyer wrote:

> To summary: not a DNS problem at all. Purely a Windows security issue.

The stub-to-recursive path touches both communities: windows and
network operators; and even more if there is application caching.

Traditional poisoning attacks of course usually have only DNS or
network operators on either end.  (We'll ignore the trivial DNS
poisoning attacks against old windows resolvers, which are entirely a
Windows problem.)

The paper did not intentionally characterize blame (well, the
'suggestions' section was admittedly DNS-centric, and looked mostly to
the network operators).  Nonetheless, I'm quite happy to characterize
this anyway that results in either community taking responsibility and
offering solutions.  When I talk to network operators, I say this is a
DNS problem, since they're more likely to take action.  When I talk to
software developers, I say this is a Windows problem, since they're
then more likely to take action.

Having hinted at blame this way, I've found some ISPs are considering
'locking in' their users who resolve using the ISPs recursive servers;
an opt-out might preserve e2e for customers who want to use other DNS
services (e.g., the opt-in OpenDNS).  Or at least these are the ideas
being considered by those who believe this is not just a Windows
problem, but their network problem.

Your larger point is that the paper suggestions were very
network-centric.  True enough.  In candor, this reflects the limited
time I had to write the paper, and the limited space.  (We wanted more
tables in the paper.)  A compromised host can have any service
disabled, including DNSSEC.

-- 
David Dagon              /"\                          "When cryptography
dagon at cc.gatech.edu      \ /  ASCII RIBBON CAMPAIGN    is outlawed, bayl
Ph.D. Student             X     AGAINST HTML MAIL      bhgynjf jvyy unir
Georgia Inst. of Tech.   / \                           cevinpl."