4 ms·

The behavior these people are asking for is an implementation detail specific to glibc. It's also incorrect: all DNS resolvers listed in resolv.conf are assume

The behavior these people are asking for is an implementation detail specific to glibc. It's also incorrect: all DNS resolvers listed in resolv.conf are assumed by relevant standards to return the same results as each other. I feel bad for the systemd developers, getting bug reports from people who don't understand their own computers.

king_phil 9y ago
Can you point out the relevant RFC, please? Didn't know about that.
- bluejekyll 9y ago
  I don't believe resolv.conf is in any DNS RFC individually. Here's a list of all RFCs related to DNS: https://www.isc.org/community/rfcs/dns/ https://www.isc.org/community/rfcs/dns/ In https://tools.ietf.org/html/rfc1034 https://tools.ietf.org/html/rfc1034 this is discussed: The resolver always starts with a list of server names to query (SLIST). This list will be all NS RRs which correspond to the nearest ancestor zone that the resolver knows about. To avoid startup problems, the resolver should have a set of default servers which it will ask should it have no current NS RRs which are appropriate. The resolver then adds to SLIST all of the known addresses for the name servers, and may start parallel requests to acquire the addresses of the servers when the resolver has the name, but no addresses, for the name servers. I believe it would be an accurate statement that a DNS resolver which is incapable of servicing all DNS queries by the client is something which many clients are not designed to expect. But relying on the behavior of glibc in the way it attempts lookups is in essence relying on the internal workings of that software rather than anything written in the spec. BIND9 supports 'views' (iirc) which allow for splitting queries between internal vs. external DNS. But that would be the resolver as opposed the users desktop implementing that.
- stonogo 9y ago
  From RFC 1034: "The strategy is to cycle around all of the addresses for all of the servers with a timeout between each transmission." Note that it does not specify an order -- the resolver determines that, and RFC 1035 even recommends keeping a weighted list of nameservers prioritized by response time: "To complete initialization of SLIST, the resolver attaches whatever history information it has to the each address in SLIST. This will usually consist of some sort of weighted averages for the response time of the address, and the batting average of the address (i.e., how often the address responded at all to the request)." ...which is exactly what systemd is doing. The glibc behavior is a naive simplest-implementation approach, and if your infrastructure depends on an implementation detail of a specific libc resolver, you should install proper configurable resolvers and use those instead. The fact that all nameservers are expected to return identical results is inherent in the design of DNS. It's one namespace, and if you need to split it, the client resolver is the wrong place to do that too.
JdeBP 9y ago
It's actually misunderstanding the DNS. There are a lot of misunderstandings of the DNS, unfortunately. This is such a common one that I wrote a Frequently Given Answer about it in 2003, years before systemd was even an idea. * http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-same-service.html http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-sam... There's a lot of such misunderstanding here in this discussion, with people asserting, erroneously, that there's a standard, or at least conventional, behaviour for multiple proxy DNS server listings in /etc/resolv.conf, that systemd-resolved is deviating from. In fact, there is a very prominent difference between two widely used softwares that predates systemd by decades, namely nslookup and the C library's DNS client. In actual fact there is not one single conventional behaviour. This particular Frequently Given Answer touching upon the differences in the access patterns dates from 2001, and people are still making this conceptual error about how DNS works 16 years later. * http://jdebp.eu./FGA/nslookup-flaws.html#WrongClient http://jdebp.eu./FGA/nslookup-flaws.html#WrongClient
Asooka 9y ago
Yes, but it's behaviour people have come to expect, and one you should replicate when you're replacing an existing system. I see no reason to break established behaviour of the single de-facto implementation, unless there are significant performance gains to be made. Even then I would rather add an option to turn off the expected behaviour for those who know what they're doing. SystemD is following a standard, while people are relying on an implementation. One that has been stable for a long time and has become a de-facto standard. Think of e.g. memcpy on BSD - even though the standard says memcpy between overlapped regions is not defined, the implementation does memmove in that case, because that's what people expect to happen. If you're replacing a system that has historically provided guarantees above and beyond those given by a bespoke standard, you should emulate them, or you'll cause users a lot of pain. SystemD devs have chosen to inflict pain on their users, hence the users are not happy.
- tyingq 9y ago
  I do agree that there was that expectation. There was at least a "defacto" standard in that many Linux distribution resolv.conf man pages said things like "If there are multiple servers, the resolver library queries them in the order listed." (verbatim quote from some Linux distribution...I concede though, that different distributions may not have spelled that out)
  - bluejekyll 9y ago
    I've always expected that to mean that it attempts the next on the list in case of a failure to receive a message from one, it attempts the next. Some of the people in that bug are saying something that would imply that it also attempts the next on the list in the case of NxDomain/NoData, etc., terminal errors in the lookup. Once one of these is received, it's been my expectation that the query should been marked as failed, and not reattempted.
    - tyingq 9y ago
      I would expect the same as you, though the man page isn't terribly specific in that regard.
