coredns/fallback

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

fallback

Deprecated

This plugin is deprecated in favor of https://github.com/coredns/alternate, which performs the same function.

Name

fallback - a plugin that sends queries to an alternate set of upstreams if the plugin chain returns specific error messages.

Description

The fallback plugin allows an alternate set of upstreams be specified which will be used if the plugin chain returns specific error messages. The fallback plugin utilizes the proxy plugin (https://coredns.io/plugins/proxy) to query the specified upstreams.

As the name suggests, the purpose of the fallback is to allow a fallback when, for example, the desired upstreams became unavailable.

Syntax

{
    fallback [original] RCODE PROXY_PARAMS
}

• original is optional flag. If it is set then fallback uses original request instead of potentially changed by other plugins
• RCODE is the string representation of the error response code. The complete list of valid rcode strings are defined as RcodeToString in https://github.com/miekg/dns/blob/master/msg.go, examples of which are SERVFAIL, NXDOMAIN and REFUSED.
• PROXY_PARAMS accepts the same parameters as the proxy plugin https://coredns.io/plugins/proxy.

Examples

Fallback to local DNS server

The following specifies that all requests are proxied to 8.8.8.8. If the response is NXDOMAIN, fallback will proxy the request to 192.168.1.1:53, and reply to client accordingly.

. {
	proxy . 8.8.8.8
	fallback NXDOMAIN . 192.168.1.1:53
	log
}

Fallback with original request used

The following specify that original query will be proxied to 192.168.1.1:53 if 8.8.8.8 response is NXDOMAIN. original means no changes from next plugins on request. With no original flag fallback will proxy request with EDNS0 option (set by rewrite).

. {
	proxy . 8.8.8.8
    rewrite edns0 local set 0xffee 0x61626364
	fallback original NXDOMAIN . 192.168.1.1:53
	log
}

Multiple fallbacks

Multiple fallbacks can be specified, as long as they serve unique error responses.

. {
    proxy . 8.8.8.8
    fallback NXDOMAIN . 192.168.1.1:53
    fallback REFUSED . 192.168.100.1:53
    fallback original SERVFAIL . 192.168.100.1:53
    log
}

Additional proxy parameters

You can specify additional proxy parameters for each of the fallback upstreams.

. {
    proxy . 8.8.8.8
    fallback NXDOMAIN . 192.168.1.1:53 192.168.1.2:53 {
        protocol dns force_tcp
    }
    log
}

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.

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

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.

what

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