Re: [RFC] DNS system upgrades

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? 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)".

However, again, this is not my area so perhaps a hodgepodge of
/etc/resolv.conf info and dns_nameservers info is better.

Thank you,

Alex.

> What you point at is another behaviour I had forgotten.
>
> 5) We should make etc/resolv.conf provide the defaultsfor dns_defnames,
> dns_nameservers, append_domain squid.conf options and have them override
> resolvconf.
>
> The way append_domain and dns_nameservers work that appears to have been
> the intention originally.
>
>
>>
>>> Administrators who do not want it are supposed to be using the
>>> alternative "domain" directive, when they use tools like host or
>>> nslookup to debug they should see consistent behaviour (diverting them
>>> away from Squid to the actual DNS issues in resolv.conf settings), and
>>> this will prevent future confusion such as appears to be happening in
>>> bug 3585.
>>
>>> 3) removal of dnsserver and related code.
>>>
>>> IRIC the argument for keeping it previously was NetBIOS or WINS name
>>> lookup still being needed (though I am suspicious the dns_defnames issue
>>> was the actual cause of this).
>>>
>>> - NetBIOS was deprecated in 2000, to be replaced by DNS
>>> - WINS was deprecated in 2012, to be replaced by IPv6
>>> auto-configuration / adhoc services.
>>>
>>>
>>> I am okay to see this delayed a few more squid series to give WINS
>>> longer to die, but it is time we looked again at why it is still there.
>>>
>>> Since the last round of discussion we adjusted the internal engine to
>>> fix most of the remaining issues. The above dns_defnames behaviour
>>> change is the last bit I am aware of that is needed for a seamless
>>> upgrade, short of full-blown NetBIOS support integration which is not
>>> very feasible.
>>
>> All three items above sound good to me, but this is not my area of
>> expertise so I hope others will chime in.
>>
>> The WINS-related decision may be worth discussing on squid-users as well.
>
> If we can't findany reasons against that is the next step. Henrik was
> quick enough to provide reasons to keep it last time without bothering
> many people.
>
> Amos
Received on Wed Feb 20 2013 - 21:21:01 MST