Return to Answer

• The DNS client library in your applications is almost always going to be the BIND DNS client library from ISC. Most C libraries on Unix and Linux systems incorporate the BIND DNS client library. Several other DNS client libraries exist, though, and a minority of applications use them instead.

  The DNS client library does name qualification and finds out what DNS proxy server(s) to talk to, in the manners described in further reading.

• The initial DNS proxy server is, in this particular setup, systemd-resolved listening on 127.0.0.53.

  Other Unix and Linux softwares that perform this role include Daniel J. Bernstein's dnscache, unbound, dnsmasq, the PowerDNS Recursor, the MaraDNS Recursor ("Deadwood"), and so forth.

  I personally have a local instance of modified dnscache (that can inherit its listening sockets) on every machine listening on 127.0.0.1, which is also the default place that the BIND DNS client library expects a proxy DNS server to be, in the absence of explicit configuration.

• systemd-resolved talks to other proxy DNS servers, which may well talk to yet further proxy servers, forwarding the query along a chain until the query reaches a resolving proxy server.
• By default, as the systemd people ship things and unless the person who built the binary package or the local system administrator changes it, the resolving proxy DNS server will be a server run by Google as part of Google Public DNS, and there will be a chain of forwarding proxy DNS servers of length 1.
• If the system administrator has configured systemd-resolved to use other proxy DNS servers instead of Google's, the chain will be longer. Examples of such configuration include (in a rough best-to-worst order) using a local resolving proxy DNS server on the LAN, using a proxy DNS server that is running in a router/gateway at the edge of the LAN, or using a third-party proxy DNS server that is out on the Internet at large.
• The resolving proxy DNS server at the far end of the chain does the grunt work of query resolution, querying content DNS servers around the world as needed for data which it stitches together to form the final answer, which is then returned back along the chain of proxy DNS servers, including systemd-resolved at the near end of that chain, to the DNS client library in the applications.

• The DNS client library in your applications is almost always going to be the BIND DNS client library from ISC. Most C libraries on Unix and Linux systems incorporate the BIND DNS client library. Several other DNS client libraries exist, though, and a minority of applications use them instead.

  The DNS client library does name qualification and finds out what DNS proxy server(s) to talk to, in the manners described in further reading.

• The initial DNS proxy server is, in this particular setup, systemd-resolved listening on 127.0.0.53.

  Other Unix and Linux softwares that perform this rôle include Daniel J. Bernstein's dnscache, unbound, dnsmasq, the PowerDNS Recursor, the MaraDNS Recursor ("Deadwood"), and so forth.

  I personally have a local instance of modified dnscache (that can inherit its listening sockets) on every machine listening on 127.0.0.1, which is also the default place that the BIND DNS client library expects a proxy DNS server to be, in the absence of explicit configuration.

• systemd-resolved talks to other proxy DNS servers, which may well talk to yet further proxy servers, forwarding the query along a chain until the query reaches a resolving proxy server.
• By default, as the systemd people ship things and unless the person who built the binary package or the local system administrator changes it, the resolving proxy DNS server will be a server run by Google as part of Google Public DNS, and there will be a chain of forwarding proxy DNS servers of length 1.
• If the system administrator has configured systemd-resolved to use other proxy DNS servers instead of Google's, the chain will be longer. Examples of such configuration include (in a rough best-to-worst order) using a local resolving proxy DNS server on the LAN, using a proxy DNS server that is running in a router/gateway at the edge of the LAN, or using a third-party proxy DNS server that is out on the Internet at large.
• The resolving proxy DNS server at the far end of the chain does the grunt work of query resolution, querying content DNS servers around the world as needed for data which it stitches together to form the final answer, which is then returned back along the chain of proxy DNS servers, including systemd-resolved at the near end of that chain, to the DNS client library in the applications.

• The DNS client library in your applications is almost always going to be the BIND DNS client library from ISC. Most C libraries on Unix and Linux systems incorporate the BIND DNS client library. Several other DNS client libraries exist, though, and a minority of applications use them instead.

  The DNS client library does name qualification and finds out what DNS proxy server(s) to talk to, in the manners described in further reading.

