💾 Archived View for midnight.pub › replies › 8669 captured on 2024-08-25 at 05:44:33. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2024-08-18)

-=-=-=-=-=-=-

<

Parent

~inquiry

> I find that using my own hardware for everything helps a
> bit. My hate for software that implements their own DNS
> lookup, is like the fire of a thousand suns.

I suddenly remembered about /etc/hosts, and thought putting entries in there might be the simplest solution, because apart from search (which I'm doing less and less of due to what seems like the plummeting quality of any "information"/"help" out there relative to the amount of happy horseshit added to search results and what seem to be spammy sites that somehow get their pages ranked higher), I'm generally visiting a handful of sites, and my understanding is that /etc/hosts entries can bypass an external DNS'ing altogether for entries covering those sites (e.g. for "site.com" and "www.site.com").

But, as usual: No. F no.

I didn't expect additions to the file to "take effect immediately", so I learned the linux in the container on this Chromebook is Debian 11, and agonized through trying to find consensus on what subsystem I might need to restart, whose invocation was apparently:

sudo systemctl restart systemd-resolved'

But doing that didn't cause my additional entries to accomplish anything.

My disgust with search these days has me basically giving up, suspecting the misery of having to periodically wait for DNS to take "forever" every several minutes is less than wading in useless-opinion-driven "trying things". Far too much modern "information"/"help" these days seems roughly in the ballpark of "Well... I pulled on my left earlobe with my right hand while engaged in a one foot hopping to a 2-left/3-right pattern while whistling the chorus to Linkin Park's 'In The End'... and during that IT JUST STARTED WORKING!!!"

I wouldn't doubt that perhaps something in Debian 11 simply doesn't now how to properly work (with) the router T-Mobile supplied for their "5G" plan, because the same Chromebook worked just fine with the router at the previous residence - which I imagine T-Mobile made sure couldn't work with the router they give you. I've tried other DNS server IP addresses in /etc/resolv.conf, know they "took" (after restarting whatever), wrote a script to re-establish them after a reboot (because they get written from something else that I didn't want to mess with), but it's either the router itself, or something about Debian 11 not working with it.

And, of course, although the Chromebook regularly notifies me about upgrading to Debian 12, the couple times I tried that took half of forever en route to telling me that something about the install failed.

Yeah... I could get a Debian 12 .deb (that's the right suffix, right?) and mess with installing it in the container situation on this machine (as opposed to traveling the road I imagine more traveled, which is to simply upgrade the "Terminal" app), but having to got through that likely pinnacle misery isn't what you want to have to do with a device that otherwise "just works". The "Terminal" app for Chromebook has worked gloriously for me for years. All I need is a simple, mostly command line environment for basic reading/posting and scripting fun. But a good chunk of that implies networking matters being solved. If I wanted to boil that ocean by dicking with different distros and versions there of, I'd have gone a different route altogether.

And, of course, I'm just guessing that Debian 12 might solve the problem. It's not hard to imagine jumping through seemingly infinite hoops to install it (without managing to destroy what's worked for years), only to find the DNS issue - that apparently nobody else online has encountered - happens in that environment too.

In the past I might have logged into the router as "admin", and dug around and tried a few things. But despite the router showing the admin password on the side of the device, T-Mobile opted to disable being able to use it (via telnet or ssh) anyway. You're told to use their app to do "advanced" things, but the app has no paths to such.

I mean, just the time blown grinding out this reply due to the amount of frustration this has caused me could have been better spent, e.g. pounding legacy soda can pull tabs under my fingernails....

Write a reply

Replies

~lacklustre_saint wrote:

I suddenly remembered about /etc/hosts, and thought putting entries in there might be the simplest solution...

This really depends on how your distro handles dns queries. The old standard way of using bootp and hosts are often the last options in how your host resolves dns queries. For example, in some systems the file /etc/nsswitch.conf is used to configure the order of dns query resolution, and on top of that, we have the /etc/resolv.conf that can be updated by a number of network utilities. For my own needs, I configured a local dns server which is always used by every client inside my own network, but sometimes not even that is enough.

Not sure about ChromeOS, but Chrome has historically had their own dns-over-https resolver, with their own dns servers configured, which caused a lot of confusion a couple of years ago, not sure if that is still true though.