Thank yu very much! Yes Im aware of DNS possible issues 2013/9/25 Amos Jeffries <squid3@xxxxxxxxxxxxx>: > On 25/09/2013 6:30 p.m., Luis Daniel Lucio Quiroz wrote: >> >> Hello :) >> >> For a reason, dont ask. I need to configure a Squid that is able to >> do reverse lookup from a webapp that does dinamic hostdomains. So i >> need to configure a squid that does *.mydomain. >> >> I dont have too much control on *.mydomain IP's, so cache_peer wont be >> very helpful in this case. I need to relay in DNS for this. Is it a >> way to make this work? > > > If you use DNS in the reverse-proxy to access the origin servers you will > need even more control of the IPs than you do with cache_peers. Since both > configurations require the public DNS needs to be configured to point the > clients at your proxy. But a reverse-proxy without cache_peer *also* > requires a reliable split-DNS configured because those DNS servers become > responsible for preventing forwarding loops and must not send Squid the same > IPs which are going to the clients. > > The configuration in Squid is simple, but leaves you open to a new set of > DNS-related security problems such as DNS spoofing or hijacking in addition > to the regular HTTP security issues. > > Starting with the simple virtual-hosting reverse proxy configuration: > http://wiki.squid-cache.org/ConfigExamples/Reverse/VirtualHosting > > * You drop the cache_peer directives. > > * You replace the cache_peer_access with always_direct. > always_direct should use the same ACL rules as you would have placed on > cache_peer_access. > > NP: When defining the dstdomain ACL of hostnames you can use the wildcard > form of dstdomain: > acl outsites dstdomain .mydomain.local > > HTH > Amos
