Skip to content

dynamic_forward_proxy: adding dns_resolvers to dns_cache used by the proxy filter#16294

Merged
mattklein123 merged 52 commits intoenvoyproxy:mainfrom
ntgsx92:main
May 27, 2021
Merged

dynamic_forward_proxy: adding dns_resolvers to dns_cache used by the proxy filter#16294
mattklein123 merged 52 commits intoenvoyproxy:mainfrom
ntgsx92:main

Conversation

@ntgsx92
Copy link
Copy Markdown
Contributor

@ntgsx92 ntgsx92 commented May 3, 2021

For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md

Commit Message:
Adding dns_resolvers option to the dns cache used by the dynamic forward proxy filter. This enables users to switch default dns resolvers from /etc/resolv.conf to 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:]

Sixiang Gu added 3 commits May 3, 2021 16:14
…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>
@repokitteh-read-only
Copy link
Copy Markdown

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.

🐱

Caused by: #16294 was opened by ntgsx92.

see: more, trace.

@repokitteh-read-only
Copy link
Copy Markdown

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/envoy/.
envoyproxy/api-shepherds assignee is @adisuissa
CC @envoyproxy/api-watchers: FYI only for changes made to api/envoy/.

🐱

Caused by: #16294 was opened by ntgsx92.

see: more, trace.

Copy link
Copy Markdown
Contributor

@adisuissa adisuissa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this.
One small comment about the API.

@malza321
Copy link
Copy Markdown

malza321 commented May 4, 2021

For an explanation of how to fill out the fields, please see the relevant section

in PULL_REQUESTS.md

Commit Message:

Adding dns_resolvers option to the dns cache used by the dynamic forward proxy filter. This enables users to switch default dns resolvers from /etc/resolv.conf to 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:]

You are my hero!

Sixiang Gu added 2 commits May 4, 2021 10:25
Signed-off-by: Sixiang Gu <sgu@twitter.com>
Signed-off-by: Sixiang Gu <sgu@twitter.com>
Copy link
Copy Markdown
Contributor

@adisuissa adisuissa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

API lgtm.
@htuch can you please take a quick look at the API changes?

// 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;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this relate to #16237? Should this be a repeated DnsResolver and DnsResolver has both address and DnsLookupOptions?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

@suniltheta suniltheta May 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

@suniltheta suniltheta May 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, fair point. Let's go with #16294 (comment) then.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Signed-off-by: Sixiang Gu <sgu@twitter.com>
// 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;
Copy link
Copy Markdown
Contributor

@suniltheta suniltheta May 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Should we just name it resolvers instead of dns_resolvers ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

Sixiang Gu added 4 commits May 14, 2021 15:26
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>
@malza321
Copy link
Copy Markdown

hi!

Can I see how to use custom resolvers in advance?
envoy.yaml will be great help to let me understand!

Thanks!!

string identifier = 1;
}

// DNS resolver configuration which includes the underlying dns resolver addresses and options
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: suggest moving this to its own file resolver.proto in api/envoy/config/v3.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, definitely open to (maybe it's clearer) to call this DnsResolverConfig or DnsResolutionConfig.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

API LGTM modulo nit.

Sixiang Gu and others added 5 commits May 18, 2021 14:47
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>
@repokitteh-read-only
Copy link
Copy Markdown

@envoyproxy/first-pass-reviewers assignee is @junr03

🐱

Caused by: a #16294 (review) was submitted by @adisuissa.

see: more, trace.

@ntgsx92
Copy link
Copy Markdown
Contributor Author

ntgsx92 commented May 20, 2021

/retest

@repokitteh-read-only
Copy link
Copy Markdown

Retrying Azure Pipelines:
Retried failed jobs in: envoy-presubmit

🐱

Caused by: a #16294 (comment) was created by @ntgsx92.

see: more, trace.

@ntgsx92
Copy link
Copy Markdown
Contributor Author

ntgsx92 commented May 21, 2021

/retest

@repokitteh-read-only
Copy link
Copy Markdown

Retrying Azure Pipelines:
Check envoy-presubmit isn't fully completed, but will still attempt retrying.
Retried failed jobs in: envoy-presubmit

🐱

Caused by: a #16294 (comment) was created by @ntgsx92.

see: more, trace.

@ntgsx92
Copy link
Copy Markdown
Contributor Author

ntgsx92 commented May 21, 2021

Looks like this test case is broken. Not sure why this PR will cause it to break.

@ntgsx92
Copy link
Copy Markdown
Contributor Author

ntgsx92 commented May 24, 2021

@junr03 Hey, mind taking a look at PR? Thanks! 😄

Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks LGTM with small comments. Please also merge main.

/wait

Sixiang Gu added 2 commits May 26, 2021 14:11
Signed-off-by: Sixiang Gu <sgu@twitter.com>
@mattklein123
Copy link
Copy Markdown
Member

/retest

@repokitteh-read-only
Copy link
Copy Markdown

Retrying Azure Pipelines:
Retried failed jobs in: envoy-presubmit

🐱

Caused by: a #16294 (comment) was created by @mattklein123.

see: more, trace.

Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@mattklein123 mattklein123 merged commit e5b4a98 into envoyproxy:main May 27, 2021
leyao-daily pushed a commit to leyao-daily/envoy that referenced this pull request Sep 30, 2021
…proxy filter (envoyproxy#16294)

Signed-off-by: Sixiang Gu <sgu@twitter.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

deps Approval required for changes to Envoy's external dependencies

Projects

None yet

Development

Successfully merging this pull request may close these issues.