LWN: Comments on "Fedora and fallback DNS servers"

Fedora and fallback DNS servers

LtWorf — Thu, 11 Mar 2021 21:03:46 +0000

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

excors — Thu, 11 Mar 2021 16:47:19 +0000

> 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

pizza — Thu, 11 Mar 2021 15:21:32 +0000

> 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

farnz — Thu, 11 Mar 2021 14:02:12 +0000

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

LtWorf — Thu, 11 Mar 2021 06:29:46 +0000

> 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

Wol — Tue, 09 Mar 2021 19:53:40 +0000

> 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

jschrod — Tue, 09 Mar 2021 19:25:46 +0000

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

deater — Tue, 09 Mar 2021 03:56:45 +0000

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

farnz — Mon, 08 Mar 2021 14:10:53 +0000

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

LtWorf — Mon, 08 Mar 2021 13:57:50 +0000

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

LtWorf — Mon, 08 Mar 2021 13:54:43 +0000

> 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

anton — Sat, 06 Mar 2021 17:58:12 +0000

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

Please

flussence — Fri, 05 Mar 2021 22:40:10 +0000

I just want to post a “me too” to this. Having a human tell me when I've done something to elicit a reaction - good or bad - carries infinitely more weight than passive-aggressive externalities codified in software. The moderation style on this site, sadly unusual as it is in this day and age, works better than anything else I've seen.

We don't have an endemic unchecked plague of trolls here partly because it doesn't present a UI up front that sets expectations that they're part of the system. I can guarantee the second something with countable numbers were to be added, there'd be crowds trying to gamify it in all directions — it's already bad enough when I see a large user ID or reply count and brace for the worst.

