On 5 Jan 2017, at 23:33, Rick Moen <r...@linuxmafia.com> wrote:
> Quoting Simon Hobson (li...@thehobsons.co.uk):
>> Rick Moen <r...@linuxmafia.com> wrote:
>>
>>> Without objection, I'll point out that one leading advantage of a local
>>> recursive server (what you probably mean when you say 'caching DNS
>>> server'[1]) is that it Just Works
>>
>> Unless you are in one of the situations previously mentioned where it
>> doesn't ...
>
> I didn't think it necessary to belabour the fact that if a network
> daemon, one that inherently needs open Internet access to work, is
> prevented from having open Internet access, it won't work.
>
> Some folks love playing Edge-Case Theatre, and will happily do so all
> day long and fill up mailing lists with it.
I think you have somewhat missed the point in all this.
What started as reference to ${someone} hardcoding what most of us consider
asinine behaviour into some resolver code - and led onto a discussion of how
should Devuan do it better. Both the asinine behaviour, and the other
suggestions, have been specifically to work around edge-cases.
IMO, if we don't get working DNS* via DHCP then the network is broken and my
approach is to say "fix the network".
IFF we are going to put stuff in to work around problems for one set of edge
cases (and IMO it's debatable whether we should), then why not also cater for
what is possibly a larger group of edge cases ? Your argument seems to be "this
is the only set of edge cases I'm prepared to consider - ignore the others".
So lets narrow it down to a simple question. Do we want/need to cater for a
very small minority who suffer from one of a number of edge cases of broken
networking ? Yes or No ?
If the consensus is Yes - then just installing a local resolver does not fit
the bill, it only solves the problem for one small subset of those corner cases.
If the consensus is No - then there's no need to install a local resolver at
all as it doesn't "fix" anything that's not already working (at least to the
extent that the installer needs).
What happens AFTER install is another matter - and as has been pointed out
previously, the user/admin can decide for him/herself how to manage their own
priorities.
* Yes I've noted objections about suboptimal DNS from ISPs and stuff like that
- but while it may mess with TTLs and stuff, it does mostly "work" to the level
needed for an installer to function.
And for the record, I can only recall two instances of having to manually enter
DNS servers because DHCP didn't give me the right ones. Both are on networks at
work which are part of customers' installations. One had DHCP giving out the
wrong address (because AD servers had been moved) - so I fixed the DHCP. One is
a special case because there's some shared networking going on, so to work in
the customer's environment means manually over-riding what DHCP gives out
(which is itself working DNS) with customer-specific information - which is
most definitely in the "if you can't configure it yourself, you shouldn't be
working on that network anyway" and thus irrelevant to the discussion.
That's leaving aside captive portals in hotel environments - and yes, I've come
across those where DNS is blocked so a local resolver won't do diddly squat for
you. I do wonder though - do many people really install system software in such
environments ?
PS - thank you very much for your earlier essays on the various DNS
server/resolver options. It has been interesting to read - given that I too
manage DNS for hundreds of domain names with my work hat on. We use BIND9 -
mostly because it's what I know and we've never seen any issues sufficient to
justify the work in changing.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
