Recursor: NS-IP based Resolution Strategy Under Network Isolation (RPZ / NS-Based Routing)

[Heshmatkhah]

Hi,

It has now been approximately 48 days since external internet access in Iran has been shutdowned.

A primary technical consequence is DNS fragmentation:

• Global resolvers cannot reach authoritative DNS servers hosted inside Iran.
• DNS resolvers within Iran can't reach authoritative servers outside the country.

I’ve tested multiple mitigation approaches without success. I’m now evaluating a policy-based routing solution at the DNS layer and need guidance on feasibility and implementation.

Current setup / constraints:

• I maintain a dataset of ~2k subnets (~11M IPs) that are currently reachable within Iran.
• Some resolvers in the environment have no internet access at all!
• Some resolvers can forward queries externally to some special servers (e.g., to 1.1.1.1, 4.2.2.4).

Target behavior:

1. For each DNS query, inspect the authoritative nameserver (NS) IP.
2. If the NS IP falls within the reachable subnet list → resolve normally using that NS.
3. If the NS IP is outside the list → forward the query to an upstream resolver with internet access.

What I’m looking for:

• A mechanism similar to NSIP / NSDNAME usable within RPZ or equivalent policy engines.
• Any existing tooling (BIND, Unbound, PowerDNS, Knot Resolver, etc.) that supports NS-based decision logic.
• Alternative architectures if this approach is fundamentally flawed.

Key challenge:
Resolvers without upstream internet must still be able to delegate “external” domains via a reachable forwarder, while preserving direct resolution for internal/reachable zones.

If anyone has implemented something similar or can suggest a workable design, I’d appreciate concrete guidance.

[Disordery]

Helloo . Have no idea bout this kinda stuff but lads pls lend a hand to the WEAKLINGS 🥀😭 -From iran

[omoerbeek]

I see no way to do this with Recursor ate the moment.

#15808 could be a building block, but as mentioned there there are issues with the PR in it current state. Also, the fallback forward should be of the recursive type, something which the PR does not do at all.

[Heshmatkhah]

Hi @omoerbeek,
Thanks for your reply.
Do you have any idea what can I do in this situation?

Is #15808 allow me to change remoteaddr based on NS-IP?

[omoerbeek]

Hi @omoerbeek, Thanks for your reply. Do you have any idea what can I do in this situation?

Is #15808 allow me to change remoteaddr based on NS-IP?

Yes , but as said, there are issues with the PR in its current form. Additionally, it is not a complete solution to your problem and would also require quite some Lua code to get somewhat close to the functionality you want.