Re: [RFC] DNS system upgrades

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 21 Feb 2013 19:09:29 +1300

On 21/02/2013 6:15 p.m., Alex Rousskov wrote:
> On 02/20/2013 06:56 PM, Amos Jeffries wrote:
>
>> 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.
> Yes, that would make sense to me: If the admin wants to use resolv.conf,
> we should use all of it by default.
>
>
>>> 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.
> I see your point. However, it may be better to simplify expectations
> when admin starts tweaking things by using an "either resolv.conf or
> squid.conf" principle. It would be unusual and unnatural, IMHO, to
> specify domain names manually in squid.conf but then rely on resolv.conf
> for "search" patterns so I am guessing most admins would not expect that
> kind of combination.

But we do the opposite on all other directives...
* "nameserver" loaded from resolv.conf and search path overridden by
append_domain.
* "domain" loaded from resolv.conf and overridden by dns_defnames.

> One possible solution to clarify choices and minimize complex
> dependencies is to group these options. The admin would have to pick one
> of the following two approaches:
>
> # either use these resolvers, with these options:
> dns_resolution \
> resolvers=ip1,ip2,ip3 \
> search=tld1,tld2 \
> ...
>
> # or use resolv.conf, possibly overwriting some of its settings:
> dns_resolution \
> config=/etc/resolv.conf \
> search=... \
> ...
>
> with the following being the default (no overwriting):
>
> dns_resolution \
> config=/etc/resolv.conf
>
>
> I may be missing some details here, but I hope the above illustrates the
> overall approach.

I understand what you mean but am not understanding why it is a good
thing rather than simply documenting our directives individually as:

  "Squid loads the operating system DNS settings from /etc/resolv.conf.
This directive overrides and replaces the XX feature of resolv.conf"

Nothing complex or unexpected about that behaviour. It is already true
for all the other directives when dns_nameservers is omitted (which is
default).
The only complexity is due to dns_nameservers disabling the entirety of
resolv.conf loading.

Amos
Received on Thu Feb 21 2013 - 06:09:42 MST

This archive was generated by hypermail 2.2.0 : Thu Feb 21 2013 - 12:00:06 MST