deprecate plugin/proxy

[miekg]

I want to deprecate proxy in favor of forward.

Why:
We have had a long discussion on Slack about an outage that is attributed to the proxy code (spec. the healthchecking (HC)). This took 2 engineers quite a while to reason about the current code; it is complex. I think it is gotten too complex.

• The HC pings an HTTP endpoint, which no relation the upstream's ability to respond to DNS
• The policy frameworks adds flexibility, but brings a lot of code with it. Most people should be content with just randomizing an upstream

forward uses inband HC (by default), and just traverses a list, so no Select() what proxy currently does. And the code in forward is simpler. It also caches udp and tcp sockets, so it is faster.

Why not:

• proxy is more battle hardened than forward
• forward does not support grpc (can be added?) not https_google

Proposal:

• Add forward, convert all in-plugin callers to forward.Lookup instead of proxy.Lookup
• Deprecate proxy, but leave it for grpc and https_google (in case of the later HC is also broken, oh the irony)

[fturib]

For Infoblox use case, I need a proxy/forward with:

• grpc (and dns)
• policy (I plan to add another one named "always_first" that always tries by the same order)
• aggregate health of the proxy/forward to global coredns health status (I plan to implement the Healther interface on proxy). NOTE: I do not need the health check on upstream servers

[miekg]

yeah, forward must/should support grpc. and health.Healther is sensible for all plugins.

Not 100% sold on the need to specify client side policy.

[grobie]

👍 from our side, but we don't need grpc, policies other than random or HTTP checks. My opinion on "battle hardened" differs as well ;-)

[miekg]

"seen more production use" might be a better description.

[miekg]

Also: if you query proxy and the upstream of proxy timeout, this is attributed to the proxy, forward avoids this mistake.

[summerwind]

We have been used proxy plugin to allow to use with external service via gRPC in production. But It seems that proxy plugin is already deptecated (#2651).

This causes the block of update of CoreDNS in our environment. Are there specific plans to support gRPC in the forward plugin?

[miekg]

Is trivial to add external plugins to coredns, so I don't see any problems here. (Do need to double check if coredns/proxy compiles). As to gRPC proxy functionality, I think this should be done as a new plugin.

…

On Tue, 5 Mar 2019, 00:55 Moto Ishizawa, ***@***.***> wrote: We have been used proxy plugin to allow to use with external service via gRPC in production. But It seems that proxy plugin is already deptecated ( #2651 <#2651>). This causes the block of update of CoreDNS in our environment. Are there specific plans to support gRPC in the forward plugin? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1443 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAVkW5bM1twzmabUm32aSlKKDm-aaTDeks5vTcCAgaJpZM4Ruk1a> .

[stefanmb]

@miekg It's worth pointing out that forward does not support dnstap logging of forwarded queries/responses, so deprecating proxy effectively cripples the usefulness of the dnstap plugin if we don't add the functionality to forward.

[miekg]

[ Quoting <notifications@github.com> in "Re: [coredns/coredns] deprecate plu..." ]

@miekg It's worth pointing out that `forward` does not support `dnstap` logging of forwarded queries/responses, so deprecating `proxy` effectively cripples the usefulness of the `dnstap` plugin if we don't add the functionality to `forward`.

yep, and there is an issue open for that. As previous said, including proxy is easy. It's removed because healthchecking is not good, it's not fast enough and too complex

[stefanmb]

Found it #1448 - thank you!

[miekg]

closing here, as its' gone. Cleaning up the last bit and then really make it external.