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 #1924] Support for GeoDNS #818

New issue

Open

opened 2026-03-16 00:24:26 +03:00 by kerem · 8 comments

kerem commented

2026-03-16 00:24:26 +03:00

Owner

Originally created by @FireMasterK on GitHub (May 2, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1924

Is your feature request related to a problem? Please describe.
I'd like to return different responses based on the requestee's IP address's geolocation.

Describe the solution you'd like
The ability to serve different records based on the requestee's IP geo-location.

Additional context
N/A

Originally created by @FireMasterK on GitHub (May 2, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1924 **Is your feature request related to a problem? Please describe.** I'd like to return different responses based on the requestee's IP address's geolocation. **Describe the solution you'd like** The ability to serve different records based on the requestee's IP geo-location. **Additional context** N/A

kerem commented

2026-03-16 00:24:32 +03:00

Author

Owner

@djc commented on GitHub (May 4, 2023):

This seems like a pretty niche use case. I suggest you write your own RequestHandler which routes requests per your requirements. If you run into trouble building something out feel free to ask more specific questions.

@djc commented on GitHub (May 4, 2023): This seems like a pretty niche use case. I suggest you write your own `RequestHandler` which routes requests per your requirements. If you run into trouble building something out feel free to ask more specific questions.

kerem commented

2026-03-16 00:24:37 +03:00

Author

Owner

@ztheory commented on GitHub (Jul 5, 2023):

This seems like a pretty niche use case.

Quite the opposite. Many of largest CDNs use the source IP address of the recursive DNS request to serve a geo-specific RR which routes the client to the closest-possible Edge PoP.

This is true for, but not limited to:

Akamai
Fastly
Microsoft/Azure
Meta

In addition, this can be used to block certain countries or !your country if your website/domain only serves a certain market.

BIND9:
https://kb.isc.org/docs/aa-01149
PowerDNS Authoritative:
https://doc.powerdns.com/authoritative/backends/geoip.html?highlight=geoip

@ztheory commented on GitHub (Jul 5, 2023): > This seems like a pretty niche use case. Quite the opposite. Many of largest CDNs use the source IP address of the recursive DNS request to serve a geo-specific RR which routes the client to the closest-possible Edge PoP. This is true for, but not limited to: * Akamai * Fastly * Microsoft/Azure * Meta In addition, this can be used to block certain countries or !your country if your website/domain only serves a certain market. BIND9: https://kb.isc.org/docs/aa-01149 PowerDNS Authoritative: https://doc.powerdns.com/authoritative/backends/geoip.html?highlight=geoip

kerem commented

2026-03-16 00:24:42 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jul 8, 2023):

I’m generally ok with this implementing this, but the concerns I have are generally around privacy issues. So any implementation we do, it would be good the ensure that we 0 out the last octet in IPv4 and the last 64 bits in ipv6 (double check the ipv6 rules, it might be better to mask up to /48).

@bluejekyll commented on GitHub (Jul 8, 2023): I’m generally ok with this implementing this, but the concerns I have are generally around privacy issues. So any implementation we do, it would be good the ensure that we 0 out the last octet in IPv4 and the last 64 bits in ipv6 (double check the ipv6 rules, it might be better to mask up to /48).

kerem commented

2026-03-16 00:24:47 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jul 8, 2023):

By the way, the scaffolding is there for this feature, it just needs to be added to the EDNS record, I think adding it as an option when configuring the resolver would be ok (that is I’m thinking we should put the onus on the caller to configure the proper source address).

@bluejekyll commented on GitHub (Jul 8, 2023): By the way, the scaffolding is there for this feature, it just needs to be added to the EDNS record, I think adding it as an option when configuring the resolver would be ok (that is I’m thinking we should put the onus on the caller to configure the proper source address).

kerem commented

2026-03-16 00:24:52 +03:00

Author

Owner

@ztheory commented on GitHub (Jul 8, 2023):

Most recursive resolver software has ECS disabled by default. Cloudflare doesn't support it, and Quad9 only supports it on an alternative service address (9.9.9.11). On the authoritative side, in the absence of ECS, the client IP should be used for the GeoIP lookup.

Most ECS-enabled resolvers behave nicely by calculating and rounding down to the /24, /22, or /52 (IPv6) when recursing, unless the client manually specified this using dig, etc. On the resolver side, perhaps creating an option to enforce the rounding down via an overwrite, as the client may desire to send a /32 or a custom subnet for testing purposes, but on the flip side, Akamai requires that the resolver overwrite any user-specified subnet in order to accept ECS from a recursive service.

I'm not a programmer, so I can't speak intelligently about how this implementation might look at a low level, but I was roughly imaging this might entail using the MaxMindDB crate to query a local .mmdb database: https://crates.io/crates/maxminddb , or just importing the CSV version.

After the GeoIP lookup is complete, being able to specify an action based on matching rules via the ISO-3166-2 region and/or country code.

