[114557] in North American Network Operators' Group
RE: you're not interesting,
daemon@ATHENA.MIT.EDU (Tomas L. Byrnes)
Thu May 14 20:24:44 2009
Date: Thu, 14 May 2009 17:24:26 -0700
In-Reply-To: <200905142358.n4ENwWPM094667@drugs.dv.isc.org>
From: "Tomas L. Byrnes" <tomb@byrneit.net>
To: "Mark Andrews" <Mark_Andrews@isc.org>,
"John Levine" <johnl@iecc.com>
Cc: nanog@nanog.org, rs@seastrom.com
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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=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.
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.