• The initial DNS proxy server is, in this particular setup, systemd-resolved listening on 127.0.0.53.

  Other Unix and Linux softwares that perform this rôle include Daniel J. Bernstein's dnscache, unbound, dnsmasq, the PowerDNS Recursor, the MaraDNS Recursor ("Deadwood"), and so forth.

  I personally have a local instance of modified dnscache (that can inherit its listening sockets) on every machine listening on 127.0.0.1, which is also the default place that the BIND DNS client library expects a proxy DNS server to be, in the absence of explicit configuration.

• systemd-resolved talks to other proxy DNS servers, which may well talk to yet further proxy servers, forwarding the query along a chain until the query reaches a resolving proxy server.
• By default, as the systemd people ship things and unless the person who built the binary package or the local system administrator changes it, the resolving proxy DNS server will be a server run by Google as part of Google Public DNS, and there will be a chain of forwarding proxy DNS servers of length 1.
• If the system administrator has configured systemd-resolved to use other proxy DNS servers instead of Google's, the chain will be longer. Examples of such configuration include (in a rough best-to-worst order) using a local resolving proxy DNS server on the LAN, using a proxy DNS server that is running in a router/gateway at the edge of the LAN, or using a third-party proxy DNS server that is out on Internet at large.
• The resolving proxy DNS server at the far end of the chain does the grunt work of query resolution, querying content DNS servers around the world as needed for data which it stitches together to form the final answer, which is then returned back along the chain of proxy DNS servers, including systemd-resolved at the near end of that chain, to the DNS client library in the applications.

• The DNS client library in your applications is almost always going to be the BIND DNS client library from ISC. Most C libraries on Unix and Linux systems incorporate the BIND DNS client library. Several other DNS client libraries exist, though, and a minority of applications use them instead.

  The DNS client library does name qualification and finds out what DNS proxy server(s) to talk to, in the manners described in further reading.

• The initial DNS proxy server is, in this particular setup, systemd-resolved listening on 127.0.0.53.

  Other Unix and Linux softwares that perform this role include Daniel J. Bernstein's dnscache, unbound, dnsmasq, the PowerDNS Recursor, the MaraDNS Recursor ("Deadwood"), and so forth.

  I personally have a local instance of modified dnscache (that can inherit its listening sockets) on every machine listening on 127.0.0.1, which is also the default place that the BIND DNS client library expects a proxy DNS server to be, in the absence of explicit configuration.

• systemd-resolved talks to other proxy DNS servers, which may well talk to yet further proxy servers, forwarding the query along a chain until the query reaches a resolving proxy server.
• By default, as the systemd people ship things and unless the person who built the binary package or the local system administrator changes it, the resolving proxy DNS server will be a server run by Google as part of Google Public DNS, and there will be a chain of forwarding proxy DNS servers of length 1.
• If the system administrator has configured systemd-resolved to use other proxy DNS servers instead of Google's, the chain will be longer. Examples of such configuration include (in a rough best-to-worst order) using a local resolving proxy DNS server on the LAN, using a proxy DNS server that is running in a router/gateway at the edge of the LAN, or using a third-party proxy DNS server that is out on the Internet at large.
• The resolving proxy DNS server at the far end of the chain does the grunt work of query resolution, querying content DNS servers around the world as needed for data which it stitches together to form the final answer, which is then returned back along the chain of proxy DNS servers, including systemd-resolved at the near end of that chain, to the DNS client library in the applications.

In the terminology of RFC 1034, there are "resolvers" and there are "name servers". "resolver" describes the entire subsystem that user programs use to access "name servers", without regard to any particular architecture. It's the subsystem that queries one or more "name servers" for the data that they publish and pieces together from those data a final answer for the querying application, in the manner described in RFC 1034 § 5.3.3. A "resolver" is the overall subsystem that does query resolution.

In the terminology of RFC 1034, there are "resolvers" and there are "name servers". "resolver" describes the entire subsystem that user programs use to access "name servers", without regard to any particular architecture. It's the subsystem that queries one or more "name servers" for the data that they publish and pieces together from those data a final answer for the querying application, in the manner described in RFC 1034 § 5.3.3. A "resolver" is the overall subsystem that does query resolution.