Fedora and fallback DNS servers [LWN.net]

Fedora and fallback DNS servers

Posted Feb 25, 2021 15:30 UTC (Thu) by atnot (guest, #124910)
Parent article: Fedora and fallback DNS servers

Wasn't this whole discussion already had on the web with Postel's robustness principle? With the ultimate conclusion learned from the web generally being that long-term, tolerating brokenness leads to more interoperability, security and privacy issues than strictly refusing invalid configurations.

There is another issue here though. If one distro works by default and another doesn't, users will blame their distro, even if it's behaviour is correct.

to post comments

Fedora and fallback DNS servers

Posted Feb 25, 2021 16:06 UTC (Thu) by ju3Ceemi (subscriber, #102464) [Link] (36 responses)

There are three things at play here

First case: random non-technical people
That guy starts its laptop using default configuration, connect to wifi, get internet with a working DNS from DHCP
If somehow, the dhcp gives him a wrong DNS setting, this means the whole networking is broken. Shall we really try to hide that ? For customers, I doubt that this ever happen. When was the last time a cable compagny broke the DNS of millions of customers ? For entreprises, there is something more: using a random DNS resolver from internet will probably not work, rendering the fallback useless

Second case: servers
Basically, this is the same thing as an enterprise non-technical people: useless

Last case: technical users, that tweek their DNS configuration for some reasons (may be dns routing partially across a couple of VPN, or local zones, or whatever)
In that last case, using any resolver from internet will be broken too, because it won't have that specific required configuration (the local zone, custom routing or whatever)

So I am asking: when is the fallback a good idea, exactly ?

Fedora and fallback DNS servers

Posted Feb 25, 2021 17:39 UTC (Thu) by gnu_lorien (subscriber, #44036) [Link] (33 responses)

"So I am asking: when is the fallback a good idea, exactly ?"

In your first you assert that the fallback simply won't work, if that's the case, then why turn it off? It *could* work. If it does, then everything's fine. The random non-technical person has no control over the DNS configuration of any of the things that broke them.

Somebody else made this point here too, but it bears repeating: If my Fedora laptop "breaks" in this situation and my Windows laptop "works," then, to the user, it was Fedora's fault that it broke not the network.

This example solidifies for me that the non-fallback way is the expert's configuration not the default. If I'm setting up or debugging this network then I need to turn the fallback off to make sure I configured DNS correctly. This setting is of no use to people that don't have control over the network configuration themselves.

In the second case it's essentially catastrophic to have no DNS. I've personally dealt with the scourge of having to hard-code IP addresses into bootstrap scripts for VMs at a cloud provider because we didn't hook up DNS properly. The problem was that VMs appeared to start and then just never registered. The workaround eventually burned us when the IP addresses changed everything lost access to their master resource. Suddenly every VM stopped registering because they weren't using DNS.

Fedora and fallback DNS servers

Posted Feb 25, 2021 21:42 UTC (Thu) by pmb00cs (subscriber, #135480) [Link] (29 responses)

"The random non-technical person has no control over the DNS configuration of any of the things that broke them."

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.

Fedora and fallback DNS servers

Posted Feb 25, 2021 21:58 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (9 responses)

It isn't 1995.

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.

Fedora and fallback DNS servers

Posted Feb 25, 2021 22:33 UTC (Thu) by pmb00cs (subscriber, #135480) [Link] (8 responses)

No it's 2021 and you do need a certain level of technical understanding to recognise that the OS on your computer is changeable, and that there exists a free option that you can download and install.

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.

Fedora and fallback DNS servers

Posted Feb 26, 2021 6:50 UTC (Fri) by roc (subscriber, #30627) [Link] (7 responses)

This is why we will never have the year of the Linux desktop ... too many people, given the choice between inconveniencing a few technical people and inconveniencing masses of non-technical people, will choose the latter.

Fedora and fallback DNS servers

Posted Feb 26, 2021 7:40 UTC (Fri) by pmb00cs (subscriber, #135480) [Link] (6 responses)

It's not choosing to inconvenience "masses" of non-technical people. Firstly there aren't masses of non-technical people using Linux, for the reasons already discussed. Secondly even for those "masses" of non-technical people only the few who have broken DNS would be inconvenienced by this choice.

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.

Fedora and fallback DNS servers

Posted Feb 28, 2021 23:51 UTC (Sun) by gnu_lorien (subscriber, #44036) [Link] (5 responses)

I tried to figure out exactly how many times I've had to manually set up fallback DNS because of some DNS problem in the servers that were provided for me by my network operator. I think it's at least once a year. It doesn't seem like a very high rate, but it is high enough that I've memorized the Google public DNS addresses so that I can quickly switch to them without needing another connected device. In each of these situations I was a very technical user who had no control over the remote machines. The only machine I had control over was mine.

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:
- 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

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.

Fedora and fallback DNS servers

Posted Mar 1, 2021 0:30 UTC (Mon) by pizza (subscriber, #46) [Link]

Several years ago there was some sort of quirk in the DHCP client used by Fedora that caused DNS server entries to not get set under some circumstances. Windows clients and my Android phone weren't affected. This happened surprisingly often, mostly with captive-portal wifi setups (eg at hotels), but I recall it happening a few times with some home-ISP-supplied wifi routers too.

Fedora and fallback DNS servers

Posted Mar 1, 2021 2:55 UTC (Mon) by pabs (subscriber, #43278) [Link]

I remember using 4.2.2.2 in similar situations back in 2007.

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.

Fedora and fallback DNS servers

Posted Mar 1, 2021 8:15 UTC (Mon) by pmb00cs (subscriber, #135480) [Link] (2 responses)

I can't remember the last time I have had to manually set DNS on an end device (server or client). It's not that I haven't had network issues, but network issues get fixed at the network level. Sometimes that has been by me, on my network, sometimes that has been by others on their network.

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?

Fedora and fallback DNS servers

Posted Mar 1, 2021 11:25 UTC (Mon) by pizza (subscriber, #46) [Link]

> As to your hotel networks, if you didn't tell them about it, how do you expect them to fix it at all?

Oh, that's easy; Linux isn't listed under "supported systems"

Fedora and fallback DNS servers

Posted Mar 1, 2021 19:14 UTC (Mon) by gnu_lorien (subscriber, #44036) [Link]

"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"

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.

Fedora and fallback DNS servers

Posted Feb 26, 2021 9:07 UTC (Fri) by intelfx (subscriber, #130118) [Link] (15 responses)

> 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

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).

Fedora and fallback DNS servers

Posted Feb 26, 2021 9:31 UTC (Fri) by pmb00cs (subscriber, #135480) [Link] (14 responses)

And if the computer scientists and students are on a campus network they can report network problems to their university networking team.

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?
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.

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.

Fedora and fallback DNS servers

Posted Feb 26, 2021 11:28 UTC (Fri) by intelfx (subscriber, #130118) [Link] (1 responses)

> 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?

You probably intended a sarcastic meaning, but you are absolutely correct from first word to last.

(Source: first-hand experience.)

Fedora and fallback DNS servers

Posted Feb 26, 2021 11:35 UTC (Fri) by peniblec (subscriber, #111147) [Link]

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.

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.

Fedora and fallback DNS servers

Posted Feb 28, 2021 8:35 UTC (Sun) by jond (subscriber, #37669) [Link]

You were doing very well presenting your case right up to the ad-hominem attack on Poettering which undermines the whole thing.

Fedora and fallback DNS servers

Posted Mar 5, 2021 13:15 UTC (Fri) by jschrod (subscriber, #1646) [Link] (10 responses)

> in the CS field there are academics who don't know how networking works to the point they've never heard of DNS?

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.

Fedora and fallback DNS servers

Posted Mar 8, 2021 13:54 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (9 responses)

> I hope that DNS is *not* taught in a CS course at any self-respecting university.

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.

Fedora and fallback DNS servers

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.

Fedora and fallback DNS servers

Posted Mar 9, 2021 3:56 UTC (Tue) by deater (subscriber, #11746) [Link]

as someone currently teaching a Computer Engineering "Network Engineering" course, you are right on all counts on what we cover. Also the time the Computer Science students took the class (due to a prof on sabbattical in their department) they struggled a bit because their classes tend not to cover low-level real world topics.

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.

Fedora and fallback DNS servers

Posted Mar 9, 2021 19:25 UTC (Tue) by jschrod (subscriber, #1646) [Link] (6 responses)

> > I hope that DNS is *not* taught in a CS course at any self-respecting university.

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.
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?

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.)

Fedora and fallback DNS servers

Posted Mar 9, 2021 19:53 UTC (Tue) by Wol (subscriber, #4433) [Link]

> Even other countries teach such topics in special engineering schools that are decidedly not geared towards an academic education.

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,
Wol

Fedora and fallback DNS servers

Posted Mar 11, 2021 6:29 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (4 responses)

> Yes, that's all important -- but for a high-school course

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.

Fedora and fallback DNS servers

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.

Fedora and fallback DNS servers

Posted Mar 11, 2021 15:21 UTC (Thu) by pizza (subscriber, #46) [Link]

> In Computer Engineering, you will absolutely have to deal with practical things like tcpdump, TCP handshake, DNS, Ethernet frame structure and more

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

Fedora and fallback DNS servers

Posted Mar 11, 2021 16:47 UTC (Thu) by excors (subscriber, #95769) [Link] (1 responses)

> If they [a computer scientist] 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.

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.

Fedora and fallback DNS servers

Posted Mar 11, 2021 21:03 UTC (Thu) by LtWorf (subscriber, #124958) [Link]

Where I did my master, they had different research groups for more applied and more theoretical stuff.

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.

Fedora and fallback DNS servers

Posted Feb 27, 2021 1:34 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link] (2 responses)

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.

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.

Fedora and fallback DNS servers

Posted Feb 28, 2021 8:37 UTC (Sun) by jond (subscriber, #37669) [Link]

In which case you’ve survived for a very long time using Linux without this change and haven’t been inconvenienced by its absence.

Fedora and fallback DNS servers

Posted Mar 8, 2021 13:57 UTC (Mon) by LtWorf (subscriber, #124958) [Link]

Here we are talking about a situation that happens if your DHCP server has a certain specific broken configuration.

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

Posted Feb 26, 2021 0:24 UTC (Fri) by jkingweb (subscriber, #113039) [Link] (1 responses)

> Somebody else made this point here too, but it bears repeating: If my Fedora laptop "breaks" in this situation and my Windows laptop "works," then, to the user, it was Fedora's fault that it broke not the network.

Does Windows have similar built-in fallbacks? Does macOS? As far as I know they don't. Chrome OS and Android might, I'll grant.

Fedora and fallback DNS servers

Posted Feb 26, 2021 4:05 UTC (Fri) by ttuttle (subscriber, #51118) [Link]

Last I checked, Chrome OS didn't. It will ping Google's DNS servers as a diagnostic probe if your DNS servers don't work, but it won't reroute queries by itself.

Fedora and fallback DNS servers

Posted Feb 26, 2021 15:19 UTC (Fri) by ju3Ceemi (subscriber, #102464) [Link]

"Somebody else made this point here too, but it bears repeating: If my Fedora laptop "breaks" in this situation and my Windows laptop "works," then, to the user, it was Fedora's fault that it broke not the network."

Well, does windows have such fallback DNS system ?
If not, what situation, exactly, are we talking about ? Somehow, the dhcp will send a broken setting to fedora, but a good one to windows ?

If the network is broken, both fedora and windows will be broken
If fedora only is broken, then the user is right to blame it

Having some fallback is useless at best, in any cases

Fedora and fallback DNS servers

Posted Feb 25, 2021 19:26 UTC (Thu) by ezuck (subscriber, #59641) [Link] (1 responses)

When was the last time a cable company broke the DNS of millions of customers? For me, recently (Feb 12 ). Videotron, one of the major ISPs here in Quebec was suffering outages that appear to have been due to DNS. In my case, switching to google (8.8.8.8) resolved things.

Fedora and fallback DNS servers

Posted Feb 25, 2021 23:04 UTC (Thu) by Wol (subscriber, #4433) [Link]

My system has been bodged to stick 8.8.8.8 in resolve.conf, precisely because I have repeated had what appear to be DNS outages (I suspect my ISP-supplied router runs DNS and it crashes or burps or whatever on occasion).

Cheers,
Wol

Fedora and fallback DNS servers

Posted Feb 25, 2021 17:13 UTC (Thu) by warrax (subscriber, #103205) [Link] (1 responses)

> Wasn't this whole discussion already had on the web with Postel's robustness principle? With the ultimate conclusion learned from the web generally being that long-term, tolerating brokenness leads to more interoperability, security and privacy issues than strictly refusing invalid configurations.

That is absolutely not true when it comes to security. Postel's law is widely regarded (at least by security experts) as misguided in a hostile world like today's Internet. (It was probably a good idea at the time, but no longer. Of course, in *some* cases it might still be a good idea.)

Fedora and fallback DNS servers

Posted Feb 25, 2021 17:42 UTC (Thu) by jkingweb (subscriber, #113039) [Link]

I think you misread. The passage you quote agrees that Postel's law has been proven unhehlpful on the modern network. It's just a bit hard to parse.

Fedora and fallback DNS servers

Posted Feb 25, 2021 17:23 UTC (Thu) by excors (subscriber, #95769) [Link] (13 responses)

I think the lesson from the web is that interoperability comes from tolerantly handling invalid input, *and* precisely specifying how consumers must handle that invalid input (and having the major implementations follow that specification). The second part is crucial but is missing from Postel's law.

E.g. HTML4 parsing (as implemented in the real world) had the tolerance but not the specification. Early browsers made up their own rules for error handling in an attempt at DWIM, web sites started accidentally relying on those rules, then new browsers would break on those sites and (in order to remain competitive and stop users defecting) had to reverse-engineer and emulate the old browsers' behaviour. Similar for HTTP headers and other parts of the web platform. That led to many interoperability issues, and to security and privacy issues (because nobody could understand how the browsers actually behaved, so they couldn't work out a coherent security model and verify whether the browsers followed it).

XHTML didn't have the tolerance - browsers would completely refuse to display an ill-formed document. But a vanishingly small minority of sites actually used XHTML properly (virtually everyone sent it with Content-Type: text/html which meant it got parsed as HTML4 instead, relying on the browsers' error handling to cope with e.g. " " which is not valid HTML4). And almost every dynamically-generated site that used XHTML properly (as application/xhtml+xml) could be broken by e.g. users posting a comment containing a U+FFFF, which is not allowed in XML but the sites didn't realise and would happily print it out again, thus completely breaking the page for every user (and, in some cases, also breaking the admin pages that were needed to delete the offending comment).

I suspect the main reason that browsers didn't implement a tolerant XHTML parser (which would make the browser significantly more usable on many sites, giving it a competitive advantage and attracting more users) is that nobody used XHTML so it wasn't worth the bother. It's not a good case study for the benefits of rejecting invalid inputs.

HTML5 precisely specified the HTML4 error-handling behaviour. You can pass /dev/urandom into any browser and it should get parsed the same way, and that way is based on the original browsers' DWIM behaviour. There are test suites to verify that, and browser developers care about following the specification, and there's little competitive advantage in violating the specification and DWIMing differently, so the implementations converged and that has greatly increased interoperability. And then it became possible to analyse security/privacy issues by looking at the specification (which is much easier than untangling the logic from source code) and verifying that it follows some proposed security model - it doesn't automatically solve the issues but it makes it possible to reason about them and begin to address them comprehensively. A similar process has happened with HTTP etc.

(Then the web added a zillion more features, and the sheer quantity and complexity means that interoperability is very hard again. But at least it's been largely solved in specific areas.)

I think that lesson applies to most protocol-like technologies for large-scale communication between independent implementations. It doesn't apply to e.g. programming languages, where the person who writes the invalid input can immediately see a fatal error message and fix it themselves. It may not apply to configuration files, since interoperability isn't particularly relevant there, though there's possibly a similar dynamic between the person providing the invalid input (misconfiguring the DHCP/DNS server or whatever) and the person who just wants to get their work done and who doesn't have a good way to convince the first person to fix the issue and will eventually switch to a different distro that doesn't keep getting in their way.

Fedora and fallback DNS servers

Posted Feb 25, 2021 17:54 UTC (Thu) by Sesse (subscriber, #53779) [Link] (5 responses)

> HTML5 precisely specified the HTML4 error-handling behaviour. You can pass /dev/urandom into any browser and it should get parsed the same way, and that way is based on the original browsers' DWIM behaviour.

“Should” is the word. I've read HTML5 parsers full of comments like “the spec says this, but Firefox does it differently, so we have to oblige”.

Fedora and fallback DNS servers

Posted Feb 26, 2021 6:49 UTC (Fri) by roc (subscriber, #30627) [Link] (4 responses)

Where?

The guy who owns the Gecko HTML5 parser is VERY diligent about avoiding this sort of thing. I can let him know.

Fedora and fallback DNS servers

Posted Feb 26, 2021 7:29 UTC (Fri) by Sesse (subscriber, #53779) [Link] (1 responses)

I no longer have access to the code in question, sorry. The point is that even in HTML5, you cannot assume consistent bug-by-bug compatibility of tag soup parsing.

Fedora and fallback DNS servers

Posted Feb 26, 2021 11:10 UTC (Fri) by roc (subscriber, #30627) [Link]

If you say so, but FWIW, my impression is that HTML parsing differences are far down the list of issues that cause compatibility problems.

Fedora and fallback DNS servers

Posted Feb 26, 2021 14:25 UTC (Fri) by jkingweb (subscriber, #113039) [Link] (1 responses)

My own experience agrees with this. Last year I found a bug in the Encoding spec test suite, which resulted in bugs being filed for Gecko, WebKit, and Chromium, because they passed the incorrect test. The Gecko and WebKit bugs were fixes promptly. The Chromium bug, unsurprisingly, is still open. They don't seem to care whether they decode characters the same as everyone else (they have tons of decoder bugs), so I wouldn't be surprised if that extends up to parsing chain. Mozilla, though? Doesn't seem to be a problem.

Maybe Sesse was referring to code which predated the parsing test suite, however.

Fedora and fallback DNS servers

Posted Feb 26, 2021 15:57 UTC (Fri) by excors (subscriber, #95769) [Link]

If I remember correctly, there is very little "code which predated the [HTML5] parsing test suite" - the first reasonably-comprehensive test suites (including tests for a lot of the error handling) were developed in parallel with the first public parser implementation (html5lib, I think?) and in parallel with the specification itself. That was valuable for detecting and fixing any unspecified or ambiguous behaviour in the specification, and then the specification plus test suites were a strong foundation for the subsequent browser implementations, which at least in Mozilla's case was basically a from-scratch rewrite.

I'm sure it wasn't perfect and there were still bugs, and probably things have changed a lot since I last looked at it seriously (a worryingly large number of years ago), but my impression at the time was that it was very successful at achieving interoperability across all the browsers and several non-browser parser implementations. (And it was enormously more successful than HTML4's approach of "here's the specification of a valid document, and how browsers should handle it. Huh, invalid document? Why would anyone do that? Just fix your document" and XHTML's approach of "Invalid document? YELLOW SCREEN OF DEATH".)

(Of course parsing is only a tiny part of the web platform, and probably one of the easiest parts for this kind of comprehensive specification and testing because it's a nice self-contained platform-independent linear transformation from bytes to a tree of elements (ignoring fiddly bits like document.write). But similar principles were applied with some success to other parts of the platform too, and I think the lesson is that it's a significant improvement over Postel's law.)

Fedora and fallback DNS servers

Posted Feb 25, 2021 18:49 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (3 responses)

> (virtually everyone sent it with Content-Type: text/html which meant it got parsed as HTML4 instead, relying on the browsers' error handling to cope with e.g. " " which is not valid HTML4)

To clarify: That technically *is* valid HTML4, it's just the wrong HTML4. Formally, it's equivalent to > (i.e. the tag ends at the slash, as part of a more general <foo/bar/ syntax which is allegedly "easier" than writing <foo>bar</foo>), but I think approximately three people in the entire history of the universe have actually wanted it to be interpreted that way, so all the browsers cheated and ignored the slash. Then XHTML came along and said "actually, you need the slash" and made everything even worse (because as you say, everyone was serving XHTML with text/html and it was then getting parsed as HTML4).

Then HTML5 came along and had to fix this mess. So they decided to specify that the slash is optional and has no semantic meaning (i.e. and are exactly equivalent), and while they were going to the trouble of doing that, they also specified that is illegal (the tag is always empty, so no need to close it), as is (arbitrary self-closing tags are not supported). Both of those misfeatures had been legal in XHTML, but approximately nobody had been using them, so it was reasonably safe to just yank them from the spec before they could turn into an attractive nuisance.

Fedora and fallback DNS servers

Posted Feb 25, 2021 22:31 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (2 responses)

Maybe not , but <td/> was certainly quite common in XHTML.

Fedora and fallback DNS servers

Posted Feb 26, 2021 0:42 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

HTML5 solves that problem by specifying that you can just write <td> and then a closing tag is inferred at the next <td> or <th>, or at the end of the <tr>. This is not considered "error handling," either. It's perfectly legal to omit the closing tag, and the result is considered a well-formed HTML5 document. This was certainly never the case in XHTML, although I'm not sure how HTML4 handled this sort of chicanery.

If you do include the slash, it just strips it out and emits a parse error, so you would end up with an unclosed <td>. But as discussed in the previous paragraph, that <td> will probably close itself anyway, and so it hardly matters.

Incidentally, you can also do this with , meaning you can write prose like this:

Here is a paragraph of text...

Here is a second paragraph...

[and so on]

This is also considered well-formed HTML5.

Fedora and fallback DNS servers

Posted Feb 26, 2021 1:20 UTC (Fri) by jkingweb (subscriber, #113039) [Link]

> HTML5 solves that problem by specifying that you can just write <td> and then a closing tag is inferred at the next <td> or <th>, or at the end of the <tr>. This is not considered "error handling," either. It's perfectly legal to omit the closing tag, and the result is considered a well-formed HTML5 document. This was certainly never the case in XHTML, although I'm not sure how HTML4 handled this sort of chicanery.

This has been a design feature of HTML from its earliest days. Many end tags are optional, as are some start tags, including those for html, body, and tbody.

That last is perhaps lesser-known: in an HTML (but not XHTML) document, <tr> is never a child of <table>; there is always an implicit tbody (or explicit thead or tfoot) element in between.

Fedora and fallback DNS servers

Posted Feb 25, 2021 23:14 UTC (Thu) by Wol (subscriber, #4433) [Link]

And then you throw PHBs into the mix.

Many moons ago, in the days back when ISPs actually knew what they were doing, our ISP upgraded their email servers, and they started sending "250 EHLO". Our MS Mail Gateway threw a hissy fit, and the PHB demanded that our ISP "fix" their sendmail, despite MS Mail completely ignoring the SMTP spec, namely that you MUST NOT quit in response to a command you don't recognise.

Cheers,
Wol

Fedora and fallback DNS servers

Posted Feb 26, 2021 6:51 UTC (Fri) by roc (subscriber, #30627) [Link]

As a former Mozilla distinguished engineer --- this is exactly right.

Fedora and fallback DNS servers

Posted Mar 6, 2021 17:58 UTC (Sat) by anton (subscriber, #25547) [Link]

It doesn't apply to e.g. programming languages, where the person who writes the invalid input can immediately see a fatal error message and fix it themselves.

If only programming languages guaranteed a fatal error message on invalid input. We have that for syntax and so-called "static semantics" (things beyond context-free grammars that are checked by the compiler). But then there are run-time errors, which may be seen by a different person. And then there is undefined behaviour, where a new version of the compiler that the code was tested with might compile the code different than the old version; or worse, the same version of a library might choose to behave differently on some hardware than on the tested hardware (happened with memcpy).

Sidebar on robustness

Posted Mar 4, 2021 13:34 UTC (Thu) by davecb (subscriber, #1574) [Link]

Logically, Postel's advice should be considered as part of an iterative process for robust software development, not as a magic trick that is necessary, sufficient and always correct.

First, interpret the specification narrowly when writing and broadly when reading
Second, complain loudly (but perhaps with exponential backoff) when a narrow reading fails,
Finally, treat the results as a bug report against the spec. Fix the spec and go to step 1.