In message <70d072392e56884193e3d2de09c097a91f3...@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_andr...@isc.org]
> >Sent: Thursday, May 14, 2009 4:59 PM
> >To: John Levine
> >Cc: nanog@nanog.org; r...@seastrom.com
> >Subject: Re: you're not interesting,was Re: another brick in the
> wall[ed
> >garden]
> >
> >
> >In message <20090514223605.88104.qm...@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_andr...@isc.org
