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