Henrik, thanks for your reply.
Henrik Nordstrom wrote:
Make sure that /etc/resolv.conf (or squid.conf) contains your ISP name servers,
The problem is not that the contents of resolve.conf are wrong. They are always correct. The problem is that squid doesn't change its nameserver settings to reflect changes in resolve.conf.
I have tried putting the ISP nameservers after the first two lines of resolve.conf (ie, as lines 3 and 4), but this has the undesirable side-effect that each access to a new site waits for the nameservers listed in the first two entries to timeout before the page can be fetched. (I notice that squid subsequently caches the DNS server that worked for that site, so subsequent fetches from that site are fast - nice).
> or run a caching DNS locally.
That was one of my initial thoughts. I can't remember anymore if NAMED responds dynamically to changes in resolve.conf. Regardless, I wanted to find out if this could be fixed by adjusting squid, before bringing another process into the mix.
Alternatively modify your ADSL connect script to issue a "squid -k reconfigure" after successful connection.
I have also considered this. What is actually needed is a "squid -k reconfigure" whenever resolve.conf changes, which is whenever an interface is brought up or down that has PEERDNS set to true.
Eg, if I shut down ADSL and bring up the LAN interface (in the office) then I need a "squid -k reconfigure" as well.
One solution is to put a "squid -k reconfigure" into my "ifup-local" script. The problem there is that these mods almost always get lost when upgrading/reinstalling the distro.
I have also looked at the workings of "ifup-post", which calls a do_netreport() function. This iterates all the files in /var/run/netreport, and sends the process identified by each a "kill -SIGIO" signal. Would this work for squid?
Squid doesn't seem to enable this automatically, so I presume I would have to modify the startup script in /etc/init.d, meaning that the changes will also most probably be lost on an upgrade.
A different solution would be to have squid detect that resolve.conf has changed, and do the reconfigure automatically. To avoid the inefficiency of polling a file system object, I would propose that squid checks if resolve.conf has changed whenever it gets a timeout from the first nameserver from resolve.conf.
I am happy to look at the code and create a patch if I can. However, there's no point doing so if it is unlikely to be accepted into the production version. What are people's thoughts?
Are there any better solutions I've missed?
Cheers! Nik.
PS: do people prefer to be included in the reply list, or to only get replies via the mailing list?
