coredns/fallback

The fallback plugin allows sending queries to alternate upstreams based on rcodes returned from the plugin chain.

fallback's Issues

Move Lookup logic from current Proxy to Forward

Right now, fixes for fallback most likely induce fix in proxy (in fact in the Lookup part)
It would be better to improve plugin Forward instead of Proxy.

However, that needs some adaptation in plugin Forward to implement reusable Lookup and ensure the Lookup can be defined from Setup parameters.

Hope the fallback function can be nested  

I want to implement strict DNS query in the specified order, but a prompt similar to NXDOMAIN or SERVFAIL can automatically query the next DNS server. Fallback can just achieve this function, but I need more than two DNS servers to check strictly in order. I tried to open different ports to nest, but I found that it failed. When something like NXDOMAIN or SERVFAIL appeared, he would only go directly to the last DNS server. I don't know if this is a bug or a fallback can only be used once. In any case, I hope fallback can add nesting functionality, thank you very much.

does no build

get this error on windows

coredns>go build
go: finding github.com/coredns/fallback latest
go: finding github.com/coredns/coredns/plugin/proxy latest
go: finding github.com/coredns/coredns/plugin latest
go: github.com/mholt/[email protected]: parsing go.mod: unexpected module path "github.com/caddyserver/caddy"
go: error loading module requirements

what

Feature: Ability to define the Query to send through fallback as the original query

Description

As of now, FALLBACK is re-issuing the DNS Query that failed in the plugin chain (based on the returned Code).
BUT, it is re-issuing the DNS Query that is transformed (using REWRITE) to fit requirement of the regular remote upstream.

One of the goals of the Fallback is to give-up to our specific upsream, and send to the regular resolvers. That means if possible without the encoded data with REWRITE.

Proposition of change

To keep FALLBACK generic enough and compatible with existing version, I would propose to add an option "ORIGINAL" in the stanza to specify that request for the DNS query.

Syntax would be, adding an option parameter "original" :

{
    fallback [original] RCODE PROXY_PARAMS
}

NOTE: as we reuse the configuration of PROXY_PARAMS, it is more easy/convenient to add the new parameter in front of PROXY_PARAM.
We need to make it optional to keep compatibility.

. {
    REWRITE edns0 local 0xffee <mycode>
    proxy . <mySpecificRemoteResolver>
    fallback NXDOMAIN . <anotherSpecificRemoteresolver>
    fallback original REFUSED . 192.168.100.1:53
    log
}

code returned by fallback.ServeDNS is not correct one

When fallback rules are not kicked-in, the cored return by ServeDNS is not the right one:
=> it should be the rcode returned by the following handler, not a combination of that rcode and the rcode returned by the Response.

Was discovered while trying to log the DNS messages and found that FALLBACK plugin had an influence on these logs although none of the rules of FALLBACK was hit.

• a fix is in progress