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
DNS improvements #16314
Comments
Also right now DNS has a hard coded refresh rate, and resolved entries are valid until that expires (ignoring TTL) Once we have support for stale DNS, I think we can have DNS results be respected for min(ttl, refresh_rate)* and use the stale DNS support to make sure we don't end up stalling requests when we have a slightly-expired entry *possibly actully max(30s, min(ttl, refresh_rate)) to make sure we don't DNS thrash |
This current behavior is a problem for some of my users. They were expecting that once the DNS result TTL expired, stale endpoints would not receive any new connections. My team saw some other tickets like this one: #2691 and we're not sure what the desired behavior is. Does the below describe the goal here? If DNS resolution fails:
|
Oh hey I totally failed to update this issue. As of #18408 Envoy is closer to respecting TTL. DNS reresolve will be more aggressive based on the DNS TTL, The main DNS cache will remove stale entries but I don't think it propagates the non-null to null address resolution to worker threads to really ensure no additional traffic. I think it'd be a fairly simple change, which I think should be config guarded as I think it's pretty common to use stale entries if re-resolve fails. |
Thank you! Didn't notice that issue, sorry.
Understood. That's the opposite of what this user wants in this particular case but I understand as a general principle the desire to allow the use of stale entries. |
HTTPS resource record (will improve QUIC usage)
Serve stale DNS results (improves performance and reliability)
DoT/DoH
The text was updated successfully, but these errors were encountered: