-
Notifications
You must be signed in to change notification settings - Fork 5.4k
dns cache: add DNS query timeout option #17207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
baef43e
dns cache: add DNS query timeout option
mattklein123 71de6be
Merge remote-tracking branch 'origin/main' into dns_timeout
mattklein123 e822fdf
comments
mattklein123 7a2708a
Merge remote-tracking branch 'origin/main' into dns_timeout
mattklein123 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8 changes: 7 additions & 1 deletion
8
api/envoy/extensions/common/dynamic_forward_proxy/v4alpha/dns_cache.proto
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8 changes: 7 additions & 1 deletion
8
generated_api_shadow/envoy/extensions/common/dynamic_forward_proxy/v3/dns_cache.proto
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
8 changes: 7 additions & 1 deletion
8
generated_api_shadow/envoy/extensions/common/dynamic_forward_proxy/v4alpha/dns_cache.proto
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make it a bit more clear if the original request is canceled or if we retry in parallel like hedging? I recall (possibly erroneously) that was the latency-improving timeout folks often use on mobile of "if DNS does not return in this time use stale result" which implies to me 5s happens frequently enough we don't want to cancel. Alternately if platform implementation details would result in the OS getting the results for the original request that's Ok too but I'm not sure how to regression test that. cc @RyanTheOptimist @DavidSchinazi for thoughts as this is more their area than mine.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this is a good call out. The current implementation will actually cancel and not hedge. Part of the impetus for this change is we think the iOS/apple resolver is occasionally getting wedged, so we are going to accompany this with some changes to that resolver to hopefully make it better handle timeouts (cc @junr03). One thing we might want to do here is actually modify the
cancel()API to take a reason parameter, so that the impl can do different things if it's a normal cancellation vs. a timeout. I think in the case of timeout we might want to have the impls tare down the DNS connections and make new ones. Let me do that in this change.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does "hedge" mean in this context?
I'm not sure about 5s being the right value. I think that's probably too short for a client network stack which need to operate in congested lossy networks. I could look at some telemetry from Chrome around DNS resolution times if that would help? (Of course, I don't know much about the forward proxy deployments so maybe that's the right value for them)
FWIW, the way the stale DNS racing works in Chrome with QUIC is as follows. First host resolution is attempted. If no "Fresh" (presumably cached) result is available but a stale result is (this is all synchronous and does not involve waiting for network events) then the QUIC connection is started using the stale DNS entry. At this point we are running the QUIC handshake in parallel with the DNS request. We only use the resulting QUIC connection to send requests on if the DNS comes back and matches the IP connected to.
To do this, Chrome's resolver basically has two APIs. One for getting a fresh address (which will be async if the address is not cached) and another for getting a stale address (which is always synchronous but may return nothing).
Does that help?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that would be super useful. My feeling though is this is an OK default for server and we can tune it for envoy-mobile config.
Yes definitely. I think this is what we need to move towards. cc @junr03
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'm good with the default being server side as long as we make sure that @goaway and @junr03 and co know to tweak their defaults when they pick up the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh and @RyanTheOptimist hedging is an option in router config where you can configure a retry in parallel - 2 requests to 2 upstreams, and cancel the slow one once the first response headers coming back. My point was I was ok with 5s for mobile if we were kicking off a second attempt not canceling the first but I'm also Ok with just upping the default on mobile.