5 ms·

I would have to side with systemd project here. I had never heard of the ordering of the DNS servers being meaningful, and I'm amazed people are relying on that

I would have to side with systemd project here. I had never heard of the ordering of the DNS servers being meaningful, and I'm amazed people are relying on that behaviour described in the ticket. 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.

kazinator 9y ago
> I had never heard of the ordering of the DNS servers being meaningful 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.)
- jle17 9y ago
  > 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). 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.
  - kazinator 9y ago
    Clearly, if for any given result, server A must assert its answer over server B, there cannot be a simple timeout or failure fallback from A to B; only if A indicates that it is in working order, but declines to provide an answer.
- amluto 9y ago
  Indeed. I've cursed at glibc for continuing to try an unresponsive resolver for each request quite a few times. Go systemd.
Karunamon 9y ago
DNS has been plenty reliable for the past couple decades. Systemd violating backwards compatibility in the name of standards adherence when the real world works a different way is very... "enterprisey" of them.
pdkl95 9y ago
> I had never heard of the ordering of the DNS servers being meaningful 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.) > Having a DNS setup that works in a different way when stuff fails should be seen as a bug; 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.
- ealexhudson 9y ago
  Y'see, I do get all that. And I could have phrased the "never heard of ordering" thing better: of course I have. 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.
  - ChuckMcM 9y ago
    I see it as implementation being perceived as architecture. The instance of the library that is quoted does this, it is not part of the architecture. That library has been used in a lot of places, so people start relying on the side effect (a common one is to stand up a local DNS server, have it 'shadow' or give alternative results to some queries, like ad network host names, and if the host name isn't in it then to fail so that the next DNS server is queried which is more likely a 'legit' server.) 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.
Asooka 9y ago
That's not really "cruft", that's an additional guarantee that the de-facto historical standard implementation has provided users, in addition to the guarantees outlined in the bespoke on-paper standard. SystemD wants to replace a system that implements a standard+extensions. It doesn't want to implement the extensions, for religious reasons. Maybe there's also a tiny speedup in some scenarios, but there should be an option for those scenarios. 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.
- ealexhudson 9y ago
  So, on one side we have a probably limited number of users who have a DNS setup which is uncommon, and who tolerate periods where they receive incorrect DNS responses. On the others, we have the users who have >1 DNS servers on their local network, who experience significant periods of timeout when the first is offline, even though they have working DNS service available. 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.
chronid 9y ago
> DNS is supposed to be reliable. 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...

kazinator 9y ago

> I had never heard of the ordering of the DNS servers being meaningful 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.)

jle17 9y ago
> 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). 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.
- kazinator 9y ago
  Clearly, if for any given result, server A must assert its answer over server B, there cannot be a simple timeout or failure fallback from A to B; only if A indicates that it is in working order, but declines to provide an answer.
amluto 9y ago
Indeed. I've cursed at glibc for continuing to try an unresponsive resolver for each request quite a few times. Go systemd.

Karunamon 9y ago

DNS has been plenty reliable for the past couple decades. Systemd violating backwards compatibility in the name of standards adherence when the real world works a different way is very... "enterprisey" of them.

pdkl95 9y ago

> I had never heard of the ordering of the DNS servers being meaningful 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.) > Having a DNS setup that works in a different way when stuff fails should be seen as a bug; 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.

ealexhudson 9y ago
Y'see, I do get all that. And I could have phrased the "never heard of ordering" thing better: of course I have. 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.
- ChuckMcM 9y ago
  I see it as implementation being perceived as architecture. The instance of the library that is quoted does this, it is not part of the architecture. That library has been used in a lot of places, so people start relying on the side effect (a common one is to stand up a local DNS server, have it 'shadow' or give alternative results to some queries, like ad network host names, and if the host name isn't in it then to fail so that the next DNS server is queried which is more likely a 'legit' server.) 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.

Asooka 9y ago

That's not really "cruft", that's an additional guarantee that the de-facto historical standard implementation has provided users, in addition to the guarantees outlined in the bespoke on-paper standard. SystemD wants to replace a system that implements a standard+extensions. It doesn't want to implement the extensions, for religious reasons. Maybe there's also a tiny speedup in some scenarios, but there should be an option for those scenarios. 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.

ealexhudson 9y ago
So, on one side we have a probably limited number of users who have a DNS setup which is uncommon, and who tolerate periods where they receive incorrect DNS responses. On the others, we have the users who have >1 DNS servers on their local network, who experience significant periods of timeout when the first is offline, even though they have working DNS service available. 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.

chronid 9y ago

> DNS is supposed to be reliable. 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...