@ztheory commented on GitHub (Jul 8, 2023): Most recursive resolver software has ECS disabled by default. Cloudflare doesn't support it, and Quad9 only supports it on an alternative service address (9.9.9.11). On the authoritative side, in the absence of ECS, the client IP should be used for the GeoIP lookup. Most ECS-enabled resolvers behave nicely by calculating and rounding down to the /24, /22, or /52 (IPv6) when recursing, unless the client manually specified this using `dig`, etc. On the resolver side, perhaps creating an option to enforce the rounding down via an overwrite, as the client may desire to send a /32 or a custom subnet for testing purposes, but on the flip side, Akamai requires that the resolver overwrite any user-specified subnet in order to accept ECS from a recursive service. I'm not a programmer, so I can't speak intelligently about how this implementation might look at a low level, but I was roughly imaging this might entail using the MaxMindDB crate to query a local .mmdb database: https://crates.io/crates/maxminddb , or just importing the CSV version. After the GeoIP lookup is complete, being able to specify an action based on matching rules via the ISO-3166-2 region and/or country code.

kerem commented

2026-03-16 00:24:57 +03:00

Author

Owner

@Jameel-Hao commented on GitHub (Aug 23, 2025):

GeoDNS is a very very important feature in CDN scenario. And It can also extend user-defined CIDR scheduler...
I have 5 years of experience in DNS development and have spent a lot of time focusing on this feild.
Compared with model of bind9, if hickory implement a user-defined GeoDNS, it will be very competitive.

@Jameel-Hao commented on GitHub (Aug 23, 2025): GeoDNS is a very very important feature in CDN scenario. And It can also extend user-defined CIDR scheduler... I have 5 years of experience in DNS development and have spent a lot of time focusing on this feild. Compared with model of bind9, if hickory implement a user-defined GeoDNS, it will be very competitive.

kerem commented

2026-03-16 00:25:02 +03:00

Author

Owner

@djc commented on GitHub (Aug 25, 2025):

It's clear that this is a fairly popular feature and I think it could make sense. However, I think this would probably need either someone to come in and implement it or someone to fund the work. For the latter case, feel free to contact me via email (should be easy to find via my homepage).

@djc commented on GitHub (Aug 25, 2025): It's clear that this is a fairly popular feature and I think it could make sense. However, I think this would probably need either someone to come in and implement it or someone to fund the work. For the latter case, feel free to contact me via email (should be easy to find via my homepage).

kerem commented

2026-03-16 00:25:08 +03:00

Author

Owner

@Jameel-Hao commented on GitHub (Aug 26, 2025):

OK. I had implemented it in C language before....
I will try to implement a RUST version.. But I am a fresher in RUST:<, maybe you have to wait long long time.
The GeoDNS functions contains:
1. ipmap Create a template of Geo Information which users can define by themselves. This is the configuration of GeoDNS.
Maybe the template like this: CIDR continent country province city isp ...
2. scheduler Provide API to query the Geo information from the ipmap and match one recordset Geo configuration(Maybe this is a map structure). Need to combine Geo information, such as Orange_Paris(isp_city) is the route or schedule with the highest weight... EU(continent) is the lowest weight...
Input: ip address, tenant id, assosiated Geo map(this one is assosiated with recordset)
Output: The Geo node in recordset and the weight(isp_province) -- This should be very complicated and needs to be adapted to the current model.
3. Adapt to current DNS query logic. Add the EDNS logic(eg. EDNS Scope Prefix)
4. Ops Api. Query the Geo Information by digging with edns.. This function not only confirm our Geo information is correct, but also confirm the source ip address... it's very important.
Input: dig txt.hickorygeo.com txt subnet=2.0.0.0
Output:
;; ANSWER SECTION:
txt.hickorygeo.com 300 IN TXT "client ip: 2.0.0.0 geo: continent country province city isp"

@Jameel-Hao commented on GitHub (Aug 26, 2025): OK. I had implemented it in C language before.... I will try to implement a RUST version.. But I am a fresher in RUST:<, maybe you have to wait long long time. The GeoDNS functions contains: **1. ipmap** Create a template of Geo Information which users can define by themselves. This is the configuration of GeoDNS. Maybe the template like this: _CIDR continent country province city isp ..._ **2. scheduler** Provide API to query the Geo information from the ipmap and match one recordset Geo configuration(Maybe this is a map structure). Need to combine Geo information, such as Orange_Paris(isp_city) is the route or schedule with the highest weight... EU(continent) is the lowest weight... Input: ip address, tenant id, assosiated Geo map(this one is assosiated with recordset) Output: The Geo node in recordset and the weight(isp_province) -- This should be very complicated and needs to be adapted to the current model. **3. Adapt to current DNS query logic**. Add the EDNS logic(eg. EDNS Scope Prefix) **4. Ops Api**. Query the Geo Information by digging with edns.. This function not only confirm our Geo information is correct, but also confirm the source ip address... it's very important. Input: dig txt.hickorygeo.com txt subnet=2.0.0.0 Output: ;; ANSWER SECTION: txt.hickorygeo.com 300 IN TXT "client ip: 2.0.0.0 geo: continent country province city isp"