[dns-operations] Where to find "DNS resolution path corruption"?
Mark_Andrews at isc.org
Tue Feb 19 23:36:44 UTC 2008
> 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
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
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the dns-operations