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

[Mark Andrews]

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

> 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