> > Makes sense. In the current code, if the test for ttl == 0 is > removed, it should set the '0' case to the negative TTL rather than > the positive one, which would be better in all cases, I think. >
Given that. I'd agree. However is negative-ttl limited to being 1 or more itself? Amos > > On 2007/10/11, at 3:06 AM, Duane Wessels wrote: > >> >> >> >> On Wed, 10 Oct 2007, Mark Nottingham wrote: >> >>> From ipcache.c; >>> >>>> if (ttl == 0 || ttl > Config.positiveDnsTtl) >>>> ttl = Config.positiveDnsTtl; >>>> if (ttl < Config.negativeDnsTtl) >>>> ttl = Config.negativeDnsTtl; >>>> i->expires = squid_curtime + ttl; >>> >>> As I read this, if the TTL from an upstream resolver happens to be >>> '0', it changes it to whatever positive_dns_ttl is -- even though >>> that also acts as a ceiling for DNS TTLs. >> >> I think this is partly left over from the old days when Squid always >> used the external dnsserver programs. 'dnsserver' could only report >> TTLs if the O/S had the libresolv _dns_ttl hack. So "ttl == 0" >> meant that dnsserver didn't have any TTL value, so it should be set >> to positive_dns_ttl. >> >>> The problem is that this plays havoc with DNS-based load >>> balancers, which will be '0' more often than other DNS entries by >>> nature. Any chance of either; >> >> The only thing I'm worried about is that with true 0 TTL squid will >> have to make multiple lookups for a single HTTP request. For >> example, if someone had a long list of 'dst' ACLs then each one >> could result in a new DNS lookup. >> >> AFAIK, the ipcache is the only place where DNS lookups are cached >> and Squid may refer to the ipcache multiple times for a given HTTP >> transaction. >> >> DW > > -- > Mark Nottingham [EMAIL PROTECTED] > > >
