> > Correct, I don't believe that any of the providers noted are actually
> [snip]
> Disappointing that nanog readers can't read
> http://www.paxfire.com/faqs.php and get
a clue, instead all the mouth-flapping about MItM and https. a clue,
> instead all the mouth-flapping about MItM and https. While
Maybe instead of jumping to the conclusion NANOG readuers should "get a
clue",
you should actually do a little more research than reading a glossyware/
vacant FAQ that doesn't actually explain everything Paxfire is reported to
do, how it works, and what the criticism is?
I'm not jumping to conclusions, merely speaking to evidence. My
personal experience involves leaving a job at a network that
insisted on implementing some of this dreck. There is a well-known,
long-standing "monetization" by breaking NXDOMAIN. DSLreports
and plenty of other end-user fora have been full of information
regarding this since Earthlink starded doing it in ... 2006?
Changing NXDOMAIN queries to an ISP's _own_ recursive servers is old hat,
and not the issue.
That sentence makes no sense. Hijacking NXDOMAIN doesn't have anything
to do with pointing to a recursive resolver, but returning a partner/
affiliate web site, search "helper" site or proxy instead of the
NXDOMAIN.
What the FAQ doesn't tell you is that the Paxfire appliances can tamper
with DNS
traffic received from authoritative DNS servers not operated by the ISP.
A paxfire box can alter NXDOMAIN queries, and queries that respond with
known search engines' IPs.
to send your HTTP traffic to their HTTP proxies instead.
barefruit/paxfire/nominum/etc all do essentially the same thing:
1) install a dns-appliance in-line (some form of in-line, there are
lots of options, it's not really important in the end which is used)
between 'cache resolver' and 'user'. (198.6.1.1 has a paxfire
appliance literally in-line between it's customer facing port and the
world)
2) chose a set/subset of queries to falsify answers for (nxdomain
only? autosearch.msn.com? *.google.com? *?)
In the case of barefruit it's another complex and in the case of
nominum it's a third complex ...
4) accept http/https/etc on the complex of servers, funnel you an
answer which is essentially 'hostname == search-query'. For non-http
most of these complexes are SUPPOSED to not permit a connect to
happen... for jomax at least they don't accept tcp/443, they do accept
25 though
5) profit if users click on these results.
It's not black magic, it's annoying and wrong for some versions
(depending upon your ethics I guess?) of wrong I wish ISP's would
stop doing this, and it seems that some folk have luck twisting arms
at ISP's to make this stop.
> Not trying to be obtuse, but none of the technical docs you cite appear
to
> talk about HTTP proxies nor does the newswire report have any technical
> details. I have tested several of the networks listed in the report and
in
> none of the cases I saw was there HTTP proxy activity. Picking up on
> WCCP/TCS isn't that hard (I used to install those myself) so unless
there is
> some functionality in IOS and/or JUNOS that allows I don't see it
happening.
> Paxfire can operate all of the proxies they want but the network
> infrastructure has to be able to pass the traffic over to those proxies
and
> I don't see it (on at least 3 of the networks cited).
barefruit/paxfire/nominum/etc all do essentially the same thing:
1) install a dns-appliance in-line (some form of in-line, there are
lots of options, it's not really important in the end which is used)
between 'cache resolver' and 'user'. (198.6.1.1 has a paxfire
appliance literally in-line between it's customer facing port and the
world)
2) chose a set/subset of queries to falsify answers for (nxdomain
only? autosearch.msn.com? *.google.com? *?)
3) run a farm of servers somewhere else (in the case of paxfire they
are the jomax.net servers:
;; QUESTION SECTION:
;asdkjad912jd.123adsad.com. IN A
;; ANSWER SECTION:
asdkjad912jd.123adsad.com. 60 IN A 64.158.56.49
asdkjad912jd.123adsad.com. 60 IN A 63.251.179.49
;; AUTHORITY SECTION:
asdkjad912jd.123adsad.com. 65535 IN NS WSC2.JOMAX.NET.
asdkjad912jd.123adsad.com. 65535 IN NS WSC1.JOMAX.NET.
In the case of barefruit it's another complex and in the case of
nominum it's a third complex ...
4) accept http/https/etc on the complex of servers, funnel you an
answer which is essentially 'hostname == search-query'. For non-http
most of these complexes are SUPPOSED to not permit a connect to
happen... for jomax at least they don't accept tcp/443, they do accept
25 though
5) profit if users click on these results.
It's not black magic, it's annoying and wrong for some versions
(depending upon your ethics I guess?) of wrong I wish ISP's would
stop doing this, and it seems that some folk have luck twisting arms
at ISP's to make this stop.
-chris
Some people believe the search results are a better user experience than the
error page they would otherwise receive. The "awesome bar" is a similar
feature....imho
sure, but users requested that 'feature' and it's there for only
http/https traffic. it's not being done at the lower layers of the
stack, for all applications off the client machine.
messing with basic plumbing will have unintended consequences, they will be bad.
If the users her WANT to have this experience, there are lots of
in-browser/application methods to achieve this, hijacking DNS at the
resolver is really just NOT the right answer, ever.
messing with basic plumbing will have unintended consequences, they will be bad.
If the users her WANT to have this experience, there are lots of
in-browser/application methods to achieve this, hijacking DNS at the
resolver is really just NOT the right answer, ever.
See that ship off on the horizon? It appears to have sailed...
doesn't mean I can't be the cranky old man shaking my fist, right?
I'm told that non-trivial revenue is being generated by ISPs who are doing this redirection. As long as that is true, I suspect it's unlikely pointing out how broken hijacking DNS is will be particularly effective.
yea... so that, so I understand, depends a lot on who's telling the
tale. From one source at an ISP doing this, the revenues are not
anywhere near what was promised by the vendor(s). Anyway, I'm not sure
what they are, we probably won't ever know what they really are
I suppose it'll continue as long as people consider it 'ok' to be
subjected to this and don't leave their ISP for an alternative. (where
available!) Oh, maybe dns-sec will help us with this problem too?
nsec3 to the rescue?
