[dns-operations] new public DNS service: 9.9.9.9

[Tony Finch]

abang <abang at t-ipnet.net> wrote:

> Yes, that's right. However, it confirms our observations: Resolvers, serving a
> small customer base have high latency.

This is sort-of true, but I think it's too simple to provide usefully
actionable insights.

There are three components to the average latency:

 * stub-to-resolver latency

 * cache hit rate

 * cache miss latency

The stub/resolver latency can be measured the same way that you measure
other network RTT stats. This dominates the latency for cache hits, so the
closer the resolver the faster it will be for the majority of queries.

The hit rate goes up with the number of users, amongst other things.

The cache miss latency is highly variable and has a very long tail,
because your resolver could be talking to all sorts of working or broken
authoritative servers all over the world. This makes averages less useful
than you might hope.

You can eliminate a lot of cache miss latency by using a cache that does
"hammer time" prefetching; prefetching also becomes more effective with a
larger user population because it is driven by cache hits near the end of
a cache entry's TTL.

In general, if you are doing latency statistics, you should be looking at
histograms and percentiles, not averages - averages are dominated by tail
effects, but what you actually care about is outliers. Bert Hubert posted
about PowerDNS's really nice latency visualizations last month -
https://blog.powerdns.com/2017/11/02/dns-performance-metrics-the-logarithmic-percentile-histogram/

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Fair Isle: Southwest 7 to severe gale 9, becoming cyclonic severe gale 9 to
violent storm 11 later, perhaps hurricane force 12 later. Rough or very rough,
becoming high or very high later in west. Rain, showers later. Moderate or
poor.