Re: [RFC] DNS system upgrades

On 20/02/2013 8:45 p.m., Alex Rousskov wrote:
> On 02/19/2013 05:08 PM, Amos Jeffries wrote:
>> A few things are on my radar that need improving in the Squid DNS
>> components. I am proposing these as a batch, any which we can agree on
>> will be scheduled for fixing in 3.4.
>>
>>
>> 1) renaming all DNS options to begin with dns_* prefix.
>>
>> This will allow the cfgman documentation to collate these options
>> together as a batch in future.
>> Also clarify what component in Squid some of the more obscure options
>> relate to.
>> Also, allow for some future upgrades compacting these type of options
>> into a single component directive / command line interpreter simplicity.
>>
>> Options affected that I'm aware of:
>> append_domain
>> ignore_unknown_nameservers
>> hosts_file
>> cache_dns_program ... (stripping the cache_ part.)
>>
>>
>> NP: at this point I am on the fence about adding the prefix to fqdncache
>> and ipcache options and *not* proposing a change to them.
>>
>>
>>
>> 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.

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 - 08:46:39 MST