starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #3295] DNS EDNS Client Subnet (ECS) - RFC7871 #1163

New issue

Open

opened 2026-03-16 01:46:59 +03:00 by kerem · 3 comments

kerem commented

2026-03-16 01:46:59 +03:00

Owner

Originally created by @brr53 on GitHub (Oct 2, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3295

Is your feature request related to a problem? Please describe.
DNS answers always reflect the resolver’s location, not the subnet I need to test from, making CDN/GSLB testing inaccurate.

Describe the solution you'd like
Support EDNS Client Subnet (ECS) so I can send queries “as if” from a given subnet (e.g. 1.1.1.1/32) to reproduce region-specific answers.

In cURL we do it like: dig @1.1.1.1 www.example.com A +subnet=198.51.100.0/24

Describe alternatives you've considered
Workarounds include spinning up VMs in target regions or relying on custom resolvers.

Additional context
This enables accurate CDN edge validation, incident triage, and geo-routing tests without extra infrastructure.

Originally created by @brr53 on GitHub (Oct 2, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3295 **Is your feature request related to a problem? Please describe.** DNS answers always reflect the resolver’s location, not the subnet I need to test from, making CDN/GSLB testing inaccurate. **Describe the solution you'd like** Support EDNS Client Subnet (ECS) so I can send queries “as if” from a given subnet (e.g. 1.1.1.1/32) to reproduce region-specific answers. In cURL we do it like: dig @1.1.1.1 www.example.com A +subnet=198.51.100.0/24 **Describe alternatives you've considered** Workarounds include spinning up VMs in target regions or relying on custom resolvers. **Additional context** This enables accurate CDN edge validation, incident triage, and geo-routing tests without extra infrastructure.

kerem added the

enhance

features:edns

feature:global_lb

labels

2026-03-16 01:46:59 +03:00

kerem commented

2026-03-16 01:47:10 +03:00

Author

Owner

@djc commented on GitHub (Oct 6, 2025):

Which API do you need this for? What are you trying to do exactly?

There is some basic infrastructure for this -- hickory_proto::rr::rdata::opt::ClientSubnet, which you can add out to going messages by using Message::set_edns().

Though note this part of the RFC:

2. Privacy Note

   If we were just beginning to design this mechanism, and not
   documenting existing protocol, it is unlikely that we would have done
   things exactly this way.

   The IETF is actively working on enhancing DNS privacy
   [[DPRIVE_Working_Group](https://www.rfc-editor.org/rfc/rfc7871#ref-DPRIVE_Working_Group)] and the reinjection of metadata [[METADATA](https://www.rfc-editor.org/rfc/rfc7871#ref-METADATA)] has
   been identified as a problematic design pattern.

   As noted above however, this document primarily describes existing
   behavior of a deployed method to further the understanding of the
   Internet community.

   We recommend that the feature be turned off by default in all
   nameserver software, and that operators only enable it explicitly in
   those circumstances where it provides a clear benefit for their
   clients.  We also encourage the deployment of means to allow users to
   make use of the opt-out provided.  Finally, we recommend that others
   avoid techniques that may introduce additional metadata in future
   work, as it may damage user trust.

   Regrettably, support for the opt-out provisions of this specification
   are currently limited.  Only one stub resolver, getdns, is known to
   be able to originate queries with anonymity requested, and as yet no
   applications are known to be able to indicate that user preference to
   the stub resolver.

So any implementation to do more with this should be opt-in.

@djc commented on GitHub (Oct 6, 2025): Which API do you need this for? What are you trying to do exactly? There is some basic infrastructure for this -- `hickory_proto::rr::rdata::opt::ClientSubnet`, which you can add out to going messages by using `Message::set_edns()`. Though note [this part](https://www.rfc-editor.org/rfc/rfc7871#section-2) of the RFC: ``` 2. Privacy Note If we were just beginning to design this mechanism, and not documenting existing protocol, it is unlikely that we would have done things exactly this way. The IETF is actively working on enhancing DNS privacy [[DPRIVE_Working_Group](https://www.rfc-editor.org/rfc/rfc7871#ref-DPRIVE_Working_Group)] and the reinjection of metadata [[METADATA](https://www.rfc-editor.org/rfc/rfc7871#ref-METADATA)] has been identified as a problematic design pattern. As noted above however, this document primarily describes existing behavior of a deployed method to further the understanding of the Internet community. We recommend that the feature be turned off by default in all nameserver software, and that operators only enable it explicitly in those circumstances where it provides a clear benefit for their clients. We also encourage the deployment of means to allow users to make use of the opt-out provided. Finally, we recommend that others avoid techniques that may introduce additional metadata in future work, as it may damage user trust. Regrettably, support for the opt-out provisions of this specification are currently limited. Only one stub resolver, getdns, is known to be able to originate queries with anonymity requested, and as yet no applications are known to be able to indicate that user preference to the stub resolver. ``` So any implementation to do more with this should be opt-in.

kerem commented

2026-03-16 01:47:15 +03:00

Author

Owner

@brr53 commented on GitHub (Oct 6, 2025):

Thank you @djc

Which API do you need this for?

We want to use it via settings in ResolverOpts from our client application. We use ResolverOpts with TokioResolver.

What are you trying to do exactly?

For globally available applications, we want to test and make sure that our clients are given the intended/correct edge IP addresses when connecting to our servers. Testing via Client Subnet is much more preferable than setting up temporary servers around the world to test this.

There are many other use usecases also such as censorship resistance (resolving to a foreign, unfiltered, unbiased server)

add to outgoing messages by using Message

Using Message directly appears to require much manual handling and not let us use the built-in caching features.

implementation to do more with this should be opt-in.

Of course, the default works fine for most people. Regarding privacy, Google DNS enforces the smallest subnet size to be a /24 to prevent the exact IP address from being sent. With Hickory, we'd ideally pass the subnet as a string and have direct control & knowledge.

@brr53 commented on GitHub (Oct 6, 2025): Thank you @djc > Which API do you need this for? We want to use it via settings in ResolverOpts from our client application. We use ResolverOpts with TokioResolver. > What are you trying to do exactly? For globally available applications, we want to test and make sure that our clients are given the intended/correct edge IP addresses when connecting to our servers. Testing via Client Subnet is much more preferable than setting up temporary servers around the world to test this. There are many other use usecases also such as censorship resistance (resolving to a foreign, unfiltered, unbiased server) > add to outgoing messages by using Message Using Message directly appears to require much manual handling and not let us use the built-in caching features. > implementation to do more with this should be opt-in. Of course, the default works fine for most people. Regarding privacy, Google DNS enforces the smallest subnet size to be a /24 to prevent the exact IP address from being sent. With Hickory, we'd ideally pass the subnet as a string and have direct control & knowledge.

kerem commented

2026-03-16 01:47:20 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 7, 2025):

Previous discussions and issues in this area: #1924, #350

@bluejekyll commented on GitHub (Oct 7, 2025): Previous discussions and issues in this area: #1924, #350

kerem referenced this issue

2026-03-16 04:57:49 +03:00

[PR #1163] [MERGED] Keep OS error information on io::Error #2032