Disclaimer: I have a dog in this fight, since ThreatSTOP is dependent on DNS/TCP.
-----Original Message----- From: Mark Andrews [mailto:Mark_Andrews@isc.org] Sent: Thursday, May 14, 2009 4:59 PM To: John Levine Cc: nanog@nanog.org; rs@seastrom.com Subject: Re: you're not interesting,was Re: another brick in the wall[ed garden]
In message <20090514223605.88104.qmail@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=0" is also guaranteed to generate a support call. You almost certainly have a interative resolver making the query which will not handle the "aa=0" 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. 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.