[GH-ISSUE #455] Remote Server Solver Cache Consistency Guarantee #165

New issue

Closed

opened 2026-02-26 04:34:15 +03:00 by kerem · 0 comments

kerem commented

2026-02-26 04:34:15 +03:00

Owner

Originally created by @mageddo on GitHub (May 29, 2024).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/455

What is Happening

Consider the following scenario (#440 )

I specified two addresses as DNS - 10.0.0.10 and 8.8.8.8. The 10.0.0.10 DNS is only accessible via VPN.

I connected to the VPN and used the dig command to query an address that has an IP within the 10.0.0.10 range. The command was: dig @172.17.0.1 (this is the IP of the Docker where the DNS is listening). There were no issues, and the response was the address 10.0.0.169.

Next, I disconnected from the VPN and tried the dig command again multiple times. I still received the internal IP 10.0.0.169, even though the site has an external IP address on 8.8.8.8. I waited 10 minutes to check the cache, but I still received the internal address.

I suppose this scenario it's related to the response entries cache. Once query has a successful response then DPS will cache it for the time the remote server specifies, 10.0.0.10 in that case.

What is expected

The thing is, once the VPN is disconnected and 10.0.0.10 DNS server is now unavailable, 10.0.0.169 reponse is obsolete, inconsistent, it looks like clear the remote cache when one of the remotes goes down or up, is the expected behavior.

Changes (Optional)

Do #449 first
Refactor SolverRemote which is with really big methods, see #459
Create a watch dog to keep testing the remote servers circuit, it will clear the cache whenever a remote server goes down or gets health again.

Originally created by @mageddo on GitHub (May 29, 2024). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/455 ### What is Happening Consider the [following scenario][1] (#440 ) > I specified two addresses as DNS - 10.0.0.10 and 8.8.8.8. The 10.0.0.10 DNS is only accessible via VPN. > > I connected to the VPN and used the dig command to query an address that has an IP within the 10.0.0.10 range. The command was: dig @172.17.0.1 (this is the IP of the Docker where the DNS is listening). There were no issues, and the response was the address 10.0.0.169. > > Next, I disconnected from the VPN and tried the dig command again multiple times. I still received the internal IP 10.0.0.169, even though the site has an external IP address on 8.8.8.8. I waited 10 minutes to check the cache, but I still received the internal address. > > > I suppose this scenario it's related to the response entries cache. Once query has a successful response then DPS will cache it for the time the remote server specifies, 10.0.0.10 in that case. ### What is expected The thing is, once the VPN is disconnected and 10.0.0.10 DNS server is now unavailable, 10.0.0.169 reponse is obsolete, inconsistent, it looks like clear the remote cache when one of the remotes goes down or up, is the expected behavior. ### Changes (Optional) * [x] Do #449 first * [x] Refactor `SolverRemote` which is with really big methods, see #459 * [x] Create a watch dog to keep testing the remote servers circuit, it will clear the cache whenever a remote server goes down or gets health again. [1]: https://github.com/mageddo/dns-proxy-server/issues/440#issuecomment-2135070799