phil21 9y ago
Typically I am the first to pile on systemd - but this one is silly. There is absolutely no guarantee that dns resolvers will be queried in order. The implementations of this vary drastically - some implementations make the request to all dns resolvers configured and simply use the response that comes back the fastest. The implemented a hack that seemed to "work" but made poor assumptions as to why. This is not the correct way to implement split horizon DNS.

king_phil 9y ago

Can you point out the relevant RFC, please? Didn't know about that.

bluejekyll 9y ago
I don't believe resolv.conf is in any DNS RFC individually. Here's a list of all RFCs related to DNS: https://www.isc.org/community/rfcs/dns/ https://www.isc.org/community/rfcs/dns/ In https://tools.ietf.org/html/rfc1034 https://tools.ietf.org/html/rfc1034 this is discussed: The resolver always starts with a list of server names to query (SLIST). This list will be all NS RRs which correspond to the nearest ancestor zone that the resolver knows about. To avoid startup problems, the resolver should have a set of default servers which it will ask should it have no current NS RRs which are appropriate. The resolver then adds to SLIST all of the known addresses for the name servers, and may start parallel requests to acquire the addresses of the servers when the resolver has the name, but no addresses, for the name servers. I believe it would be an accurate statement that a DNS resolver which is incapable of servicing all DNS queries by the client is something which many clients are not designed to expect. But relying on the behavior of glibc in the way it attempts lookups is in essence relying on the internal workings of that software rather than anything written in the spec. BIND9 supports 'views' (iirc) which allow for splitting queries between internal vs. external DNS. But that would be the resolver as opposed the users desktop implementing that.
stonogo 9y ago
From RFC 1034: "The strategy is to cycle around all of the addresses for all of the servers with a timeout between each transmission." Note that it does not specify an order -- the resolver determines that, and RFC 1035 even recommends keeping a weighted list of nameservers prioritized by response time: "To complete initialization of SLIST, the resolver attaches whatever history information it has to the each address in SLIST. This will usually consist of some sort of weighted averages for the response time of the address, and the batting average of the address (i.e., how often the address responded at all to the request)." ...which is exactly what systemd is doing. The glibc behavior is a naive simplest-implementation approach, and if your infrastructure depends on an implementation detail of a specific libc resolver, you should install proper configurable resolvers and use those instead. The fact that all nameservers are expected to return identical results is inherent in the design of DNS. It's one namespace, and if you need to split it, the client resolver is the wrong place to do that too.

JdeBP 9y ago

It's actually misunderstanding the DNS. There are a lot of misunderstandings of the DNS, unfortunately. This is such a common one that I wrote a Frequently Given Answer about it in 2003, years before systemd was even an idea. * http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-same-service.html http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-sam... There's a lot of such misunderstanding here in this discussion, with people asserting, erroneously, that there's a standard, or at least conventional, behaviour for multiple proxy DNS server listings in /etc/resolv.conf, that systemd-resolved is deviating from. In fact, there is a very prominent difference between two widely used softwares that predates systemd by decades, namely nslookup and the C library's DNS client. In actual fact there is not one single conventional behaviour. This particular Frequently Given Answer touching upon the differences in the access patterns dates from 2001, and people are still making this conceptual error about how DNS works 16 years later. * http://jdebp.eu./FGA/nslookup-flaws.html#WrongClient http://jdebp.eu./FGA/nslookup-flaws.html#WrongClient

Asooka 9y ago

Yes, but it's behaviour people have come to expect, and one you should replicate when you're replacing an existing system. I see no reason to break established behaviour of the single de-facto implementation, unless there are significant performance gains to be made. Even then I would rather add an option to turn off the expected behaviour for those who know what they're doing. SystemD is following a standard, while people are relying on an implementation. One that has been stable for a long time and has become a de-facto standard. Think of e.g. memcpy on BSD - even though the standard says memcpy between overlapped regions is not defined, the implementation does memmove in that case, because that's what people expect to happen. If you're replacing a system that has historically provided guarantees above and beyond those given by a bespoke standard, you should emulate them, or you'll cause users a lot of pain. SystemD devs have chosen to inflict pain on their users, hence the users are not happy.

tyingq 9y ago
I do agree that there was that expectation. There was at least a "defacto" standard in that many Linux distribution resolv.conf man pages said things like "If there are multiple servers, the resolver library queries them in the order listed." (verbatim quote from some Linux distribution...I concede though, that different distributions may not have spelled that out)
- bluejekyll 9y ago
  I've always expected that to mean that it attempts the next on the list in case of a failure to receive a message from one, it attempts the next. Some of the people in that bug are saying something that would imply that it also attempts the next on the list in the case of NxDomain/NoData, etc., terminal errors in the lookup. Once one of these is received, it's been my expectation that the query should been marked as failed, and not reattempted.
  - tyingq 9y ago
    I would expect the same as you, though the man page isn't terribly specific in that regard.

phil21 9y ago

Typically I am the first to pile on systemd - but this one is silly. There is absolutely no guarantee that dns resolvers will be queried in order. The implementations of this vary drastically - some implementations make the request to all dns resolvers configured and simply use the response that comes back the fastest. The implemented a hack that seemed to "work" but made poor assumptions as to why. This is not the correct way to implement split horizon DNS.