[dns-wg] NSID option on the RIPE Atlas SOA measurements of the root servers

Hi Chris,

Chris Amin wrote:
> 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.

I don't quite see how option 2 does not result in an increase in storage
requirements, and you seem to contradict this by then talking about
reducing the measurement frequency. Perhaps I misunderstand what you're
saying here.

>From a research perspective, I would argue that it would at least
temporarily make sense to have the two (slightly) different measurements
(i.e. the old without and the new one with NSID enabled) running in
parallel, just to flesh out whether any significant differences occur.
If storage and measurement performance are not a (serious) issue, then
running two separate measurements would be preferable, in my opinion, to
safeguard continuity of the existing measurements. In my experience such
longitudinal datasets keep increasing in value as time progresses, and
are more valuable if they have a consistent measurement methodology.
Based on that argument, discontinuing or altering and existing
measurement should only be done if there are good reasons for it.

Best regards,

Roland

-- 
-- Roland M. van Rijswijk - Deij
-- SURFnet bv
-- w: http://www.surf.nl/en/about-surf/subsidiaries/surfnet
-- e: roland.vanrijswijk at surfnet.nl