[dns-operations] Where to find "DNS resolution path corruption"?
Mark_Andrews at isc.org
Wed Feb 20 01:33:52 UTC 2008
> On Wed, Feb 20, 2008 at 10:36:44AM +1100, Mark Andrews wrote:
> > 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.
> A nice list.
> Thanks to Stephane, I'm coming up to speed on some of the more recent
> policy RFCs on name mangling. I make yardsticks and measure things
> (often malicious things). But on Wednesday, I'm talking to a large
> group of (mostly N. American) ISPs at MAAWG, who are forming a working
> group around DNS issues.
> Your list of dumb DNS things is larger than my short list of dumb DNS
> things, and I'll ask the ISPs not to do any of them for all the
> obvious reasons. Even if they listened, what else could go wrong?
> Here are my proposed arguments (comments welcomed):
> transparent proxy evils: users waste time learning that
> opendns does not work for them; users deserve to know the
> address of the DNS server actually resolving for them;
> mixed authority/recursive hosts (yes, bad) with custom TLDs
> in their zones will not be reached. What else? Various
> forums overflow with stories.
> ignoring 'rd': obviously bad
> TSIG: Do any proxies do anything more than merely forward or drop
> TSIG queries? (I think proxying would introduce potential
> clock issues, since now you have three parties with potentially
> different times. I.e., what if the client and proxy clocks differ,
> but the client and server's clocks are sync'd. BADTIME or not?)
> This seems far too complicated to do more than forward or drop.
TSIG is desgined to be passed through a proxy. You set the
id as you pass the request on and you restore the oringinal
id as you pass the reply back.
> DNSSEC: I worry ISPs won't provide such a box, particularly if it
> lets their DNSSEC-aware users reject the NXDOMAIN rewriting.
> (Cf. RFC 4924 s2.5)
ISP's shouldn't be re-writing NXDOMAIN without the consent
of the client. I suppect it could be classed as a criminal
act to do so w/o the client's consent.
> opt-out: In the worst case, notification and consent may be obtained
> by the user continuing to pay their cable bill. Here, perhaps
> the industry group can define best practices.
Sometimes there is not a practical alternative to the ISP
especially if the competition is also doing it. I've
definitely had to settle for non-optimal solutions at times
because there was no optimal solution. I suspect we all
> DNS vendors will be needed for whatever the N. American ISPs do, so
> some readers of this list might have the last word.
> Unlike the port 25 blocking effort from MAAWG, which took years, the
> ISPs have a potential revenue stream from NXDOMAIN rewriting.
Which makes them even more vulnerable to class actions as
they are making a profit from it.
> Thanks to everyone who posted in this thread; I've learned this
> iceberg is more of an iceshelf.
> 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."
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