Conversation
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
|
I guess my question is do we ever always want to wait? Assume we have 5s timeout. I'd think all requests should wait 5s from "initial resolution attempt" but if request 1 was at T=0 and request 2 was T=1s I'd assume once we'd spent 5s trying to resolve we'd want to fail request 2 at T=5s not T=6s So basically I think we should ditch this approach, allow null updates for initial update, and fast-fail instead of continue if the resolved address is nullptr. |
Yes, I think I agree with this summary. |
…ons (#19588) in #17645 there was a bunch of discussion around the DNS cache returning null addresses and how to handle it. After discussion on #19461 we agreed to keep sending null updates, but to fast-fail if no address was resolved. Risk Level: Medium (data plane change) Testing: updated integration tests, unit tests Docs Changes: n/a Release Notes: inline Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
…ons (envoyproxy#19588) in envoyproxy#17645 there was a bunch of discussion around the DNS cache returning null addresses and how to handle it. After discussion on envoyproxy#19461 we agreed to keep sending null updates, but to fast-fail if no address was resolved. Risk Level: Medium (data plane change) Testing: updated integration tests, unit tests Docs Changes: n/a Release Notes: inline Signed-off-by: Alyssa Wilk <alyssar@chromium.org> Signed-off-by: Josh Perry <josh.perry@mx.com>
5 participants
Fixing unexpected behavior, where null updates are sent on first resolution.
With the new timeouts, the major functional change is that every DNS lookup for a given host will wait for the configured timeout before expiring, rather than the initial request(s) waiting until a one time timeout expiring, and all subsequent requests fast-failing.
I'm honestly not sure which is a preferred behavior given the DNS resolver will continue to attempt to re-resolve, so sending for discussion before I go fix up unit tests. Matt had been inclined to not send null updates but if we've got re-resolves going and there has been no response after the initial timeout I'm inclined to think continuing is the correct choice, but that the DNS filters should fast-fail if there's no resolution result.
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]