4 ms·

I think your terms are incorrect. Proxy queries in your context are referred to as recursive and content is authoritative.

JdeBP 6y ago
These aren't types of query, they are types of server. viovich123 was talking about content DNS servers that cause the scaling problems, and penalizing the people who run them. But it is the proxy DNS servers, and the DNS clients and applications softwares that drive them, that are the cause here. The terms are correct, and are derived from HTTP. You aren't grasping them correctly.
- dkdk8283 6y ago
  These terms are not listed in RFC 7719 “DNS Terminology”. > You aren’t grasping them correctly. I find this to be quite rude.
- bauruine 6y ago
  I've never heard those terms only recursive / resolver and authoritative. Who uses content and proxy?
- eikenberry 6y ago
  > The terms are correct, and are derived from HTTP. You aren't grasping them correctly. This, I think, is the source of the problem. DNS servers have their own terminology that pre-dates HTTP. The servers that take/do lookup requests and cache them are known as recursive servers. Yes, they act similarly to HTTP caching proxies, but that's not how they are referred to. These make up the vast majority of DNS servers. The other type is authoritative, which is called that as it is the 'athoritative'source of truth for some domain's DNS data. Where the root servers look it up to feed into the system. These would be akin to your basic HTTP servers, but again the terminology is different.
  - JdeBP 6y ago
    This is the source of the problem. People don't understand the DNS terminology. Very few people indeed get "resolver" right, for example, and they only then end up confusing the rather larger number of people who get it quite wrong. Similarly, "authoritative" confuses people when they have to try to understand why it isn't actually the same as an "authoritative answer". Whereas they do understand the idea of DNS records being content, that is published by content servers. Hence why many years ago I took to explaining DNS using HTTP terminology. It works quite well.
    - ohyeshedid 6y ago
      > Hence why many years ago I took to explaining DNS using HTTP terminology. It works quite well. That is the source of your own confusion. There will be no memorial for you on the hill that you're dying on.
    - eikenberry 6y ago
      I can see where you're coming from, as it does work as a close metaphor and people are generally more familiar with HTTP. I think the disconnect is that while that is a good way to relate it, seems like teaching the correct terminology along with the basic idea is generally better as it also gives them the tools (eg. as search criteria) to research it more themselves.
      - JdeBP 6y ago
        Long experience shows that it doesn't. It just adds layers of obfuscation to the subject. You spend all of the time explaining what a "resolver" is, for starters, and then have to explain how that model then doesn't really match how the softwares fit together on their operating system and LAN, because it was intended to be an operating system neutral model. And then you get to explain that almost no-one will understand you correctly if you use the term properly. Whereas explain to them that it's a form of publication, from content servers through proxies to client libraries in applications, like HTTP, and it generally clicks what part of the overall system talks to what other parts. People have some absurd models of how things work, from ISPs talking to ISPs to relays along chains of content servers. Explaining that it's actually like HTTP gets people using the correct mental model, and matches how the softwares in reality fit together. There really is a DNS client library, and it has a name such as (for example) libresolv. There really is a proxy DNS server, and one can point to a specific process running its program, again with names (dnscache, pdns-recursor, et al.), to its back-end and front-end traffic, and to whether it is configured to forward or to resolve. There really are content DNS servers, again with nameable programs (nsd, tinydns, walldns, pdns_server, et al.), with specific locations, and with content sources that one can point to. The fact that RFC 7719 exists should tell one something, even if it weren't spelled out in its introduction that the RFC terminology is confusing, contradictory, and going to change wholesale "real soon now". Here's a mental exercise: Configure your machine with 1.1.1.1 in /etc/resolv.conf. The RFCs, including RFC 7719, tell you both that your "resolver" is the program that does the entire job of "resolution" and that it is located on the same machine as the program requesting the lookups. You have a DNS client library locally, linked into your applications, that is talking to a resolving proxy DNS server running on a machine operated by Cloudflare. The resolving proxy DNS server is doing all of the grunt work of query resolution, retrieving content from content DNS servers with back-end transactions, and Cloudflare's machine is where its front-end and back-end are. It's simple to explain that way. Now point to your "resolver". Then further try explaining it to someone else. Then try explaining that Cloudflare's server is a DNS server, but not a "name server". See what happens when you tell them that for an explanation of "name server" they just need to use RFC 7719 to "research it more".
- ohyeshedid 6y ago
  > These aren't types of query, they are types of server Actually, they're both a type of server and a type of query. > viovich123 was talking about content DNS servers DNS has nothing to do with content, it's name to address resolution.
  - JdeBP 6y ago
    No, content and proxy are types of server. There's no such thing as a "content query" nor a "proxy query". And DNS very much is content. The content is a whole bunch of resource record sets. Published by content servers, much as in HTTP. And it isn't all name to address stuff.

