Hi Replying to the list
Yes i get that error on many different sites same exact error about host headers. Also if you watch the TTL on the amazonaws url i provided it changes from 3 to 5 to 10 seconds to 60 to 10 back and forth. If you go online to an dns lookup site like kloth i see via kloth 5 seconds TTL i get a different TTL value at different times, it appears they dont have a set TTL but they change it often and it varies. Right now it appears to be a ttl of 60 seconds as you found but earlier and over the weekend it has shown 5 seconds and even AWS support verified it can vary as low as 5 seconds. That being said , when it is changing every 3-5 seconds which comes and goes , squid gives the header forgery errors as shown before. On Tue, Oct 18, 2016 at 12:30 PM, <gar...@comnet.uz> wrote: > On 2016-10-18 18:32, John Wright wrote: > >> Hi, >> >> I have a constant problem with Host header forgery detection on squid >> doing peek and splice. >> >> I see this most commonly with CDN, Amazon and microsoft due to the >> fact there TTL is only 5 seconds on certain dns entries im connecting >> to. So when my client connects through my squid i get host header >> issues due to the contstant dns changes at these destinations. >> >> I have ready many things online but how do i get around this. I >> basically want to allow certain domains or ip subnets to not hit the >> host header error (as things break at this point for me ). >> >> Any ideas ? >> >> One example is >> >> sls.update.microsoft.com [1] >> >> Yes my client and Squid use same DNS server, i have even setup my >> squid as a bind server and tried that just for fun same issue. Fact >> is the DNS at these places changes so fast (5 seconds) the dns >> response keeps changing/ >> >> I just need these approved destinations to make it through >> >> >> >> Links: >> ------ >> [1] http://sls.update.microsoft.com/ >> > > Hi, > > Are you sure, that Squid and all your clients use same _caching_ DNS > server? For example, here results from my server for name > sls.update.microsoft.com: > > $ dig sls.update.microsoft.com > ... > sls.update.microsoft.com. 3345 IN CNAME > sls.update.microsoft.com.nsatc.net. > sls.update.microsoft.com.nsatc.net. 215 IN A 157.56.77.141 > ... > > > Second request after 3 seconds: > > $ dig sls.update.microsoft.com > ... > sls.update.microsoft.com. 3342 IN CNAME > sls.update.microsoft.com.nsatc.net. > sls.update.microsoft.com.nsatc.net. 212 IN A 157.56.77.141 > ... > > > Here I see that the TTL for the target A record is 300 seconds (not 5 > seconds), and _caching_ DNS server will serve same A record for all clients > at least 5 minutes. That behaviour will not introduce false positives for > host forgery detection. > > > > On other hand, if the DNS server is not _caching_, you would get different > A records for each request. For example, below are results from > authoritative DNS server for zone nsatc.net: > > > $ dig @e.ns.nsatc.net sls.update.microsoft.com.nsatc.net > ... > sls.update.microsoft.com.nsatc.net. 300 IN A 157.55.240.220 > ... > > > Second request after 5 seconds: > > $ dig @e.ns.nsatc.net sls.update.microsoft.com.nsatc.net > ... > sls.update.microsoft.com.nsatc.net. 300 IN A 157.56.96.54 > ... > > > Here I see, that the DNS server serves exactly one A record in round-robin > fashion. Same true for Google public DNS services. That behavior could > cause troubles for host forgery detection. > > HTH > > Garri > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users > -- Thank you for your time, John Wright
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
