RFC8482 – Saying Goodbye to ANY

Re:RFC8482 – Saying Goodbye to ANY by anyfoo on Friday March 15, 2019 @05:20PM (#19404411)

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.

[ Parent | on HN ]

Re:RFC8482 – Saying Goodbye to ANY by kazinator on Friday March 15, 2019 @06:27PM (#19404898)

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.

[ Parent | on HN ]

Re:RFC8482 – Saying Goodbye to ANY by anyfoo on Friday March 15, 2019 @07:07PM (#19405170)

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?

[ Parent | on HN ]

Re:RFC8482 – Saying Goodbye to ANY by kazinator on Friday March 15, 2019 @07:16PM (#19405222)

> 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".

[ Parent | on HN ]

Re:RFC8482 – Saying Goodbye to ANY by anyfoo on Friday March 15, 2019 @08:58PM (#19405710)

No. Don't add complexity, state and attack surface with no reasonable cause.

[ Parent | on HN ]