4 ms·

The article gives some insight. For example, to quote: Should it forward the "ANY" query to authoritative? Should it respond with any record that is al

by anyfoo 8y ago

The article gives some insight. For example, to quote: Should it forward the "ANY" query to authoritative? Should it respond with any record that is already in cache? Should it do some a mixture of the above behaviors? Should it cache the result of "ANY" query and re-use the data for other queries? Pair that with inconsistent implemented behavior.

kazinator 8y ago
If we treat ANY as universally quantified, for absolute correctness/up-to-dateness we must always send the request upstream, because we are not the authority on all that may exist. However, we can sacrifice a bit of correctness with some reasonable heuristics. If we execute an ANY query for a given domain, we can cache the fact that we did such a query, in addition to caching the records that come back. Then, for some time after that, we may treat those cached records as being everything that is known about that domain; if another ANY query comes in for that domain, we give those records to the client. Furthermore, in an independent cache entry, we can associate the list of record types with that domain: it informs us that for that domain, records of those types are known, or have been known. When we get an ANY query for that domain, if we have this list, we can walk the list of types and query upstream for the missing records that have expired from our cache, rather than forwarding the ANY request. Then we serve the client a mixture of cached and fresh records.
- anyfoo 8y ago
  Oh my. Multiple heterogenous but interacting caches? Heuristics? And if I understood it correctly, if any of the records you got from ANY are expired, you selectively query for new records from a list of cached types, not using ANY? What if the upstream added a record from another type in the meantime? Why have ANY at all then? How is any of that "simple"? How do you transition the existing infrastructure to that behavior? Why?
  - kazinator 8y ago
    > What if the upstream added a record from another type in the meantime? Then we don't see it for a while until the type list is refreshed; that's the up-to-dateness case that is sacrificed. > How do you transition the existing infrastructure to that behavior? Why? If it's an alternative to ALL being rendered inoperative (and someone else is already taking responsibility for that extreme measure), I might have a lot of leeway that adds up to "try it and whatever the hell happens, happens".
    - anyfoo 8y ago
      No. Don't add complexity, state and attack surface with no reasonable cause.

by anyfoo 8y ago

kazinator 8y ago

If we treat ANY as universally quantified, for absolute correctness/up-to-dateness we must always send the request upstream, because we are not the authority on all that may exist. However, we can sacrifice a bit of correctness with some reasonable heuristics. If we execute an ANY query for a given domain, we can cache the fact that we did such a query, in addition to caching the records that come back. Then, for some time after that, we may treat those cached records as being everything that is known about that domain; if another ANY query comes in for that domain, we give those records to the client. Furthermore, in an independent cache entry, we can associate the list of record types with that domain: it informs us that for that domain, records of those types are known, or have been known. When we get an ANY query for that domain, if we have this list, we can walk the list of types and query upstream for the missing records that have expired from our cache, rather than forwarding the ANY request. Then we serve the client a mixture of cached and fresh records.

anyfoo 8y ago
Oh my. Multiple heterogenous but interacting caches? Heuristics? And if I understood it correctly, if any of the records you got from ANY are expired, you selectively query for new records from a list of cached types, not using ANY? What if the upstream added a record from another type in the meantime? Why have ANY at all then? How is any of that "simple"? How do you transition the existing infrastructure to that behavior? Why?
- kazinator 8y ago
  > What if the upstream added a record from another type in the meantime? Then we don't see it for a while until the type list is refreshed; that's the up-to-dateness case that is sacrificed. > How do you transition the existing infrastructure to that behavior? Why? If it's an alternative to ALL being rendered inoperative (and someone else is already taking responsibility for that extreme measure), I might have a lot of leeway that adds up to "try it and whatever the hell happens, happens".
  - anyfoo 8y ago
    No. Don't add complexity, state and attack surface with no reasonable cause.