On 21/02/2013 10:20 a.m., Alex Rousskov wrote:
On 02/20/2013 01:46 AM, Amos Jeffries wrote:
On 20/02/2013 8:45 p.m., Alex Rousskov wrote:
On 02/19/2013 05:08 PM, Amos Jeffries wrote:
2) adapting append_domains from a string type to a custom type
This will allow us to do additional configuration validation. Such as
identifying whether resolv.conf or squid.conf was used as data source.
* auto-enablling dns_defnames search list
/etc/resolv.conf contains two similar but different directives for
labelling the local domain name.
The "search" directive in particular signals DNS searching of multiple
domains to the default host resolver. But Squid still requires explicit
"dns_defnames on" in squid.conf to enable that behaviour. As a result we
have administrators seeing a 'bad' difference between internal and
dnsserver when they try upgrading to internal DNS.
I propose using the resolv.conf hint to enable dns_defnames searching
automatically in the absence of explicit squid.conf configuration.
By "explicit squid.conf configuration", you mean the dns_nameservers
option, right? In other words, if dns_nameservers is given, the entire
/etc/resolv.conf is ignored. Otherwise, both "nameserver" and "search"
directives in /etc/resolv.conf are honored, correct?
No I meant "dns_defnames on" is needed explicitly in squid.conf to
enable DNS search behaviour the search settings loaded from resolv.conf
should have meant in the first place. The default squid.conf does not
honour the search part of teh setting.
Will enabling dns_nameservers disable any use of /etc/resolv.conf?
Yes in the crurrent Squid dns_nameservers disables loading of
resolv.conf entirely.
I disagree on this being a desirable order of preference, but that is
outside the proposed change.
I'm only proposing for now that dns_defnames directive be enabled *if*
resolv.conf is loaded containing search directive and nothing is in
squid.conf setting it explicitly.
I
think there should be an easy way for an admin to disable all
/etc/resolv.conf use and rely on squid.conf settings exclusively. Use of
dns_nameservers may be a good trigger for that.
In other words, I do not think Squid should pick up search clues from
/etc/resolv.conf when the admin explicitly configured dns_nameservers.
It feels like that would lead to messy configurations where the admin
will not know for sure where the information is coming from. We should
warn when options contradict each other.
If there is a conflict, I think our preference should be towards "works
as expected" rather than "external DNS works as internal DNS (and so it
is easy to switch from former to the latter)".
... which to me means Squid always loading resolv.conf first and obeying
its instructions, then overriding particular aspects of that behaviour
with squid.conf settings.
The current expectation is that with a default squid.conf the command
line "host foo" and "squidclient http://foo/"; will both respond with
something indicating 127.0.0.1 as the server. As of today the
squidclient response is "Domain Not Found".
Amos