(Here's where I'd apologise for veering so far off topic, but I think arguing over software-political DNS hijacking is a horse that's already been flogged into dust.)

Fedora and fallback DNS servers

miquels — Fri, 05 Mar 2021 18:47:57 +0000

The IP address you are using as the source of the DNS query is personal information, it identifies you. The request you are sending can also be privacy sensitive - in effect, when using a webbrowser, you are sending your entire browsing history real-time to these DNS providers. Who are providing this service for free. Why?

The GDPR does not limit transmission of IP addresses. It does, however, require that whoever provides this service, does not use the information gathered for any other purpose than providing the service. Do google and/or cloudflare have a GDPR statement somewhere? If so, fine. No problem. If not, why not?

I think that in general, in the EU it's better to use your ISPs DNS servers. In the US, it's probably better to use Google / Cloudflare DNS as your own ISP is probably worse, both quality-wise and privacy-wise.

Mike.

Fedora and fallback DNS servers

jschrod — Fri, 05 Mar 2021 13:15:15 +0000

> 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

zdzichu — Fri, 05 Mar 2021 12:13:08 +0000

You need to intercept all communication, do MITM with TLS traffic and do deep packet inspection. Because users wanting to use DoH will create their own DoH resolvers on cheapest VPS instances in cloud. I know, they did that in my company.

Fedora and fallback DNS servers

kpfleming — Fri, 05 Mar 2021 12:09:21 +0000

With the advent of DoH, this has gotten very hard to do well. Now you not only have to block UDP and TCP traffic to destination port 53, but you also have to block TCP traffic to port 443 on the well-known DoH servers, and hope that your users won't use a non-well-known server.

Fedora and fallback DNS servers

cortana — Fri, 05 Mar 2021 10:12:02 +0000

Does that mean that if there's no DNS server _configured_ then the fallback is used, so if you have configured servers but they are wrong or don't work you're back to no DNS

Yes, see resolved.conf(5):

FallbackDNS=

A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers. Please see DNS= for acceptable format of addresses. Any per-link DNS servers obtained from systemd-networkd.service(8) take precedence over this setting, as do any servers set via DNS= above or /etc/resolv.conf. This setting is hence only used if no other DNS server information is known. If this option is not given, a compiled-in list of DNS servers is used instead.

See also systemd-resolved(8) for a general description of how it resolves names via unicast DNS:

The following query routing logic applies for unicast DNS traffic:
If a name to look up matches (that is: is equal to or has as suffix) any of the configured routing domains (search or route-only) of any link, or the globally configured DNS settings, "best matching" routing domain is determined: the matching one with the most labels. The query is then sent to all DNS servers of any links or the globally configured DNS servers associated with this "best matching" routing domain. (Note that more than one link might have this same "best matching" routing domain configured, in which case the query is sent to all of them in parallel).
In case of single-label names, when search domains are defined, the same logic applies, except that the name is first suffixed by each of the search domains in turn. Note that this search logic doesn't apply to any names with at least one dot. Also see the discussion about compatibility with the traditional glibc resolver below.
If a query does not match any configured routing domain (either per-link or global), it is sent to all DNS servers that are configured on links with the DefaultRoute= option set, as well as the globally configured DNS server.
If there is no link configured as DefaultRoute= and no global DNS server configured, one of the compiled-in fallback DNS servers is used.
Otherwise the unicast DNS query fails, as no suitable DNS servers can be determined.

Sidebar on robustness

davecb — Thu, 04 Mar 2021 13:34:52 +0000

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.

Fedora and fallback DNS servers

gnu_lorien — Mon, 01 Mar 2021 19:14:33 +0000

"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

madscientist — Mon, 01 Mar 2021 15:16:47 +0000

I am definitely not running BIND. Every home router available these days has its own DNS service available. That doesn't mean everything always works.

> I believe this proposal is "use the DHCP DNS if one is provided, and only fall back to the public servers if DHCP gives us nothing usable."

That's not clear to me: it would be interesting to know exactly WHAT the removed behavior is. The article uses terms like "fallback mechanism" and "last resort", but without actually defining what these mean. Does that mean that if there's no DNS server _configured_ then the fallback is used, so if you have configured servers but they are wrong or don't work you're back to no DNS? Or does it mean if there's no DNS server _available_ (either no configured servers OR none of the configured servers respond to DNS requests) the fallback is used? If the latter, when is this checked?

Either way, things can still go wrong.

> My assumption is that we start from the premise of "make it easy for non-technical users, and possible to configure for technical users."

The premise we start from is "DNS is not working". If DNS does not work, because we don't get the right configuration via DHCP or for some other reason, what is the best thing to do?

Fedora and fallback DNS servers

pizza — Mon, 01 Mar 2021 11:25:04 +0000

> 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

pmb00cs — Mon, 01 Mar 2021 08:15:59 +0000

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

pabs — Mon, 01 Mar 2021 02:55:08 +0000

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

pizza — Mon, 01 Mar 2021 00:30:00 +0000

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

gnu_lorien — Sun, 28 Feb 2021 23:51:37 +0000

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

johannbg — Sun, 28 Feb 2021 19:59:31 +0000

Among their sample atleast and as you can see both Debian and FreeBSD are doing better job than Fedora in that measurement and Fedora is just slightly better than RH which is on par with Microsoft...

Fedora and fallback DNS servers

dskoll — Sun, 28 Feb 2021 19:01:12 +0000

Thanks for the link. As this page shows, DNSSEC adoption is very limited.

Fedora and fallback DNS servers

NYKevin — Sun, 28 Feb 2021 18:25:10 +0000

OK. Well, people who are technical enough to run their own custom BIND server (or whatever it is that you're doing) can also figure out how to configure DHCP correctly. I believe this proposal is "use the DHCP DNS if one is provided, and only fall back to the public servers if DHCP gives us nothing usable."

My assumption is that we start from the premise of "make it easy for non-technical users, and possible to configure for technical users." But perhaps you have a different set of priorities and if so, I don't think we have any common ground to debate.

Fedora and fallback DNS servers

madscientist — Sun, 28 Feb 2021 13:33:52 +0000

No. I don't see where I said anything like that.

I said that local systems could not see other systems on the local network because DNS was misconfigured to not use the local server, exactly as this proposal suggests should become the fallback behavior.

Fedora and fallback DNS servers

jond — Sun, 28 Feb 2021 08:37:16 +0000

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

jond — Sun, 28 Feb 2021 08:35:51 +0000

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

NYKevin — Sun, 28 Feb 2021 07:19:55 +0000

> In fact I just replace my home router last month and had this exact issue, where systems on my home network were not being seen/not available due to DNS problems.

Really? You have devices on your home network that are, completely automatically and with no human intervention, registering .home.arpa addresses, and the router has a DNS server which is letting them do that? That's amazing. I thought[1] this sort of thing was still just an IETF pipe dream. I hadn't realized people were actually going around implementing it.

[1]: I formed this impression by skimming RFC 7368, until I eventually realized that it is not a spec at all, but just a vague listing of the IETF's general aspirations for home networking on IPv6.

Fedora and fallback DNS servers

abo — Sat, 27 Feb 2021 12:44:33 +0000

Cloud providers which depend on another cloud provider (Google, Cloudflare) to function properly. Ridiculous!

Of course the image may be to blame, perhaps the provider requires routing and DNS to be configured statically but the person who made the image forgot to add the right resolver.

Fedora and fallback DNS servers

gdt — Sat, 27 Feb 2021 08:22:19 +0000

In either case I can't see why you'd imagine this somehow creates a relationship between a user and an ISP regulated by law

Well I can't speak to the USA, but in Australia that's precisely what the Telecommunications Act exists to do. The ISP is a "carriage service provider" or a "telecommunications provider" and thus has a black-letter list of the occasions when the content of the user's telecommunications can be disclosed, with other disclosures being criminal.

If your concern is that operators of big public DNS servers like 8.8.8.8 and 1.1.1.1 might invade your privacy I have great news - unlike most ISPs they've actually got good reasons not to and policies saying they won't.

Whereas ISPs are controlled by telecommunications legislation rather than by self-interest. My point is that invisible failover between these two very different privacy scenarios is not desirable.

Fedora and fallback DNS servers

tialaramex — Sat, 27 Feb 2021 06:40:45 +0000

Both Google and Cloudflare have reasoned that their profitability is inherently tied to the Internet. If they make the Internet work better, they get more profits. Certainly we can trivially analyse the most superficial version of this thinking as correct - if the Internet somehow goes away Google and Cloudflare are ruined.

For now this aligns their interests and mine very well. In principle the Network might some day be transitioning to a successor technology and we could imagine Google and Cloudflare, if they still existed when that happens, fighting this change, like a 1990s telco (profiting from the previous iteration of the Network the global PSTN) trying to stop the Internet rather than going with the flow, but if that happens it would be in the distant future and I expect to be long dead.

Anyway, under this rationale offering public DNS unbreaks the Internet for some non-trivial fraction of users, which in turn drives up your profitability.

For Cloudflare in particular there's an extra bonus, the 1.1.1.1 server gets to choose which of several valid answers to give in response to queries and so it can choose answers for Cloudflare services that reduce RTT between origin and server since it knows where they both are.

Historically there was effort to help other servers do this in DNS, by telling them the first few octets of the asking client's IP address. EDNS Client Subnet. Unfortunately of course as we see in this thread, people consider their IP address private information and don't want it leaked. So Cloudflare does not use EDNS Client Subnet at all.

Fedora and fallback DNS servers

rgmoore — Sat, 27 Feb 2021 01:34:43 +0000

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.

Please

jrn — Fri, 26 Feb 2021 23:58:46 +0000

For what it's worth, I appreciate Jon's comments when he intervenes. They are tasteful and help set the tone for everyone else — they make it clear what kind of engagement is expected in *other* threads.

It may be that additional moderation features are also needed (though I've been coping okay with the killfile equivalent) but I don't want to see this other tool for good go away.

Fedora and fallback DNS servers

thoughtpolice — Fri, 26 Feb 2021 21:43:19 +0000

Absolutely not. Tor is nothing but a huge liability for the very vast majority of users when they aren't aware of it (it's another huge failure point in the software stack, and one that some government agencies will respond to with outright hostility), and if the user isn't aware of it, the protections it offers tend to be severely neutered.

Tor can only anonymize and keep you private when you're actively working with it under specific assumptions. Throwing users into the network and making some trivial claim to privacy isn't just a low-effort nerd cop out red herring BS (yes, that's exactly what it is), it's actively misleading to the user about what they can expect.

Fedora and fallback DNS servers

johannbg — Fri, 26 Feb 2021 19:56:12 +0000

The "biggies" are always the last to change given the complexity of their infrastructure & bureaucracy.

Given the rate how fast this is being adopted, now that cloud providers offer it, I'm pretty sure Microsoft will have completed their adoption atleast for the Office 365 platform by the end of this year.

NIST provides statistics on IPv6 and DNSSEC adoption within the US government here [1].

1. https://fedv6-deployment.antd.nist.gov/