What happened:
When using the file or auto plugins inside a catch-all server block, queries for CNAMEs pointing to out-of-zone names return SERVFAIL due to CoreDNS' internal lookup of the CNAME target failing due to CoreDNS not being authoritative for the target.

What you expected to happen:
Such queries should return NOERROR. Returning the rcode from the internal CNAME target resolution to the client is only correct for a recursive server, whereas the file and auto plugins act as authoritative servers and should return NOERROR so that the resolver can obtain the CNAME record and look up the target itself.

How to reproduce it (as minimally and precisely as possible):
Corefile:

. {
    errors
    auto {
        directory /zones/
    }
}

/zones/db.example.com:

$ORIGIN example.com.
@	IN	SOA ns1.example.com. noc.example.com. 1 1 1 1 1

test	IN	CNAME example.org.

dig @127.0.0.1 test.example.com
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30536
...

Anything else we need to know?:
This came up before in #5104 and the workaround reached by @chrisohaver was to avoid using a catch-all server block, however that isn't really compatible with the deployment I have in mind, where the zones auto loads from disk may change over time.

I have two solutions in mind:

1. Tweak the auto and file plugins to explicitly return REFUSED (instead of letting plugin.NextOrFailure return SERVFAIL) when there is no next plugin configured. The code in the file plugin that does the CNAME target lookup already interprets REFUSED correctly so no further change there is needed.
2. Create a new tiny plugin called something like finally that can be configured to unconditionally return the desired error code(REFUSED in this case) as a last resort if no other plugin handles the request. This could also be useful for other catch-all setups that don't use the auto or file plugins.

I'm happy to implement either of these solutions as a PR, just looking for some guidance from the team as to what would be preferred and accepted.

I think I'm leaning towards option 1, as file and auto are by definition authoritative servers, and it is semantically correct for an authoritative server to return REFUSED when queried for zones it's not authoritative for.

Environment:

• the version of CoreDNS: 1.12.1
• Corefile: see above
• logs, if applicable:

  [ERROR] plugin/errors: 2 example.org. A: plugin/auto: no next plugin found
  

• OS (e.g: cat /etc/os-release): official docker container
• Others: