What are DNS server, resolver and stub resolver?
Clash Royale CLAN TAG#URR8PPP
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Description says
Additionally, systemd-resolved provides a local DNS stub listener on IP address 127.0.0.53 on the local loopback interface. Programs issuing DNS requests directly, bypassing any local API may be directed to this stub, in order to connect them to systemd-resolved.
How shall I understand the format of `/etc/resolv.conf`? says
the DNS server and resolver ("stub resolver") can be different, you can pass DNS requests to 127.0.0.53 which pass them to your router for actual DNS (eg it could handle local hosts but pass requests for remote hosts on for full DNS).
What are DNS server, resolver and stub resolver?
I also heard of two kinds of DNS servers (one is called "resolver", and the other I forgot). What do the two kinds mean?
dns terminology systemd-resolved
add a comment |
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Description says
Additionally, systemd-resolved provides a local DNS stub listener on IP address 127.0.0.53 on the local loopback interface. Programs issuing DNS requests directly, bypassing any local API may be directed to this stub, in order to connect them to systemd-resolved.
How shall I understand the format of `/etc/resolv.conf`? says
the DNS server and resolver ("stub resolver") can be different, you can pass DNS requests to 127.0.0.53 which pass them to your router for actual DNS (eg it could handle local hosts but pass requests for remote hosts on for full DNS).
What are DNS server, resolver and stub resolver?
I also heard of two kinds of DNS servers (one is called "resolver", and the other I forgot). What do the two kinds mean?
dns terminology systemd-resolved
I think this is what you’ve forgotten.
– Stephen Kitt
Feb 14 at 5:19
add a comment |
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Description says
Additionally, systemd-resolved provides a local DNS stub listener on IP address 127.0.0.53 on the local loopback interface. Programs issuing DNS requests directly, bypassing any local API may be directed to this stub, in order to connect them to systemd-resolved.
How shall I understand the format of `/etc/resolv.conf`? says
the DNS server and resolver ("stub resolver") can be different, you can pass DNS requests to 127.0.0.53 which pass them to your router for actual DNS (eg it could handle local hosts but pass requests for remote hosts on for full DNS).
What are DNS server, resolver and stub resolver?
I also heard of two kinds of DNS servers (one is called "resolver", and the other I forgot). What do the two kinds mean?
dns terminology systemd-resolved
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Description says
Additionally, systemd-resolved provides a local DNS stub listener on IP address 127.0.0.53 on the local loopback interface. Programs issuing DNS requests directly, bypassing any local API may be directed to this stub, in order to connect them to systemd-resolved.
How shall I understand the format of `/etc/resolv.conf`? says
the DNS server and resolver ("stub resolver") can be different, you can pass DNS requests to 127.0.0.53 which pass them to your router for actual DNS (eg it could handle local hosts but pass requests for remote hosts on for full DNS).
What are DNS server, resolver and stub resolver?
I also heard of two kinds of DNS servers (one is called "resolver", and the other I forgot). What do the two kinds mean?
dns terminology systemd-resolved
dns terminology systemd-resolved
edited Feb 14 at 9:28
Kusalananda
134k17255418
134k17255418
asked Feb 14 at 4:28
TimTim
27.5k78264476
27.5k78264476
I think this is what you’ve forgotten.
– Stephen Kitt
Feb 14 at 5:19
add a comment |
I think this is what you’ve forgotten.
– Stephen Kitt
Feb 14 at 5:19
I think this is what you’ve forgotten.
– Stephen Kitt
Feb 14 at 5:19
I think this is what you’ve forgotten.
– Stephen Kitt
Feb 14 at 5:19
add a comment |
1 Answer
1
active
oldest
votes
Confusing names that people often get wrong.
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.
The RFC theoretically allows, because it isn't intended to be Unix-centric, systems where all of the query resolution mechanism is potentially in some form of shared subsystem that runs inside each individual applications program.
In RFC 1034 terminology, a "stub resolver" is what is generally employed in the Unix and Linux world: a fairly dumb DNS client library running in the application processes, talking the same DNS/UDP and DNS/TCP protocols to an external program running as another process, that actually does the grunt work of query resolution by making back-end transactions and building up the front-end response from them.
"resolver" is such a confusing term, and so often used contrary to the RFCs, that years ago I took to explaining the DNS to people using terminology borrowed from HTTP: proxy servers, content servers, and client libraries linked into 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.
In RFC 1034 terms, for contrast, the "resolver" here is in fact a huge black box encompassing the BIND DNS Client library, systemd-resolved
, and Google Public DNS, because it is defined by the RFC as having "user programs" on one side and content DNS servers (providing referrals and database information "directly") on the other. People often will mis-use the term, sometimes because they misunderstand the RFC 1034 architecture-neutral concept of a "resolver" to be the same as one single Unix or Linux server program, which it is not. HTTP terminology does not have the huge black box.
Further reading
- Jonathan de Boyne Pollard (2000). "content" and "proxy" DNS servers. Frequently Given Answers.
- Jonathan de Boyne Pollard (2004). What DNS query resolution is
. Frequently Given Answers. - Jonathan de Boyne Pollard (2017). What DNS name qualification is. Frequently Given Answers.
- Jonathan de Boyne Pollard (2003). Whence one obtains proxy DNS service. Frequently Given Answers.
- Jonathan de Boyne Pollard (2018). "The
dnscache
,tinydns
, andaxfrdns
services". nosh Guide. Softwares. - https://unix.stackexchange.com/a/449092/5132
I see a danger with the "proxy" analogy. In the HTTP world a proxy just forwards your traffic to a specific server while a DNS recursive nameserver has a lot more work to do, since it iterates by contacting multiple nameservers. It may even have to do DNSSEC computations.
– Patrick Mevzek
Feb 14 at 23:12
Also about naming things, the IETF DNSOP Working Group has now produced this RFC which gives the vocabulary one can use when working on DNS stuff: tools.ietf.org/html/rfc8499. See in particular section 6: "stub resolver", "recursive nameserver", "authoritative server", and "forwarder".
– Patrick Mevzek
Feb 14 at 23:15
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f500536%2fwhat-are-dns-server-resolver-and-stub-resolver%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Confusing names that people often get wrong.
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.
The RFC theoretically allows, because it isn't intended to be Unix-centric, systems where all of the query resolution mechanism is potentially in some form of shared subsystem that runs inside each individual applications program.
In RFC 1034 terminology, a "stub resolver" is what is generally employed in the Unix and Linux world: a fairly dumb DNS client library running in the application processes, talking the same DNS/UDP and DNS/TCP protocols to an external program running as another process, that actually does the grunt work of query resolution by making back-end transactions and building up the front-end response from them.
"resolver" is such a confusing term, and so often used contrary to the RFCs, that years ago I took to explaining the DNS to people using terminology borrowed from HTTP: proxy servers, content servers, and client libraries linked into 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.
In RFC 1034 terms, for contrast, the "resolver" here is in fact a huge black box encompassing the BIND DNS Client library, systemd-resolved
, and Google Public DNS, because it is defined by the RFC as having "user programs" on one side and content DNS servers (providing referrals and database information "directly") on the other. People often will mis-use the term, sometimes because they misunderstand the RFC 1034 architecture-neutral concept of a "resolver" to be the same as one single Unix or Linux server program, which it is not. HTTP terminology does not have the huge black box.
Further reading
- Jonathan de Boyne Pollard (2000). "content" and "proxy" DNS servers. Frequently Given Answers.
- Jonathan de Boyne Pollard (2004). What DNS query resolution is
. Frequently Given Answers. - Jonathan de Boyne Pollard (2017). What DNS name qualification is. Frequently Given Answers.
- Jonathan de Boyne Pollard (2003). Whence one obtains proxy DNS service. Frequently Given Answers.
- Jonathan de Boyne Pollard (2018). "The
dnscache
,tinydns
, andaxfrdns
services". nosh Guide. Softwares. - https://unix.stackexchange.com/a/449092/5132
I see a danger with the "proxy" analogy. In the HTTP world a proxy just forwards your traffic to a specific server while a DNS recursive nameserver has a lot more work to do, since it iterates by contacting multiple nameservers. It may even have to do DNSSEC computations.
– Patrick Mevzek
Feb 14 at 23:12
Also about naming things, the IETF DNSOP Working Group has now produced this RFC which gives the vocabulary one can use when working on DNS stuff: tools.ietf.org/html/rfc8499. See in particular section 6: "stub resolver", "recursive nameserver", "authoritative server", and "forwarder".
– Patrick Mevzek
Feb 14 at 23:15
add a comment |
Confusing names that people often get wrong.
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.
The RFC theoretically allows, because it isn't intended to be Unix-centric, systems where all of the query resolution mechanism is potentially in some form of shared subsystem that runs inside each individual applications program.
In RFC 1034 terminology, a "stub resolver" is what is generally employed in the Unix and Linux world: a fairly dumb DNS client library running in the application processes, talking the same DNS/UDP and DNS/TCP protocols to an external program running as another process, that actually does the grunt work of query resolution by making back-end transactions and building up the front-end response from them.
"resolver" is such a confusing term, and so often used contrary to the RFCs, that years ago I took to explaining the DNS to people using terminology borrowed from HTTP: proxy servers, content servers, and client libraries linked into 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.
In RFC 1034 terms, for contrast, the "resolver" here is in fact a huge black box encompassing the BIND DNS Client library, systemd-resolved
, and Google Public DNS, because it is defined by the RFC as having "user programs" on one side and content DNS servers (providing referrals and database information "directly") on the other. People often will mis-use the term, sometimes because they misunderstand the RFC 1034 architecture-neutral concept of a "resolver" to be the same as one single Unix or Linux server program, which it is not. HTTP terminology does not have the huge black box.
Further reading
- Jonathan de Boyne Pollard (2000). "content" and "proxy" DNS servers. Frequently Given Answers.
- Jonathan de Boyne Pollard (2004). What DNS query resolution is
. Frequently Given Answers. - Jonathan de Boyne Pollard (2017). What DNS name qualification is. Frequently Given Answers.
- Jonathan de Boyne Pollard (2003). Whence one obtains proxy DNS service. Frequently Given Answers.
- Jonathan de Boyne Pollard (2018). "The
dnscache
,tinydns
, andaxfrdns
services". nosh Guide. Softwares. - https://unix.stackexchange.com/a/449092/5132
I see a danger with the "proxy" analogy. In the HTTP world a proxy just forwards your traffic to a specific server while a DNS recursive nameserver has a lot more work to do, since it iterates by contacting multiple nameservers. It may even have to do DNSSEC computations.
– Patrick Mevzek
Feb 14 at 23:12
Also about naming things, the IETF DNSOP Working Group has now produced this RFC which gives the vocabulary one can use when working on DNS stuff: tools.ietf.org/html/rfc8499. See in particular section 6: "stub resolver", "recursive nameserver", "authoritative server", and "forwarder".
– Patrick Mevzek
Feb 14 at 23:15
add a comment |
Confusing names that people often get wrong.
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.
The RFC theoretically allows, because it isn't intended to be Unix-centric, systems where all of the query resolution mechanism is potentially in some form of shared subsystem that runs inside each individual applications program.
In RFC 1034 terminology, a "stub resolver" is what is generally employed in the Unix and Linux world: a fairly dumb DNS client library running in the application processes, talking the same DNS/UDP and DNS/TCP protocols to an external program running as another process, that actually does the grunt work of query resolution by making back-end transactions and building up the front-end response from them.
"resolver" is such a confusing term, and so often used contrary to the RFCs, that years ago I took to explaining the DNS to people using terminology borrowed from HTTP: proxy servers, content servers, and client libraries linked into 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.
In RFC 1034 terms, for contrast, the "resolver" here is in fact a huge black box encompassing the BIND DNS Client library, systemd-resolved
, and Google Public DNS, because it is defined by the RFC as having "user programs" on one side and content DNS servers (providing referrals and database information "directly") on the other. People often will mis-use the term, sometimes because they misunderstand the RFC 1034 architecture-neutral concept of a "resolver" to be the same as one single Unix or Linux server program, which it is not. HTTP terminology does not have the huge black box.
Further reading
- Jonathan de Boyne Pollard (2000). "content" and "proxy" DNS servers. Frequently Given Answers.
- Jonathan de Boyne Pollard (2004). What DNS query resolution is
. Frequently Given Answers. - Jonathan de Boyne Pollard (2017). What DNS name qualification is. Frequently Given Answers.
- Jonathan de Boyne Pollard (2003). Whence one obtains proxy DNS service. Frequently Given Answers.
- Jonathan de Boyne Pollard (2018). "The
dnscache
,tinydns
, andaxfrdns
services". nosh Guide. Softwares. - https://unix.stackexchange.com/a/449092/5132
Confusing names that people often get wrong.
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.
The RFC theoretically allows, because it isn't intended to be Unix-centric, systems where all of the query resolution mechanism is potentially in some form of shared subsystem that runs inside each individual applications program.
In RFC 1034 terminology, a "stub resolver" is what is generally employed in the Unix and Linux world: a fairly dumb DNS client library running in the application processes, talking the same DNS/UDP and DNS/TCP protocols to an external program running as another process, that actually does the grunt work of query resolution by making back-end transactions and building up the front-end response from them.
"resolver" is such a confusing term, and so often used contrary to the RFCs, that years ago I took to explaining the DNS to people using terminology borrowed from HTTP: proxy servers, content servers, and client libraries linked into 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.
In RFC 1034 terms, for contrast, the "resolver" here is in fact a huge black box encompassing the BIND DNS Client library, systemd-resolved
, and Google Public DNS, because it is defined by the RFC as having "user programs" on one side and content DNS servers (providing referrals and database information "directly") on the other. People often will mis-use the term, sometimes because they misunderstand the RFC 1034 architecture-neutral concept of a "resolver" to be the same as one single Unix or Linux server program, which it is not. HTTP terminology does not have the huge black box.
Further reading
- Jonathan de Boyne Pollard (2000). "content" and "proxy" DNS servers. Frequently Given Answers.
- Jonathan de Boyne Pollard (2004). What DNS query resolution is
. Frequently Given Answers. - Jonathan de Boyne Pollard (2017). What DNS name qualification is. Frequently Given Answers.
- Jonathan de Boyne Pollard (2003). Whence one obtains proxy DNS service. Frequently Given Answers.
- Jonathan de Boyne Pollard (2018). "The
dnscache
,tinydns
, andaxfrdns
services". nosh Guide. Softwares. - https://unix.stackexchange.com/a/449092/5132
answered Feb 14 at 8:44
JdeBPJdeBP
36.1k473172
36.1k473172
I see a danger with the "proxy" analogy. In the HTTP world a proxy just forwards your traffic to a specific server while a DNS recursive nameserver has a lot more work to do, since it iterates by contacting multiple nameservers. It may even have to do DNSSEC computations.
– Patrick Mevzek
Feb 14 at 23:12
Also about naming things, the IETF DNSOP Working Group has now produced this RFC which gives the vocabulary one can use when working on DNS stuff: tools.ietf.org/html/rfc8499. See in particular section 6: "stub resolver", "recursive nameserver", "authoritative server", and "forwarder".
– Patrick Mevzek
Feb 14 at 23:15
add a comment |
I see a danger with the "proxy" analogy. In the HTTP world a proxy just forwards your traffic to a specific server while a DNS recursive nameserver has a lot more work to do, since it iterates by contacting multiple nameservers. It may even have to do DNSSEC computations.
– Patrick Mevzek
Feb 14 at 23:12
Also about naming things, the IETF DNSOP Working Group has now produced this RFC which gives the vocabulary one can use when working on DNS stuff: tools.ietf.org/html/rfc8499. See in particular section 6: "stub resolver", "recursive nameserver", "authoritative server", and "forwarder".
– Patrick Mevzek
Feb 14 at 23:15
I see a danger with the "proxy" analogy. In the HTTP world a proxy just forwards your traffic to a specific server while a DNS recursive nameserver has a lot more work to do, since it iterates by contacting multiple nameservers. It may even have to do DNSSEC computations.
– Patrick Mevzek
Feb 14 at 23:12
I see a danger with the "proxy" analogy. In the HTTP world a proxy just forwards your traffic to a specific server while a DNS recursive nameserver has a lot more work to do, since it iterates by contacting multiple nameservers. It may even have to do DNSSEC computations.
– Patrick Mevzek
Feb 14 at 23:12
Also about naming things, the IETF DNSOP Working Group has now produced this RFC which gives the vocabulary one can use when working on DNS stuff: tools.ietf.org/html/rfc8499. See in particular section 6: "stub resolver", "recursive nameserver", "authoritative server", and "forwarder".
– Patrick Mevzek
Feb 14 at 23:15
Also about naming things, the IETF DNSOP Working Group has now produced this RFC which gives the vocabulary one can use when working on DNS stuff: tools.ietf.org/html/rfc8499. See in particular section 6: "stub resolver", "recursive nameserver", "authoritative server", and "forwarder".
– Patrick Mevzek
Feb 14 at 23:15
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f500536%2fwhat-are-dns-server-resolver-and-stub-resolver%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I think this is what you’ve forgotten.
– Stephen Kitt
Feb 14 at 5:19