[atlas] Taking the fuzz our of client cache results

Hi.

I've been running some DNS queries using the probe caches with a view
to understanding the latency between the probe cache and the
authoritative that I'm interested in.

The problem is that there is a fair degree of uncertainty in these
measurements because the cache may have to first resolve higher level names in
the hierarchy and there is no way of knowing whether the cache had to do this
or not.

If my query is for www.example.com, it's quite possible that the cache has to
first resolve example.com prior to sending the final query for www. This means
the measurement may include the cost of getting an answer from .com *and*
getting the answer from example.com... sometimes. Depending on how popular
example.com is and what other clients are doing with the cache.

I'm wondering if there is a way in which we can eliminate this fuzziness? The
most obvious way to do this is to ensure the cache is pre-primed with every
answer up to, but not including the target name.

If we assume the measurement request includes a new "prime cache" flag, then
in the presence of that flag the probe could first run a query for something
like:

    cacheprime.example.com

substituting the first label with some other value.

Alternatively it could first run an NS query for example.com

A third alternative is that the creator of the measurement could nominate the
priming query as they will have the knowledge needed to get it right.

A forth alternative is that the probe could run the query twice - with a
nominated delay that is known to exceed the TTL of the target query.

In all cases, as soon as the priming query is complete, the probe then runs the
target query with a high degree of confidence that the cache only needs to make
one round trip to the authoritative server.

There is still a small probability that the results will be fuzzy for
a variety of reasons, multiple cache choices, anycast caches,
super-busy caches, multiple probes using the same cache, but that
probability will be very low.

Also, a pre-primed query would presumably cost twice as many credits since
it's really running two queries.

Do others think a primed cache query is of use? And, are there ways of
achieving this already?


Mark.