JdeBP 6y ago

These aren't types of query, they are types of server. viovich123 was talking about content DNS servers that cause the scaling problems, and penalizing the people who run them. But it is the proxy DNS servers, and the DNS clients and applications softwares that drive them, that are the cause here. The terms are correct, and are derived from HTTP. You aren't grasping them correctly.

dkdk8283 6y ago
These terms are not listed in RFC 7719 “DNS Terminology”. > You aren’t grasping them correctly. I find this to be quite rude.
bauruine 6y ago
I've never heard those terms only recursive / resolver and authoritative. Who uses content and proxy?
eikenberry 6y ago
> The terms are correct, and are derived from HTTP. You aren't grasping them correctly. This, I think, is the source of the problem. DNS servers have their own terminology that pre-dates HTTP. The servers that take/do lookup requests and cache them are known as recursive servers. Yes, they act similarly to HTTP caching proxies, but that's not how they are referred to. These make up the vast majority of DNS servers. The other type is authoritative, which is called that as it is the 'athoritative'source of truth for some domain's DNS data. Where the root servers look it up to feed into the system. These would be akin to your basic HTTP servers, but again the terminology is different.
- JdeBP 6y ago
  This is the source of the problem. People don't understand the DNS terminology. Very few people indeed get "resolver" right, for example, and they only then end up confusing the rather larger number of people who get it quite wrong. Similarly, "authoritative" confuses people when they have to try to understand why it isn't actually the same as an "authoritative answer". Whereas they do understand the idea of DNS records being content, that is published by content servers. Hence why many years ago I took to explaining DNS using HTTP terminology. It works quite well.
  - ohyeshedid 6y ago
    > Hence why many years ago I took to explaining DNS using HTTP terminology. It works quite well. That is the source of your own confusion. There will be no memorial for you on the hill that you're dying on.
  - eikenberry 6y ago
    I can see where you're coming from, as it does work as a close metaphor and people are generally more familiar with HTTP. I think the disconnect is that while that is a good way to relate it, seems like teaching the correct terminology along with the basic idea is generally better as it also gives them the tools (eg. as search criteria) to research it more themselves.
    - JdeBP 6y ago
      Long experience shows that it doesn't. It just adds layers of obfuscation to the subject. You spend all of the time explaining what a "resolver" is, for starters, and then have to explain how that model then doesn't really match how the softwares fit together on their operating system and LAN, because it was intended to be an operating system neutral model. And then you get to explain that almost no-one will understand you correctly if you use the term properly. Whereas explain to them that it's a form of publication, from content servers through proxies to client libraries in applications, like HTTP, and it generally clicks what part of the overall system talks to what other parts. People have some absurd models of how things work, from ISPs talking to ISPs to relays along chains of content servers. Explaining that it's actually like HTTP gets people using the correct mental model, and matches how the softwares in reality fit together. There really is a DNS client library, and it has a name such as (for example) libresolv. There really is a proxy DNS server, and one can point to a specific process running its program, again with names (dnscache, pdns-recursor, et al.), to its back-end and front-end traffic, and to whether it is configured to forward or to resolve. There really are content DNS servers, again with nameable programs (nsd, tinydns, walldns, pdns_server, et al.), with specific locations, and with content sources that one can point to. The fact that RFC 7719 exists should tell one something, even if it weren't spelled out in its introduction that the RFC terminology is confusing, contradictory, and going to change wholesale "real soon now". Here's a mental exercise: Configure your machine with 1.1.1.1 in /etc/resolv.conf. The RFCs, including RFC 7719, tell you both that your "resolver" is the program that does the entire job of "resolution" and that it is located on the same machine as the program requesting the lookups. You have a DNS client library locally, linked into your applications, that is talking to a resolving proxy DNS server running on a machine operated by Cloudflare. The resolving proxy DNS server is doing all of the grunt work of query resolution, retrieving content from content DNS servers with back-end transactions, and Cloudflare's machine is where its front-end and back-end are. It's simple to explain that way. Now point to your "resolver". Then further try explaining it to someone else. Then try explaining that Cloudflare's server is a DNS server, but not a "name server". See what happens when you tell them that for an explanation of "name server" they just need to use RFC 7719 to "research it more".
ohyeshedid 6y ago
> These aren't types of query, they are types of server Actually, they're both a type of server and a type of query. > viovich123 was talking about content DNS servers DNS has nothing to do with content, it's name to address resolution.
- JdeBP 6y ago
  No, content and proxy are types of server. There's no such thing as a "content query" nor a "proxy query". And DNS very much is content. The content is a whole bunch of resource record sets. Published by content servers, much as in HTTP. And it isn't all name to address stuff.