DNS resolver as an extension point #14310
Comments
htuch
added
triage
|
It would certainly be feasible. @mattklein123 and I discussed it somewhere (I am trying to find where) when I was adding the Apple Resolver, and decided for the current setup for expediency. However, there aren't any major technical reasons why the resolvers couldn't be formalized as an extension point. In fact, it would help clean up configuration that doesn't apply to all resolvers. Resolvers are created via the dispatcher, so there is already a small surface for resolver creation. In terms of configuration consumption there are a few places where the extension would have to be accessible: some clusters, dns cache, udp dns filter; and additionally the "default" server resolver. So overall, my assessment is that while there is some cleaning up to do it would actually be nice to elevate resolvers as an extension point, and something I would have wanted to do if I had had more time in the past. Happy to help whomever wants to take this on. |
|
Yes I agree making the DNS resolver a full extension would be good. |
|
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
github-actions
bot
added
the
stale
htuch
added
help wanted
|
I am looking at this issue now. |
|
/assign @yanjunxiang-google |
…NS resolver in API definition. This configuration is to support DNS resolution as a first class Envoy extension. This API change is the first step for that task. This configuration is to replace above dns_resolution_config. By default envoy supports c-ares DNS or apple DNS resolvers. This extension can be used to configure other DNS resolver types. This configuration is optional. In case it is missing, the default behavior is in place, which means Envoy will either use c-ares DNS library or apple DNS library based on the compiling flag. When this configuration is in place, Envoy will use the configured DNS resolver carried in the extension typed_config field. In case both typed_dns_resolver_config and dns_resolution_config are configured, typed_dns_resolver_config take precedence. Testing: The code change passed bazel test. Release Notes: N/A Issues: envoyproxy#14310 Fix : N/A Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
|
Reopening, since #17272 was just the API changes (@yanjunxiang-google best to put "Part of #xyzabc" instead of "Fixes #xyzabc" when working on a series of patches on an issue). |
… class extension for issue: envoyproxy#14310. Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
We currently have c-ares and Apple iOS DNS resolver support as compile time options. We might also be interested in a site-specific DNS resolver library. I think it's reasonable to make this a standard extension point.
@junr03 since you were last digging into this, any thoughts on whether it would be feasible to accommodate the various DNS resolvers this way?
CC @yanavlasov @antoniovicente @asraa @adisuissa @KBaichoo @akonradi
The text was updated successfully, but these errors were encountered: