Fedora and fallback DNS servers
Fedora and fallback DNS servers
Posted Feb 25, 2021 21:42 UTC (Thu) by pmb00cs (subscriber, #135480)In reply to: Fedora and fallback DNS servers by gnu_lorien
Parent article: Fedora and fallback DNS servers
Why don't they ask the person who set them up with a linux install then?
I find it very hard to believe there are swathes of users computer literate enough to either change the default OS on their machine, dual boot with linux, or buy/build a computer with no OS and install Linux, who are also completely incapable of troubleshooting non working DNS. Which then leaves us with users who cannot troubleshoot DNS issues, who must therefore have had their machines configured for them.
This argument that there exist people completely incapable of recognising or debugging broken config, who use what is a niche operating system preferred by more technically minded people, that is unavailable by default on almost all commercially supplied computers strikes me as an excuse by the developers of this system for a forcing a technically poor choice on everyone. DNS issues aren't that hard to recognise, and although it can be tricky to resolve them without the wealth of information available on the internet, they aren't that difficult to resolve. Leaving a system working only by the grace of a "fall back" setting will mask failing networks, and other issues, that makes it far more dangerous to anyone who manages their own network than the pain it will save people who are non-technical, and yet still for some reason have no support for running the non-default OS on their computer.
Posted Feb 25, 2021 21:58 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link] (9 responses)
You don't (necessarily) need to understand your desktop computer to install Linux on it any more.
It helps, particularly if you have obnoxious hardware that needs proprietary blobs to function, but you don't need to.
Posted Feb 25, 2021 22:33 UTC (Thu)
by pmb00cs (subscriber, #135480)
[Link] (8 responses)
I'm not arguing that non-technical people can't install Linux. I'm arguing that they don't do so in sufficient numbers, absent any form of technical support, for their needs to outweigh the needs of the technical people for who the fallback DNS servers are actively detrimental.
Posted Feb 26, 2021 6:50 UTC (Fri)
by roc (subscriber, #30627)
[Link] (7 responses)
Posted Feb 26, 2021 7:40 UTC (Fri)
by pmb00cs (subscriber, #135480)
[Link] (6 responses)
I'd also argue those users would be far more inconvenienced by the total collapse of their networking that they were unable see coming because the failure of their DNS set up was masked from them so they didn't talk to their network provider to get that fixed early.
The needs of the technical users aren't mutually exclusive with the needs of the non-technical users.
Posted Feb 28, 2021 23:51 UTC (Sun)
by gnu_lorien (subscriber, #44036)
[Link] (5 responses)
I've been on corporate networks where this happened. I contacted the IT people who could fix the DNS and waited until I got a response to my ticket before I switched back to the internal DNS.
At least two times that I remember this happened on hotel networks. I never told them about it and certainly wasn't going to wait and hope that a hotel network was going to get fixed in any timely manner.
In each of these cases there were at least one of the following things that saved me:
If I hadn't had one of these three things then it wouldn't have been an inconvenience, it would have been completely broken. The fallback of using a custom DNS setting has worked for me over and over again. Enough that I have memorized these addresses.
I'm a living counter-example to the idea that the fallbacks are useless or that the problem of bad DNS is both rare and only an inconvenience. Even if the occurrence rate I mentioned here is considered rare I would have remained completely broken if not either for applying the same fallback that systemd-resolved seems to apply or switching to a different device.
I'm curious if you've ever been in the situation where you needed to try a DNS fallback. I'm curious why it didn't work or help you resolve the situation.
Posted Mar 1, 2021 0:30 UTC (Mon)
by pizza (subscriber, #46)
[Link]
Posted Mar 1, 2021 2:55 UTC (Mon)
by pabs (subscriber, #43278)
[Link]
Since then I switched to doing recursive DNS resolution on my laptop with a local unbound daemon, but that just introduced more issues. Networks where recursive resolving is too slow to work, ISPs that block outgoing DNS queries except to their own resolver, ISPs that strip DNSSEC results and so on.
Perhaps the right thing to do is to move the fallback DNS servers into the network configuration settings. Then when you have issues on a particular network you just reconfigure the corresponding network connection to choose one of the available public DNS servers. You could probably do better though; if systemd-resolved detects DNS server issues (an ISP known to sell your data, a country without privacy regulation, DNS servers that don't support DoT/DoH, broken resolution, stripping DNSSEC, etc) it can prompt the user in the GUI and give them the option to switch the configuration for the current network to one of the several different public resolvers, with information about their country of origin, countries of deployment, privacy policies etc.
Posted Mar 1, 2021 8:15 UTC (Mon)
by pmb00cs (subscriber, #135480)
[Link] (2 responses)
When I have had to set DNS settings manually on end devices I've had mixed results. Sometimes it would have worked, and I carried on. Sometimes it would not, and I'd need to find another solution, or live without a network connection until the responsible party could fix it. This included in at least one case a public network with a captive portal that was so broken that I resolved the DNS issue but couldn't then connect to anything. (I know tunnelling over DNS is possible, but I have never actually tried it)
As to your hotel networks, if you didn't tell them about it, how do you expect them to fix it at all? They may not have fixed it in a timely manner, but it may have helped the next person with the same issue?
Posted Mar 1, 2021 11:25 UTC (Mon)
by pizza (subscriber, #46)
[Link]
Oh, that's easy; Linux isn't listed under "supported systems"
Posted Mar 1, 2021 19:14 UTC (Mon)
by gnu_lorien (subscriber, #44036)
[Link]
This is the case that sytemd-resolved is implementing automatically for people that don't know how to set these manually or don't know which values to try.
"As to your hotel networks, if you didn't tell them about it, how do you expect them to fix it at all?"
That's not my problem. It's not my network. I'm not responsible for it.
"They may not have fixed it in a timely manner, but it may have helped the next person with the same issue?"
That's not my problem either. In this case I might suggest those other users use a GNU/Linux system with the default configured systemd-resolved fallbacks so that they're not at the whims of the broken DNS of a captive portal.
In the captive portal situation especially the economic incentive is the other way around. Any time I have to spend debugging their network and reporting this is time that I spent on their behalf where I'm paying them to fix their network. I happily give my labor free of charge to free systems. Proprietary ones do not get this privilege.
Posted Feb 26, 2021 9:07 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (15 responses)
There are lots of them.
People who find themselves using Linux for application-level reasons (computer scientists and CS students, for example) are literate enough to install and use Linux with varied degrees of success, but are not nearly as literate (or interested) in network administration or troubleshooting. Most of those probably never heard the term "DNS" (and do not wish to hear it, either).
Posted Feb 26, 2021 9:31 UTC (Fri)
by pmb00cs (subscriber, #135480)
[Link] (14 responses)
I do contend however that they are not "non-technical" users. Computer Scientists, by the nature of their job are working on the bounds of what computers can do, and Computer Science Students are studying that subject. How does that put them in the "non-technical" group? They may not have heard of DNS (really? in the CS field there are academics who don't know how networking works to the point they've never heard of DNS? Because modern Computer Science has nothing at all to do with networking does it?) but they will be technical enough to find roughly where the problem is, and report it to the responsible party if that is not them.
It's been mentioned elsewhere in the comments, but I'll bring it up here as well. What about the OS's that are installed by default? Where there is a regulatory burden for the OEM to provide support to the users, and therefore an actual financial incentive to make their use as easy as possible for non-technical users. How many of thos have a fall back for broken DNS?
Lets face it the only reason systemd-resolved has fall back DNS settings is because Lennart Poettering has probably had a DNS issue on a network that wasn't his own, and he is arrogant enough to believe that the rest of us are too stupid to fix that issue without his help, and he can't see how masking a DNS issue could come back to bite him. The rest of us however can extrapolate from our experiences, when we've had an issue masked from us it has come back to bite us, therefore masking a DNS issue will come back to bite us.
Lets not defend a poor decision by using arrogance to invoke "what about the people not as bright as us?" when those people either don't exist, or aren't as stupid as we want to think they are. We were all non-technical once, but we became technical by learning. I'm not suggesting that all Linux users are as technical as I, or that I am the most technical Linux user. What I am contending is that the least technical Linux user is at least partly technical, and must have reached a level of technical ability that would allow them to do basic diagnostics BEFORE they became a Linux user, because in this day and age that is what you need to do before you would recognise that Linux is even an option.
Posted Feb 26, 2021 11:28 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (1 responses)
You probably intended a sarcastic meaning, but you are absolutely correct from first word to last.
(Source: first-hand experience.)
Posted Feb 26, 2021 11:35 UTC (Fri)
by peniblec (subscriber, #111147)
[Link]
I'd say "modern" is superfluous; the "computer science is no more about computers than astronomy is about telescopes" aphorism is at least 30 years old.
Posted Feb 28, 2021 8:35 UTC (Sun)
by jond (subscriber, #37669)
[Link]
Posted Mar 5, 2021 13:15 UTC (Fri)
by jschrod (subscriber, #1646)
[Link] (10 responses)
I hope that DNS is *not* taught in a CS course at any self-respecting university. There are more important things to teach, principles instead of specific technics.
> Because modern Computer Science has nothing at all to do with networking does it?
Yes. (I studied CS, and made my PhD in this field.) CS is about structures and how we manipulate them. Similar to mathematics, which, in academia, isn't about math (as you know it from school) either. Or, as an other poster wrote, astronomy is not the science of telescopes.
Posted Mar 8, 2021 13:54 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (9 responses)
Yes in network courses the teacher just goes "it's all magic. Never use tcpdump and never try to understand anything. Also never learn about flow control, error correction, 3 way ack."
Sounds me more like what would happen in the most terrible university.
Posted Mar 8, 2021 14:10 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (1 responses)
Indeed; a Computer Science course (not Computer Engineering) wouldn't bother with tcpdump. Flow control, error correction and 3 way ack algorithms would probably be described and discussed, but not in terms of the details of how they're applied in the TCP/IP stack - you're looking at them as abstract theory.
Computer Engineering probably would cover tcpdump, the TCP handshake (actually a 4 way handshake, with two steps combined into one packet), flow control in TCP and on network links, ECC as used in real networks etc.
Posted Mar 9, 2021 3:56 UTC (Tue)
by deater (subscriber, #11746)
[Link]
As an aside, the networking class is getting hard to teach. With DNS moving to be tunneled over https, with https being encrypted (instead of plaintext), and with HTTP3 being QUIC which is custom-protocol-tunnelled through UDP, the analyzing-tcpdump exercises are becoming more or less useless.
Posted Mar 9, 2021 19:25 UTC (Tue)
by jschrod (subscriber, #1646)
[Link] (6 responses)
Excuse me, but we seem to have *very* different opinions what a university course is.
> Yes in network courses the teacher just goes "it's all magic. Never use tcpdump and never try to understand anything. Also never learn about flow control, error correction, 3 way ack."
Yes, that's all important -- but for a high-school course. More specific, in my country (Germany) these topics are part of the computer science (Informatik) curriculum at high-school level. For advanced courses, which are preparations for studying a topic at college level, these topics are mandatory for the syllabus the teachers have to create.
I know that other countries distribute the curriculum differently. E.g., the US places these topics probably at the college level -- which starts earlier there and which often introduces topics like 2nd (or even 1st) foreign language that are considered high-school topics in my country. Even other countries teach such topics in special engineering schools that are decidedly not geared towards an academic education.
This is the heart of my argument about *university courses*.
The goal of a university course in *computer science* is an *academic education* in that field. I take technical knowledge about specific protocols, as cited by you, as a sensible precondition. At my university, people had the opportunity to take "tutorial classes" (without credit points) in advance of a university course to fill up or refill their knowledge holes on the high-school/college level.
To repeat that high-school education cannot be the task of a course that shall teach you about theory, research, and practice of networking at an academic level -- similar to an analysis course at university level which won't repeat the "curve discussion" that we did on high-school. (Well, at least my math courses at my university didn't do so. They did expect us to know this.)
To be more specific: I would demand for a network course at university level to give the students the ability to read and understand current research articles in reviewed academic journals like ACM TOIN (or the network specific ones in ACM TOCS), and to follow research papers in respective ACM and IEEE proceedings. It would expect them to give graduates enough knowledge to start their own research in that area if they do their master's or Ph.D. thesis there.
So, no: I stand by my opinion that it is not the task of a university to teach *high-school topics* like DNS or TCP-as-a-protocol. This is the task of a school, maybe of a college, but not of a university.
(As the other persons who answered you before me have noted: for Computer Engineering that's a bit different. I specifially mentioned *computer science* courses in my post.)
Posted Mar 9, 2021 19:53 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
Unfortunately, here (in the UK) we've pretty much abolished all "schools that are decidedly not geared towards an academic education." They were called Polytechnics.
30 years on, I think we're finally realising that was a big, BIG, mistake. (And now we're making another - we're turning Universities into Polytechnics, and wondering why nobody has academic *skills* any more.)
Cheers,
Posted Mar 11, 2021 6:29 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (4 responses)
In italy you can sign up to any university course having done any high school. In fact most people signing up for computer science, typically will have gone to a "liceo scientifico" rather than a "tecnico industriale informatico" and will have a focus more on mathematics than network protocols.
No credit mathematics courses are offered to bring people up to speed on mathematics, but you are absolutely not expected to now the entire content of "Computer Networks by Andrew S. Tanenbaum" before you can even apply.
I can't really understand how learning about networks or computer architecture or operating systems makes it impossible to understand scientific papers. Does it make sense to talk about distributed algorithms without knowing how it all works and why a certain set of assumptions is made for the proof?
I also have no idea what you mean college vs university.
Is image manipulation computer science? Can it be mentioned that jpg saves more green information because camera sensors are built this way, because we see green better? Or is that out of topic and forbidden?
I guess you are limiting "computer science" to what you learnt in your university and are excluding anything else as not relevant.
Posted Mar 11, 2021 14:02 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (3 responses)
The distinction between Computer Engineering (which is the application of Computer Science to real world problems) and Computer Science (which is all about the theory) is common in many countries. Some places do mix the two together, and call the resulting mixture Computer Science, but that is by no means the common outcome.
In Computer Engineering, you will absolutely have to deal with practical things like tcpdump, TCP handshake, DNS, Ethernet frame structure and more
In Computer Science, you're looking at algorithms and how computation can be done usefully with them. So, for example, you will make certain assumptions about a distributed world, and those assumptions will be backed either by some handwaving about how a Computer Engineer can build a real system that meets those assumptions or by referencing some work by a Computer Engineer that shows that these assumptions are valid given a system that has been built.
To give an example of how this separates out; a Computer Scientist will make some assumptions about how routers in a network could be made to work (messages passed to neighbouring routers, neighbours forward packets towards their destination, there is a time delay between sending a packet and its reception), and look at how you could guarantee that packets go through the network to their destination efficiently. If they pull in Dijkstra's SPF algorithm, they'll describe something that works a lot like OSPF, but without all the little practicalities that make OSPF work in real networks.
In contrast, a computer engineer will look at things like the reliability of multicast, practical packet formats, MTU limitations, and build you something that works like OSPF.
It sounds to me like you have been through a system that blends Computer Engineering with Computer Science, and calls it Computer Science; this does happen in many institutions, but is not the most common case.
Posted Mar 11, 2021 15:21 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Where I went to college [1], CompE was a specialized form of Electrical Engineering, focusing more on digital circuits and the logical building blocks that go into computer hardware. In other words, the physical layer.
Their Computer Science program was originally an offshoot of Mathematics, focused on computational theory and algorithms, although you could get quite a lot of real-world practicalities in the various specializations and electives -- and I recall one course that specifically covered the design principles behind TCP/IP, DNS, and so forth.
> It sounds to me like you have been through a system that blends Computer Engineering with Computer Science, and calls it Computer Science; this does happen in many institutions, but is not the most common case.
"The common case" is clearly not as common as one would think...
[1] Georgia Institute of Technology, widely considered to be a tier-1 STEM school in the US
Posted Mar 11, 2021 16:47 UTC (Thu)
by excors (subscriber, #95769)
[Link] (1 responses)
But also the computer engineer might not realise that some of the implementation details violate the assumptions made in the mathematical proofs of Dijkstra's algorithm, so in rare edge cases their implementation fails to find a correct routing solution, and they can't understand the research paper that explains the problem precisely with six pages of algebra.
I think that's a significant challenge for Computer Science as a field - there's often a lack of connection between theory and practice. CS isn't like pure maths which can often be considered valuable in its own right; it's more like theoretical physics in that it's only successful when it gets applied to the real world. It's fine if it takes decades of speculative theoretical work before finding an application, but there should be a reasonable expectation that it will eventually find one. An unimplementable computer science concept is like an untestable physics theory - it's not really CS/physics any more, it's just an inefficient way to do maths.
But a lot of CS in academia doesn't really understand real-world computer engineering, because it's had no exposure to environments outside a university, so it fails to identify real problems that need solving; and a lot of computer engineering doesn't understand or care much about academic CS, so it keeps discovering and inventing bad fixes for problems that *have* been solved properly.
It's good for people to specialise but I think it's important to have at least some people who are comfortable with both sides, to keep them connected and working productively on the same problems. There are many cases where that is happening - see e.g. decades of programming language research which was only implemented in niche languages, while real software was written in C, but that research is now being adopted by mainstream production-quality languages thanks to people working to bridge the gap - but I suspect it's far less common than it should be.
Posted Mar 11, 2021 21:03 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link]
Anyway, turned out I knew 2 people doing their thesis in 2 different research groups and it was basically the same topic. Low power algorithms, if I remember. It was years ago.
Anyway, the 2 had not met each other and had no idea that in the same building there was another person working on the same project from a different angle.
Posted Feb 27, 2021 1:34 UTC (Sat)
by rgmoore (✭ supporter ✭, #75)
[Link] (2 responses)
I don't find this hard to believe at all. I've been running Fedora since Fedora Core 1 (and Red Hat before that), and I've never had to learn how to troubleshoot a non-working DNS. I doubt I would have a lot of luck learning on a computer that couldn't connect to the network somehow so I could look for instructions. More to the point, I think the attitude that most Linux users are experts so there's no reason to make a system that's easy for novices to be foolish. A system with sensible default behavior may be most important for novices, but it's helpful for everyone.
Posted Feb 28, 2021 8:37 UTC (Sun)
by jond (subscriber, #37669)
[Link]
Posted Mar 8, 2021 13:57 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link]
All other broken DHCP configurations will still make you unable to connect to anything, the default DNS only prevents one of thousands of ways to break it.
At this point. Is it worth the privacy implications when it's a thing that already normally never happens and if it happens it breaks networking on every OS?
Don't get sidetracked about technical vs non technical.
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
- I had another device to use
- I had the alternative DNS addresses memorized
- I knew how to change the DNS that had been given to me by the network
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Windows: Nope
Android: Nope
MacOS: Nope
IOS: (I don't actually know, but I suspect not)
These Operating systems in use on BILLIONS of devices don't have DNS fall back, why? Because it simply isn't the genius idea it is being sold as. It either doesn't add value, or where it does add value it masks an issue, which is far more damaging than the value it offers in masking that issue.
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Because modern Computer Science has nothing at all to do with networking does it?
You probably intended a sarcastic meaning, but you are absolutely correct from first word to last.
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Afterwards, I would expect them to have a grasp of queing theory, know about some important concepts like "time in a network" coined by Leslie Lamport, maybe reason about issues like buffer bloat in a scientific instead of an empiric way.
Where else should the graduates get that level of education from?
Fedora and fallback DNS servers
Wol
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
Fedora and fallback DNS servers
>
> In contrast, a computer engineer will look at things like the reliability of multicast, practical packet formats, MTU limitations, and build you something that works like OSPF.
Fedora and fallback DNS servers
Fedora and fallback DNS servers
I find it very hard to believe there are swathes of users computer literate enough to either change the default OS on their machine, dual boot with linux, or buy/build a computer with no OS and install Linux, who are also completely incapable of troubleshooting non working DNS.
Fedora and fallback DNS servers
Fedora and fallback DNS servers