you're not interesting, was Re: another brick in the wall[ed garden]

Fri May 15 00:37:41 UTC 2009

In message <70D072392E56884193E3D2DE09C097A91F3EBE at pascal.zaphodb.org>, "Tomas 
L. Byrnes" writes:
> Disclaimer: I have a dog in this fight, since ThreatSTOP is dependent on
> DNS/TCP.
> 
> >-----Original Message-----
> >From: Mark Andrews [mailto:Mark_Andrews at isc.org]
> >Sent: Thursday, May 14, 2009 4:59 PM
> >To: John Levine
> >Cc: nanog at nanog.org; rs at seastrom.com
> >Subject: Re: you're not interesting,was Re: another brick in the
> wall[ed
> >garden]
> >
> >
> >In message <20090514223605.88104.qmail at simone.iecc.com>, John Levine
> >writes:
> >> >Dear Sprint EVDO people,
> >> >
> >> >Your man-in-the-middle hijacking of UDP/53 DNS queries against
> >> >nameservers that I choose to query from my laptop on Sprint EVDO is
> >> >not appreciated.  Even less appreciated is your complete blocking of
> >> >TCP/53 DNS queries.
> >>
> >> If I were an ISP, and I knew that approximately 99.9% of customer
> >> queries to random name servers was malware doing fake site phishing
> or
> >> misconfigured PCs that will work OK and avoid a support call if they
> >> answer the DNS query, with 0.1% being old weenies like us, I'd do
> what
> >> Sprint's doing, too.
> >
> >	And what's the next protocol that is going to be stomped on?
> >
> >> If you're aware of a mechanical way for them to tell the difference,
> >> we're all ears.
> >
> >	Well you can't answer a TSIG message without knowing the
> >	shared secret so you might as well just let it go through
> >	and avoid some percentage of support calls.  Intercepting
> >	TSIG messages is guaranteed to generate a support call.
> >
> >	Similarly intercepting "rd=3D0" is also guaranteed to generate
> >	a support call.  You almost certainly have a interative
> >	resolver making the query which will not handle the "aa=3D0"
> >	responses.
> >
> >	Similarly there is no sane reason to block DNS/TCP other than
> >	they can do it.
> >
> [TLB:] I can think of an argument they might make: that it is/could be
> used by bots as a fallback. However, redirecting DNS/UDP fits the model
> of "providing a better service for the average user";
> blocking/redirecting TCP is more likely to break things a savvy user
> needs.

	There is still no sane reason to block TCP.  If they are
	intercepting DNS/UDP then they need to also intercept DNS/TCP
	as they will break all sites that cause "tc=1" to be set
	in the DNS/UDP reply.
 
> Maybe someone with clue at Sprint can be persuaded that doing their own
> "OpenDNS" for UDP is probably a good thing for most uses, but doing it
> for TCP is a bad thing for those users who need TCP.

	You can also add to the list of queries that you need to
	provide a clean path for any with DO=1, CD=1 or AD=1.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org