Il giorno Thu, 5 Jan 2017 02:26:25 -0800 Rick Moen <r...@linuxmafia.com> ha scritto:
> Quoting Alessandro Selli (alessandrose...@linux.com): > >> 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. > > Before I follow you further down this rabbit hole, I'm curious: Are > you still speaking about Devuan and its distro installer? Because my > understanding is that Devuan is not currently aspiring to have 'zero > questions asked' (your phrase) nor anything like the fewest possible > interactions with the installing administrator for the default > installation mode. I stated it very clearly: «*In my view*, the install program that asks the shortest list of questions is the best one for automated, bulk installations.» (emphasis added) > I have been assuming we were impliedly talking about the default > installation mode, not a non-default fully-automated mode nor a > non-default expert installation mode, or anything else of that sort. I am not entertaining this thread just for the sake of describing the status quo. Are you? Or is everyone proposing and debating proposals for a change? > I ask because your current posting meanders all over those things, which > is confusing, because that wasn't the conversation I thought I was > having, nor (I'm pretty sure) one I especially wish to (no offence > intended). Seems to me, we could spend ages discussing all of those > additional things, and, IMO, have little to show for it. You are under no obligation to participate in a discussion you do not like/think is a waste of your precious 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. > > Correct me if I'm mistaken: The default Devuan installer does promt the > user for nameserver IPs if the user is electing to supply a fixed IP > address for a network interface, right? Isn't this *exactly* what I wrote? If so, what is your point? > That would be where I said a > checkbox for '[ ] install and use a local recursive nameserver' would > be a trivial addition with disproportionately large benefits. I do not agree. I do not think a recursive nameserver would solve many of the the problems that caused a failed automatic resolver configuration. This option could of course be there (the install program would have falled into manual, interactive mode anyway), but IMO the benefits are going to be pretty limited. > Although certainly a host on dynamic IP _can_ make effective use of a > local recursive nameserver bound to localhost, I hadn't yet put > specific thought into where in the installer, if at all, it would > make sense to ask and to offer that enhancement. "If at all"? Are you backpedaling already? > I don't currently have time to ponder those specifics, but certainly > on some screen or other it would be perfectly feasible to offer that as > a checklist item. Wasn't the screen that checklist item was to be presented already put down? Shouldn't that be the screen that shows up when the user selects the manual interface configuration or the DHCP client fails DNS configuration? > Season to suit with '(Make sure you know what you're > doing)' advisories if you honestly think this causes significant failure > modes, which in my mere 35 years as a Unix admin have been nonexistent > other than captive portals on some hotel wifi except in one or two > client sites with such stiflingly severe border firewalling that damned > near nothing could talk to outside. But we'll get to those latter > situations, below. I already stated twice, if not three times, what specific situation and environment this solution would not address and solve: clamped-down telco datacenter networks. They evidently are not part of your experience, they are part of mine. >>> 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. > > Thank you for clarifying that by 'a local recursive DNS server needs > some administrative attention', you do not actually mean attention to > the software at all. What do you mean by "attention to the software"? Why do you think configuring the DNS to include forwarders does not constitute "attention to the software"? > You mean situations where outbound access to port > 53 on the outside Internet has been artificially blocked. I'm happy to see this notion is finally trickling through. > This is not what most people mean when they say 'needs some > administrative attention'. Configuring a local DNS recursive resolver indeed is, regardless of the reason one has to do it. > When you say 'selecting forwarders might be required', this describes a > rare -- and somewhat contrived (IMO) -- example situation where a > recursive nameserver has been, It's true if you only ever install Devuan in hotels with a decent Internet connection or at home, where you have full control of your network. Were you to regularly work in Enterprise/Telco datacenters then it would be a regularly wrong assumption. > in essence, artificially forbidden from > functioning as a normal recursive nameserver, except by handing off all > outbound queries to a _different_ (corporate-blessed) recursive > nameserver that has a gateway ACL permitting _it_ to open sockets to > arbitrary outside port 53. Which situation is one where operating > a recursive nameserver on the host being installed is pointless because > there already is a local recursive nameserver. That's precisely the reason I pointed out that having such a server does not constitute a fix-all solution to the problem at hand, that is handling the networking configuration where the DHCP client fails and setting alternate, public DNS servers fails as well. > So, to sum, it turns out that your example of the claim that 'of course > a local recursive DNS server too needs some administrative attention' > turns out to be a situation where a local recursive DNS server doesn't > make sense. > > Aha. I'm happy you finally got the point that there are circumstances where a local recursive DNS server doesn't make sense, it's far from providing the touted "disproportionately large benefits" and that in circumstances where DHCP DNS server config fails this solution could fail for the very same reasons, unless you take your time to configure it according to the local network layout and policies devoting it the needed administrative attention. > I don't think we would reasonably say 'Of course a Web browser too needs > some administrative attention' just because some networks don't permit > outbound sockets to 80/tcp on outside servers without configuring the > client Web software to send all outbound queries to a designated proxy > IP. Web browser configuration does not affect the installation process. However, installation would be affected were in effect web proxies that prevented the installer from accessing the repository servers directly. > I mean, such situations do exist, but making that claim without > explaining in the next sentence what specifically you mean would be > playing disputation games rather than having a conversation. I stated that several times: in telco datacenters that's the norm. In those networks you are administratively prohibited from accessing any Internet server other than the local DNS caching server and a short list of web sites accessible only throught a web proxy (mostly security advisory and documentation sites), and installation repositories are to be made local and accessible only through SSL/TLS sockets. >> [...] >> >>> 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. > > Obviously, (1) I wouldn't (and didn't) suggest BIND9, Irrelevant, the point holds true no matter what specific implementation of a recursive DNS server you install. > and (2) a > recursive nameserver indeed is not going to be able to function normally > by default in networks that artificially prevent recursive nameservers > from functioning normally. Which means that in a number of circumstances where the DHCP client fails to configure DNS and the user has to intervene manually the local recursive resolver is not going to be of any help, it's going to fail for exactly the same reasons unless it's administratively taken care of. > You see the latter as a problem. Indeed I do consider missing DNS service a problem. > I do not *What*? > -- for the same reason I > don't see it as a problem for a Linux distro (generically; it doesn't > matter for present discussion whether Devuan offers this or not) to be > able to install and turn on an MTA just because some networks don't > allow outbound access to 25/tcp except via corporate-specified gateway > IPs. Irrelevant: you do not need SMTP to perform a Devuan install/upgrade, but you do need DNS if you're preforming a network install or an install that fetches elective packages from remote repositories or that performs a system upgrade during or right after the base installation. > So, yay, you have a view; I don't share it because I think it's a bit > silly. It's not any silly if you are to perform an install in a corporate, locked-down datacenter. The fact that you never had to operate in such an environment and that no customer of yours ever run such a network is moot. -- Alessandro Selli http://alessandro.route-add.net VOIP SIP: dhatarat...@ekiga.net Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
