Public DNS "id.server" responses

DNS resolvers can be configured to respond to specific queries to allow the identification of which server or location is handling requests for a user. More background can be found in RFC 4892.

Public anycast DNS services have locations distributed globally, and so RIPE Atlas can query these to help determine where anycast routing is directing these queries. We run measurements to two public resolver services that respond to these queries, and we do so at an extremely low frequency: once per week, for each available probe. These measurements have been running since April 2018, and ought to provide insight into the deployment of these services, and the stability of anycast routing to them.

The answers vary by service. Examples of what the answer to these queries look like:

$ dig +short CHAOS TXT id.server @1.1.1.1
"AMS"

$ dig +short CHAOS TXT id.server @9.9.9.9
"res310.ams.rrdns.pch.net"

To get at the data, measurement IDs are:

• Cloudflare
  • 1.1.1.1: 12016253
  • 2606:4700:4700::1111: 12016262
• Quad9
  • 9.9.9.9: 12016241
  • 2620:fe::fe: 12016229

Measurement tags are:

• Cloudflare: idserver-cloudflare
• Quad9: idserver-quad9

In Aug 2022 we discovered Google public DNS ( 8.8.8.8 ) sets NSID when requested, so we created a measurement for this:

• Google (these run once a day, with a 'spread' of half a day, with the intent of uniformly distributing the query load over the whole day)
  • IPv4 43869257
  • IPv6 43896772

After conversations with admins of Quad9 we also added NSID queries for Quad9 (daily, 0.5d spread):

• IPv4 44040749 (this one needs to go eventually, because RD=0)
• IPv4 44137248 (this one with RD=1, because REFUSED answer if not cached)

Because id.server responses and NSID responses are generated by different parts of the Quad9 infrastructure, it is not possible to create a single measurement that captures both the id.server and the NSID.