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

[Mark Andrews]

> 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.

	And ISP's will do this in a dumb manner the same way as
	hotels do this in a dumb manner.  They will add a
	"transparent" DNS proxy/intercept box.

	They won't look at "rd", thereby breaking every interative
	resolver.

	They won't pass through queries that have a TSIG breaking
	support for those using a tamper resistant channel.

	They may not have a DNSSEC aware box breaking the ability
	to use DNSSEC.

	They won't advertise this in advance.

	They won't have a opt in/out mechanism.

> 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."
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.oarci.net
> http://lists.oarci.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org