# DNS measurement parameters: ECS-DNS and public resolver

**URL:** <https://forum.ripe.net/t/dns-measurement-parameters-ecs-dns-and-public-resolver/1333>\
**Category:** RIPE Atlas\
**Tags:** dns\
**Created:** [14 February 2025 13:38 UTC](https://forum.ripe.net/t/dns-measurement-parameters-ecs-dns-and-public-resolver/1333 "2025-02-14T13:38:00Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![HugoRimlinger](https://avatars.discourse-cdn.com/v4/letter/h/8baadc/32.png) [@HugoRimlinger](https://forum.ripe.net/u/HugoRimlinger)\
**Post date:** [14 February 2025 13:38 UTC](https://forum.ripe.net/t/dns-measurement-parameters-ecs-dns-and-public-resolver/1333/1 "2025-02-14T13:38:00Z")

</div>

Hello everyone,

I come in search of information. As part of a research project, we would like to perform DNS measurements that require to use the Extended Client Subnet option of DNS (ECS-DNS) and Google Public DNS resolver.  
I could not find information related to those two topics, it is possible? If yes, sorry in advance that I missed the information. If no… well, thank you anyway!

\*EDIT: So sorry, I just realised the resolver can be specified in the target parameter. My question is only on the topic of ECS-DNS.

Cheers.

---

<div class="post-metadata">

**Author:** ![camin](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.ripe.net/camin/32/243_2.png) [@camin](https://forum.ripe.net/u/camin)\
**Post date:** [18 February 2025 13:39 UTC](https://forum.ripe.net/t/dns-measurement-parameters-ecs-dns-and-public-resolver/1333/2 "2025-02-18T13:39:51Z")

</div>

Hello,

This option exists for DNS measurements, would it suffice for your use case?

**default\_client\_subnet** _(boolean)_ Enable an EDNS Client Subnet (RFC7871) of 0.0.0.0/0 0 or ::/0

(Retrieved from [RIPE Atlas docs | REST API Reference | Docs](https://atlas.ripe.net/docs/apis/rest-api-reference/#measurements))

Chris

---

<div class="post-metadata">

**Author:** ![HugoRimlinger](https://avatars.discourse-cdn.com/v4/letter/h/8baadc/32.png) [@HugoRimlinger](https://forum.ripe.net/u/HugoRimlinger)\
**Post date:** [19 February 2025 09:15 UTC](https://forum.ripe.net/t/dns-measurement-parameters-ecs-dns-and-public-resolver/1333/3 "2025-02-19T09:15:56Z")

</div>

Hello Chris,

Thanks for taking the time to answer and for pointing out this parameter!  
Sadly we would like to inject an arbitrary client subnet within the DNS request (if you are familiar with the option). A bit like what is possible with the [ZDNS](https://github.com/zmap/zdns) tool.  
The idea behind that is to get the response for a domain name for virtually any /24 subnet.  
I guess this could be a great add-on for DNS measurements.  
But not for now apparently, thanks anyway!

---

<div class="post-metadata">

**Author:** ![robertk](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.ripe.net/robertk/32/413_2.png) [@robertk](https://forum.ripe.net/u/robertk)\
**Post date:** [19 February 2025 12:07 UTC](https://forum.ripe.net/t/dns-measurement-parameters-ecs-dns-and-public-resolver/1333/4 "2025-02-19T12:07:09Z")

</div>

Hi Hugo, I can see the appeal for a researcher to be able to use “virtually any /24 subnet” 🙂 But it does sound less attractive from the perspective of operators of those networks. Can you evaluate what the benefits of this feature would be for these network operators?

---

<div class="post-metadata">

**Author:** ![HugoRimlinger](https://avatars.discourse-cdn.com/v4/letter/h/8baadc/32.png) [@HugoRimlinger](https://forum.ripe.net/u/HugoRimlinger)\
**Post date:** [20 February 2025 10:53 UTC](https://forum.ripe.net/t/dns-measurement-parameters-ecs-dns-and-public-resolver/1333/5 "2025-02-20T10:53:47Z")

</div>

Haha, that, I can understand. I am biased by my own interests…

Considering the increase of ECS-DNS amount of traffic and its important role in the context of large public DNS revolvers (e.g. Google Public DNS), I think that the ability for ISPs to evaluate the impact of this option on client’s redirection is worth of interest.

While saying that, I also realise that this evaluation can be made from a single vantage point (without requiring RIPE Atlas infra). Our use-case is…very specific to say the least!
