Dear colleagues,

RIPE Atlas is currently running a series of DNS SOA built-in
measurements* towards all of the root servers from all probes. During
the recent DNS measurements hackathon** it became apparent that for some
use cases it would be useful to have SOA queries from all probes with
the NSID EDNS option set, in order to be able to match up responses with
the particular responding instances in an anycasted (or load balanced)
setup.

We would like to ask for feedback on two alternative options for
implementing this change. They are:

1) Enable the NSID option for the existing built-in measurements towards
the nine root servers which support it.

2) Start a new set of built-in measurements towards the nine root
servers which support NSID.

The advantages of option (1) are that it will be possible to compare and
contrast the two sets of results, and that historical data for the
existing built-ins will remain consistent with the current results. A
very simple analysis shows that there is no overall increase in query
error rates through enabling NSID, but there are bound to be individual
marginal cases where queries fail or produce different results with NSID
set but succeed without it.

The advantages of option (2) are that there will be no increase in
result storage usage -- the current IPv4+IPv6 UDP SOA built-ins towards
the nine supporting root servers adds up to about 80 results per second
(~1.5% of the total results in the system).
This could potentially be mitigated by reducing the frequency for these
new measurements, but perhaps more important than the slightly increased
load is the
potential user confusion caused by generating and providing two very
similar sets of
measurements.

Please let us know if you have any preference for which way we go on
this, particularly if you have a (current or future) use case for this
kind of data.

Kind regards,
Chris Amin
RIPE NCC

* https://atlas.ripe.net/docs/built-in/
** https://labs.ripe.net/Members/becha/results-dns-measurements-hackathon



Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to