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.
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
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. 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@surfnet.nl