On 5 Jan 2017, at 23:33, Rick Moen <rick@???> wrote:

> Quoting Simon Hobson (linux@???):
>> Rick Moen <rick@???> 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.