This protocol works much in the same way as the DNS protocol that was described above, except there's going to be a slight tweak (not really) to allot for the cache nodes on the protocol.
What I failed to mention in that brick of text above is that services like Cloudflare (which were those original "runners" that we were talking about), are so popular because they cache the response that they receive fro those upstream DNS servers .
So when you're done looking up google.com, they remember the "answer" that was given for that query and they store that in their database backend.
Now, the next time that someone is querying for 'google.com', the recursive resolver should be able to provide a "response" almost immediately since they saved the answer to that question.
This is why there's a TTL (time-to-live) in the DNS zones for various domain records (you may not have ever paid it mind before if you've bought a domain in your lifetime).
That TTL essentially tells those recursive servers (and any other servers on the internet) how long they should consider that saved answer to be good for before they need to "refresh" that request to ensure that the answer hasn't changed (these servers are also contacted if there has been a change in the request.
Dangers Here
If there is a *false request* being made to that cached data or someone manages to alter that saved answer somehow, then that's called a cache poisoning attack.
Through a multitude of ways, an attacker can convince an upstream recursive DNS resolver (like Cloudflare or Google DNS) that the answer to a given query has changed when it, in fact, hasn't.
This is why DNSSEC is touted as such an important measure for domains to adopt - because when there is DNSSEC, that stipulates that changes being made to a given domain's "answer" be accompanied with a cryptographic signature that validates with the public key that was also included in the original resource records (for the 'SOA' file ; the 'Start of Authority' / Genesis / Head Honcho #1 Source)
This is pretty effective - although it relies on security of said keys as well as a properly propagated record reflecting the inclusion of said keys. In addition, if the user leaves it up to the registrar to manage said keys, then they are only as secure as that registrar's management of said keys (GoDaddy's 3+ breaches this year exemplifies what this means in a 'real-world' sense).
What I failed to mention in that brick of text above is that services like Cloudflare (which were those original "runners" that we were talking about), are so popular because they cache the response that they receive fro those upstream DNS servers .
So when you're done looking up google.com, they remember the "answer" that was given for that query and they store that in their database backend.
Now, the next time that someone is querying for 'google.com', the recursive resolver should be able to provide a "response" almost immediately since they saved the answer to that question.
This is why there's a TTL (time-to-live) in the DNS zones for various domain records (you may not have ever paid it mind before if you've bought a domain in your lifetime).
That TTL essentially tells those recursive servers (and any other servers on the internet) how long they should consider that saved answer to be good for before they need to "refresh" that request to ensure that the answer hasn't changed (these servers are also contacted if there has been a change in the request.
Dangers Here
If there is a *false request* being made to that cached data or someone manages to alter that saved answer somehow, then that's called a cache poisoning attack.
Through a multitude of ways, an attacker can convince an upstream recursive DNS resolver (like Cloudflare or Google DNS) that the answer to a given query has changed when it, in fact, hasn't.
This is why DNSSEC is touted as such an important measure for domains to adopt - because when there is DNSSEC, that stipulates that changes being made to a given domain's "answer" be accompanied with a cryptographic signature that validates with the public key that was also included in the original resource records (for the 'SOA' file ; the 'Start of Authority' / Genesis / Head Honcho #1 Source)
This is pretty effective - although it relies on security of said keys as well as a properly propagated record reflecting the inclusion of said keys. In addition, if the user leaves it up to the registrar to manage said keys, then they are only as secure as that registrar's management of said keys (GoDaddy's 3+ breaches this year exemplifies what this means in a 'real-world' sense).