you're not interesting, was Re: another brick in the wall[ed garden]
Mark_Andrews at isc.org
Thu May 14 19:37:41 CDT 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
> >-----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
> >In message <20090514223605.88104.qmail at simone.iecc.com>, John Levine
> >> >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
> >> 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
> >> 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
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 Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the NANOG