Improve recursive DNS tunnel stability#87
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1463d2414c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
aminvakil
left a comment
There was a problem hiding this comment.
Disclaimer: Not a maintainer here.
|
Was this written with AI? How involved was it in this PR? |
Yes. I was testing and stabilizing build, in order to be more steady and reliable in work. |
|
I can't speak for this PR but just so you know, this repo is 100% AI. You are welcome to leave. |
Oh I wasn't implying it's an inherently bad thing, your project is evidence it isn't, I was just curious. |
Not at all! |
Summary
Validation
Local checks:
Production smoke test over public recursive DNS resolvers (Selectel client -> Hetzner server, domain delegated through Cloudflare):
Notes
Some public resolvers tested from the production client were not suitable for this transport profile: Yandex stalled after a few KB, Google-only failed to become ready reliably, and UltraDNS-only stalled mid-transfer. The longer cooldown avoids repeatedly spending probe/poll work on flapping recursive paths.