:: Re: [DNG] web conferencing software…
Top Page
Delete this message
Reply to this message
Author: Rick Moen
Date:  
To: dng
New-Topics: [DNG] Motel wifi: was web conferencing software
Subject: Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting Steve Litt (slitt@???):

> If I had demanded of myself to change the root cause instead of
> coathangering the symptom, I'd have needed to go to the Void Linux
> developers and ask them to find a way to accommodate DNS, in a
> travelling situation, without changing /etc/resolv.conf.


[acknowledging your point, posted separately, that Void Linux devs could
doubtless cite some way to do so, if you asked them.]

> What I was trying to say was that if I wanted to change the *design* of
> the system, I'd have to petition the Void Linux packagers and the (urk)
> Freedesktop.org "upstream".

[...]
> I violently disagree with the design decision of having the likes of
> wicd or NetworkManager modify my /etc/resolv.conf, at least on a
> non-portable desktop. Even on a laptop, today you can DNS from 8.8.8.8
> and 8.8.4.4 anywhere you go, so there's no need to use the local ISP's
> suggested DNS servers.


(I'll get to the 'no need' statement further down.)

I doubt you _truly_ aimed at a system redesign to the effect that
"Nothing shall be allowed to touch /etc/resolv.conf except me doing
'chattr -i /etc/resolv.conf; vi /etc/resolv.conf; chattr +i /etc/resolv.conf'."
Because there are legitimate reasons to do otherwise.


TCP/IP-networked systems fall into two broad classes, those that are
DHCP clients and those statically IPed.

Statically IPed systems are the easy case, I cannot presently think of
any system software sysadmins are tempted to run that would want to
alter /etc/resolv.conf . That leaves DHCP clients.

There are three DHCP client implementations I'm aware of for Linux.
My Resolvconf page (link posted earlier) explains how to control what
each does to the nameserver line(s) in /etc/resolv.conf . So, I've
documented how to override and control (if desired) those system utilities'
mucking about. Likewise, My page details how to do likewise with either
of the two competing Resolvconf implementations (which is why the page
has that name).

That leaves 'network managers' like GNOME NetworkManager, wicd, and all
that lot. wicd appears to invoke Resolvconf to manage /etc/resolv.conf,
so see above.

GNOME NetworkManager keeps its grubby paws off /etc/resolv.conf if that
file's a symlink (including but not limited to use of Resolvconf, which
like wicd, GNOME NetworkManager relies on). So, do that. _Or_, create
/etc/NetworkManager/conf.d/90-dns-none.conf containing

[main]
dns=none

...and restarted the damned GNOME NetworkManager thing.


Theoretically, I could research and document how to do likewise for
every goshdarned ill-advised tool that occasionally mucks with the
nameserver line in /etc/resolv.conf -- systemd-resolvd, netctl, an
endless variety of crummy little utilities. I won't, because (1)
there's no end to that, but -- more to the point -- (2) people who
run crummy little utilities like that need to understand the basics of
how they work.

Or, here's an idea: Don't have them.

I have a standard joke about the "Facebook remedy". People ask me how I
solve Facebook problems, and my cheery answer is "Simple! No Facebook;
no Facebook problems!"

I've not needed those crummy little network-administrative utilities.
If I adopted one, I'd take the trouble to research its basics, including
how to _properly_ instruct it to keep its grubby little paws off the
nameserver line in /etc/resolv.conf .

And, by the way, sadly, no you are incorrect that "you can DNS from
8.8.8.8 and 8.8.4.4 anywhere you go":

Leaving aside my being disappointed about people willingly outsourcing
their recursive DNS to the second-nosiest company on the planet[1]
instead of just running a local recursive nameserver, sorry, you'll find
that such a setup breaks when negotiating a "captive portal" on, e.g.,
most hotel and motel WiFi, where crummy artificial DNS on the WAP
redirects any initial HTTP query to the portal Web site, where you prove
that you're an authorised user before they give your client routing to
outside the service network. Overriding that nameserver instruction
means you won't see the login Web page, so you won't be able to prove
you're a customer, so you won't get a usable connection.

The above is a vexing problem for travelers w/laptops who prefer to
specify their own choice of nameserver and still use hotel/motel WiFi
(and wired ethernet, actually). Best case, you have to disable your
nameserver IP override long enough to navigate the captive portal, and
then can put the override back. But, no, you cannot just leave your
choice of nameserver IPs in place (without disappointment).


[1] Nor is it any better to outsource to OpenNIC, Cisco Umbrella,
Comodo, Yandex, UncensoredDNS, etc. Here's an idea: How about
not outsourcing recursive DNS to anyone? It's not like it's
even difficult. We've had this conversation before.