If the user, despite ISP encouragement, chooses not to use a proxy, that should be his choice. He is paying for the bandwidth, and is assumed to be aware of the possible performance hit.
This was discussed in the vuln-dev mailing list after Comcast implemented transparent proxying.
This raised quite a stink when Comcast's logging habits were revealed. Oops.
There is obviously a performance degradation involved with re-resolving the address given to the cache server. Furthermore, requests now appear to be coming from the server, not the actual user -- potentially breaking host-based authentication systems.
I've also seen these cache systems horribly implemented. An IRC network that I administer recently starting checking for HTTP proxies on connection. This was performed by connecting to the remote user's host on certain ports (80, 3128, 8000, and 8080) and then issuing a CONNECT request. In more than one case, a blatantly stupid ISP redirected _incoming_ port 80 traffic to their server -- WITHOUT any sort of access restrictions on their proxy. Sort of ironic that they were probably using untold amounts of bandwidth for 1337 bounce kiddiots.
I believe that this is one of the/. articles where the value of the comments far exceeds that of the actual story.
I cannot begin to express my fustrations after having several IRC networks I administer smurfed ceaselessly -- one to the point of not returning for almost a year.
Kudos to those who have offered what little insign can be gleaned from these ignorant acts.
Shameless plug: directNIC offers registrations for 15USD for com/net/org domains. I'm not sure about other TLDs. They have, IMHO, a great management system, even though it "real" DNS costs extra. In the time I've been using them, the interface has improved exponentially. I have not had any problems with them.
Slashdot Mirror
If the user, despite ISP encouragement, chooses not to use a proxy, that should be his choice. He is paying for the bandwidth, and is assumed to be aware of the possible performance hit.
This was discussed in the vuln-dev mailing list after Comcast implemented transparent proxying.
This raised quite a stink when Comcast's logging habits were revealed. Oops.
There is obviously a performance degradation involved with re-resolving the address given to the cache server. Furthermore, requests now appear to be coming from the server, not the actual user -- potentially breaking host-based authentication systems.
I've also seen these cache systems horribly implemented. An IRC network that I administer recently starting checking for HTTP proxies on connection. This was performed by connecting to the remote user's host on certain ports (80, 3128, 8000, and 8080) and then issuing a CONNECT request. In more than one case, a blatantly stupid ISP redirected _incoming_ port 80 traffic to their server -- WITHOUT any sort of access restrictions on their proxy. Sort of ironic that they were probably using untold amounts of bandwidth for 1337 bounce kiddiots.
Proxying without consent is an Evil Thing.
First post :-)
I believe that this is one of the /. articles where the value of the comments far exceeds that of the actual story.
I cannot begin to express my fustrations after having several IRC networks I administer smurfed ceaselessly -- one to the point of not returning for almost a year.
Kudos to those who have offered what little insign can be gleaned from these ignorant acts.
If I were you, I'd ditch NSI.
Shameless plug: directNIC offers registrations for 15USD for com/net/org domains. I'm not sure about other TLDs. They have, IMHO, a great management system, even though it "real" DNS costs extra. In the time I've been using them, the interface has improved exponentially. I have not had any problems with them.
I'm not being paid to say this.