4 ms·

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.

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.