:: Re: [DNG] how to clear DNS cache
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Alessandro Selli
Fecha:  
A: dng
Asunto: Re: [DNG] how to clear DNS cache
Il giorno Wed, 4 Jan 2017 15:11:36 -0800
Rick Moen <rick@???> ha scritto:

> Quoting Alessandro Selli (alessandroselli@???):
>
>> This is something that belongs to a different stage in the OS
>> installation, when:
>>
>> 1) the user determined that a DNS server must be installed;
>> 2) that it has to run as a local recursive nameserver;
>> 3) that a particular implementation of such a server must be installed.
>
> This view amounts to 'consign it to an expert installation profile', which
> then is functionally the same as 'don't bother', as discussed below.
>
> I should stress that I didn't _literally_ have in mind the installer
> offering the user all five open source recursive nameservers for Linux.
> I showed all five checkboxes to stress the breadth of options _all_ of
> which are being ignored -- even in your amazing and rather amusing list.


I followed the same logic when I listed 26 alternate public DNS servers to
choose from. I know it contradicts my own argument that the install program
should ask the fewest possible questions.

>> I think most people will be either put off by such a question (the non
>> techies) or they will bemoan the amount of detailed questions they must
>> answer to get a basic system installed when they're in a hurry/have to
>> install a number of systems together.
>
> This logic leads to Ubuntu. ;->


I acn't see anything wrong with it. If you have technical arguments
against such a layout please feel free to elaborate. In my view, the install
program that asks the shortest list of questions is the best one for
automated, bulk installations.

> I'm certainly not offended by droolproofed distro installers that ask
> the fewest possible questions of an installing user; I merely note the
> lost opportunity.


I cannot see why such an install program would miss any opportunity. Not
bothering the user with countless questions, defaulting to an automated,
unattended install does not prevent the user from selecting at the start an
expert install path where he/she'll be free to select all the most diverse
options.

> There is obviously a happy middle ground.


Yes, it's called: "let the user decide". Level (0) menu:

A) Let the install program choose all the required settings (basic, no-frills,
automatic install, zero questions asked) [Default]
B) Customize the system at install time

> I'm
> merely suggesting that if you're already offering a screen to input the
> IPs of recursive nameservers (and Devuan is), then a checkbox for a
> local recursive nameserver is a trivial addition with disproportionally
> large benefits.


I agree, however IPs are input manually in the case the user elected to do
so (as in a manual interface configuration) or when automatic interface
configuration failed.

>> This goes too far from solving the problem of getting a network
>> interface up and working in the shortest possible time imposing the
>> smallest possible amount of hassle on the user in order to get the
>> damned thing installed.
>
> Actually, I misstated slightly: This logic leads to Klaus Knopper's
> bulk-installation Python script 0wn (= 'zero work needed') in Knoppix,
> http://www.knopper.net/knoppix/0wn-en.html. I admire that script,
> really. It offers breathtakingly little opportuntiy to tweak anything,
> just bulk-installs the entirety of Knoppix to a target drive
> (overwriting the HD and autopartitioning[1]), prompts for hostname, prompts
> for IP & nameserver IP, prompts for root & user auth details, prompts
> for hostname, installs a bootloader, and exits.


WOW, it prompts for so many things! ;-)

> But I'm glad
> less-automagic installation exists.


The availabilty of a fully automatic install does not prevent the
possibility of performing a semi- or fully-manual install per se. Just
like an automatic sudo configuration and a root user with login disabled
does not prevent people from having a regular, old-time Unix system with a
fully functional superuser.

>> Of course a local recursive DNS server too needs some administrative
>> attention, though it is simpler than an authoritative one.
>
> I don't mean to sound hostile, but _what_ administrative attention?


I already stated that selecting forwarders might be required to let the DNS
server work in a given environment. In all the telco datacenters where I
operated internal nodes where not allowed to perform recursive queries on
their own.

[...]

> Point is, the user can be offered a local recursive nameserver (I
> suggest Unbound on grounds of code quality and clean implementation)
> running and made _the_ nameserver bound to loopback and accessible from
> localhost only by default. This can and IMO should be presented as a
> simple thing.


I cannot see how this layout can solve the problems peculiar networks
present to the regular, DNS-server free install program. You are just
shifting the issue from /etc/resolv.conf to /etc/bind/named.conf.

> Consigning it to an 'expert installation profile' means
> the only people who'll use it (in practice) are the same people who
> already can and do use the 'expert installation profile' called root
> shell:


To me the ideal install program installs and activates the smallest number
of daemons. One of the things that bother me most about Ubuntu and Fedora
installations is the amount of clean-up time I spend removing the several
dozen packages that I do not need and do not want but were installed
nonetheless. All servers that are not required to install and run a basic
system should be installed by the user at a second time. This is a
requirement also for installations on embedded devices and, again, in several
telco or Enterprise environments.

[...]

>> And please keep in mind that in many Enterprise networks nodes are not
>> allowed to perform recursive queries on their own....
>
> If this matters, the installer could attempt a dig of devuan.org's DNS,
> and if it doesn't work, tell the user 'the recursive nameserver you
> requested isn't going to work here'.


This could have the side effect of having the box flagged as a misbehaving
node, besides beeing the test a non definitive answer. There are several
causes that could make a DNS resolution temporarily fail. An install program
should not rely on such a test.

> I am _not_ making this suggestion
> because I suspect blocking or intercepting outbound traffic to port 53
> is really rare,


It depends, in some places is common practise.

> but _if_ concerned, that would be the logical response.
>
> If by 'allowed' you mean 'the company wouldn't like it', then there are
> plenty of other contents in Devuan that particular corporations aren't
> going to like, either.


Call them customers, and you get my reply even before I expound it.
"What" would they not like? Corporations want a system that gets the work
done and that sits well with the rest of the infrastructure. Boxes that
trigger the firewall are not welcome.


--
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarattha@???
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9