dynamic_forward_proxy: adding dns_resolvers to dns_cache used by the proxy filter#16294
dynamic_forward_proxy: adding dns_resolvers to dns_cache used by the proxy filter#16294mattklein123 merged 52 commits intoenvoyproxy:mainfrom
Conversation
…proxy filter Signed-off-by: Sixiang Gu <sgu@twitter.com>
Signed-off-by: Sixiang Gu <sgu@twitter.com>
Signed-off-by: Sixiang Gu <sgu@twitter.com>
|
Hi @ntgsx92, welcome and thank you for your contribution. We will try to review your Pull Request as quickly as possible. In the meantime, please take a look at the contribution guidelines if you have not done so already. |
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
adisuissa
left a comment
There was a problem hiding this comment.
Thanks for working on this.
One small comment about the API.
api/envoy/extensions/common/dynamic_forward_proxy/v3/dns_cache.proto
Outdated
Show resolved
Hide resolved
You are my hero! |
Signed-off-by: Sixiang Gu <sgu@twitter.com>
Signed-off-by: Sixiang Gu <sgu@twitter.com>
| // server startup. Apple's API only allows overriding DNS resolvers via system settings. | ||
| // If this setting is not specified, the value defaults to the default | ||
| // resolver, which uses /etc/resolv.conf for configuration. | ||
| repeated config.core.v3.Address dns_resolvers = 9; |
There was a problem hiding this comment.
How does this relate to #16237? Should this be a repeated DnsResolver and DnsResolver has both address and DnsLookupOptions?
There was a problem hiding this comment.
Thanks for letting me know about this change.
Looks like we're going to have resolvers, use_tcp_for_dns_lookups and no_defalt_search_domain as the arguments for DnsResolverImpl after #16237 is merged.
Seems like a good time to encapsulate those fields into a single proto message like DnsResolver.
@suniltheta How do you feel about the above changes?
There was a problem hiding this comment.
Thanks for letting me know about this PR. Just recently committed all of the changes for the PR #16237. A new protobuf message DnsResolverOptions in introduced which only include bool fields use_tcp_for_dns_lookups & no_default_search_domain.
Notice the name change from DnsLookupOptions to DnsResolverOptions.
Having said that if we move resolvers inside DnsResolverOptions, then we might have to take care of deprecating dns_resolvers present in config/cluster/v3/cluster.proto & dns_filter/v3alpha/dns_filter.proto.
I lean towards keeping the resolvers (repeated Address type) out of dedicated DnsResolverOptions. Only because if we combine we are looking at a slightly bloated PR and deprecation of a field. But I am also flexible in combining them, if doing so is the best option in the long run.
There was a problem hiding this comment.
Yeah, I would separate DnsResolverOptions and reference it from a DnsResolver message, which can deal with addressing and other concerns not related to resolution options.
There was a problem hiding this comment.
So is this the format of the protobuf message that is being proposed?
FORMAT A:
└── DnsResolver
├── <repeated Address> dns_resolvers
└── <DnsResolverOptions> dns_resolver_options
├── <bool> use_tcp_for_dns_lookups
├── <bool> no_default_search_domain
└── /<any options added in future>/
After the merge of #16237 we do
dispatcher().createDnsResolver(resolvers, dns_resolver_options);
Instead we would be doing
dispatcher().createDnsResolver(dns_resolvers);
So when we call the function createDnsResolver we would be only passing the object of type DnsResolver. Here dns_resolvers will contain both resolvers and dns_resolver_options.
There was a problem hiding this comment.
Yeah, fair point. Let's go with #16294 (comment) then.
There was a problem hiding this comment.
@htuch What's the next step? @suniltheta and I discussed merging this PR as it is and make another PR to add the new DnsResolver message.
There was a problem hiding this comment.
If we're planning on immediately restructuring in the next PR that isn't so great. Can we at least introduce the DnsResolver message and place the list of addresses in there?
There was a problem hiding this comment.
I am on board with this idea as well. We can place the DnsResolver protobuf message in api/envoy/config/core/v3/base.proto or any other place which makes more sense in this PR. Move repeated Address dns_resolvers inside DnsResolver like mentioned in previous comment. Finally as part of #16237 PR we can move the DnsResolverOptions inside the already merged DnsResolver message.
Signed-off-by: Sixiang Gu <sgu@twitter.com>
api/envoy/config/core/v3/base.proto
Outdated
| // Setting this value causes failure if the | ||
| // ``envoy.restart_features.use_apple_api_for_dns_lookups`` runtime value is true during | ||
| // server startup. Apple's API only allows overriding DNS resolvers via system settings. | ||
| repeated Address dns_resolvers = 1; |
There was a problem hiding this comment.
nit: Should we just name it resolvers instead of dns_resolvers ?
Signed-off-by: Sixiang Gu <sgu@twitter.com>
…proxy-main Signed-off-by: Sixiang Gu <sgu@twitter.com>
Signed-off-by: Sixiang Gu <sgu@twitter.com>
Signed-off-by: Sixiang Gu <sgu@twitter.com>
|
hi! Can I see how to use custom resolvers in advance? Thanks!! |
api/envoy/config/core/v3/base.proto
Outdated
| string identifier = 1; | ||
| } | ||
|
|
||
| // DNS resolver configuration which includes the underlying dns resolver addresses and options |
There was a problem hiding this comment.
Nit: suggest moving this to its own file resolver.proto in api/envoy/config/v3.
There was a problem hiding this comment.
While we are at this, what does others think about renaming DnsResolver to DnsResolverConfig ? So that we don't get confused between this message and a class of the same name DnsResolver. Apologies for not bringing this up earlier.
There was a problem hiding this comment.
Sure, although I think that's a good idea just because the naming scheme is clearer; avoiding C++ level type conflicts isn't that strong a motivator, we have namespaces etc to deal with that.
There was a problem hiding this comment.
is it also possible to foward ip directly without dns query?
I did curl -x http://envoyip:port -kLv http://targetip:port but envoy keep returning "No healthy upstream"
There was a problem hiding this comment.
So, definitely open to (maybe it's clearer) to call this DnsResolverConfig or DnsResolutionConfig.
There was a problem hiding this comment.
let's say, we can take that up renaming DnsResolver --> DnsResolverConfig or DnsResolutionConfig in the next PR #16237 ? Since all the CI got passed here, this can go?
Signed-off-by: Sixiang Gu <sgu@twitter.com>
Signed-off-by: Benjamin Peterson <benjamin@dropbox.com> Signed-off-by: Sixiang Gu <sgu@twitter.com>
This is a follow-up to: envoyproxy#14432 (comment) After that PR, it's no longer possible (unless you do a dynamic_cast) to set the remote address from a filter. This is something that we need to do because we have specialized logic for this (XFF doesn't work for us). So this adds an extension point which will allow us to push that logic down to ConnectionManagerUtility::mutateRequestHeaders() where it belongs. Signed-off-by: Raul Gutierrez Segales <rgs@pinterest.com> Signed-off-by: Sixiang Gu <sgu@twitter.com>
* docs: comment config extension Signed-off-by: Long Dai <long0dai@foxmail.com> Signed-off-by: Sixiang Gu <sgu@twitter.com>
…mit hook (envoyproxy#16505) Signed-off-by: Justin Ely <justincely@gmail.com> Signed-off-by: Sixiang Gu <sgu@twitter.com>
|
@envoyproxy/first-pass-reviewers assignee is @junr03 |
|
/retest |
|
Retrying Azure Pipelines: |
|
/retest |
|
Retrying Azure Pipelines: |
|
Looks like this test case is broken. Not sure why this PR will cause it to break. |
|
@junr03 Hey, mind taking a look at PR? Thanks! 😄 |
mattklein123
left a comment
There was a problem hiding this comment.
Thanks LGTM with small comments. Please also merge main.
/wait
api/envoy/extensions/common/dynamic_forward_proxy/v3/dns_cache.proto
Outdated
Show resolved
Hide resolved
test/extensions/common/dynamic_forward_proxy/dns_cache_impl_test.cc
Outdated
Show resolved
Hide resolved
Signed-off-by: Sixiang Gu <sgu@twitter.com>
|
/retest |
|
Retrying Azure Pipelines: |
…proxy filter (envoyproxy#16294) Signed-off-by: Sixiang Gu <sgu@twitter.com>
For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Commit Message:
Adding
dns_resolversoption to the dns cache used by the dynamic forward proxy filter. This enables users to switch default dns resolvers from/etc/resolv.confto custom dns resolvers in the proxy filter. By default, this option will be empty which means dns cache will continue to resolve names from servers listed in/etc/resolv.conf.Additional Description:
None
Risk Level:
Low
Testing:
Unit test added
Docs Changes:
Yes
Release Notes:
Added
Platform Specific Features:
N/A
[Optional Runtime guard:]
[Optional Fixes #Issue]
#15657
[Optional Deprecated:]
[Optional API Considerations:]