systemd appears to be the only project where getting rid of legacy cruft is seen as a bad thing. Having a DNS setup that works in a different way when stuff fails should be seen as a bug; DNS is supposed to be reliable.
Now you have. This is a common configuration in mixed-use situations.
> I'm amazed people are relying on that behaviour described in the ticket
Why? Using each server in order is the expected behavior. From resolv.conf(5)
nameserver Name server IP address
Internet address of a name server that the resolver
should query [...]. If there are multiple servers,
the resolver library queries them in the order listed.
[...] (The algorithm used is to try a name server, and
if the query times out, try the next, until out of
name servers, then repeat trying all the name servers
until a maximum number of retries are made.)
You can call it a bug in your use cases, but having an imperfect fallback is important in some situations.
> DNS is supposed to be reliable.
Software is supposed to be lots of things, but good engineering understands that sometimes the real world deviates from these ideal.
What I've never heard of is people relying on that to get DNS results correct. If your first server doesn't work, you _get the wrong results_. I don't understand on what planet that is acceptable sysadmin setup.
Split DNS zones have been a thing for years. This isn't a good substitute.
One of the reasons the IETF likes multiple running implementations of an RFC is they often have different side effects and so they call out things which might hang people up.
The "correct" way to shadow, and to achieve user required semantics, is to create a DNS proxy that answers queries that it is supposed to and recursively getting results for ones that it doesn't.
Correct here is in scare quotes because it doesn't mean it is right but instead just insures side effects of the libraries will not be a problem.
Well, congratulations, there is a first time to have heard everything.
Ordering of DNS servers matters. For instance, you might have a fast one near-by (perhaps on the same machine or LAN segment); and a fallback one that is more costly to use (few hops of latency, more network resources).
> DNS is supposed to be reliable.
In that case, what you should never have heard of is people pointing to more than one DNS server simultaneously. They should have the one and only one which is reliable and that's it. (In fact, that is not an uncommon scenario; that DNS server does the recursion to others if it doesn't have the info.)
Yes, in terms of performance it's pretty common that the order matters, but the bug report is about the order mattering in terms of result. This is less common and seems like a bad idea.
UDP does not strike me as a reliable protocol.
Tthe glibc behavior is the standard on Linux, and FreeBSD (I don't know about the other BSDs) has the same behavior IIRC.
Changing the de facto standard is not something that should be done lightly...
In much the same way clang implements most of gcc's extensions to C and C++, and even defines gcc version macros, so people can simply drop-in replace gcc with clang. It could not implement any of them, but then it would not be very useful to people.
Most of those extensions either exist for a reason, or were an implementation detail that happened to be very useful to people, hence the behaviour is kept in. Now the SystemD developers have removed that behaviour because it's not mandated by a specific piece of paper, even though it's expected by a significant portion of users. Users are not happy.
For me, the second set of users ought to be getting priority, because it's a vastly common setup and users experience time outs as software failing. Ensuring that the system copes normally in the face of DNS resolver failure is a very useful and important feature.