Wrong RCODE for out-of-zone CNAME target

[EchoStone1101]

What happened:

When the file plugin chases a CNAME chain that points out-of-zone (and thus non-existent), the RCODE is NOERROR.

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

Using the following zone file (a.txt):

a.				      500 IN SOA	b.c.d. e.a.d. 3 604800 86400 2419200 604800
a.				      500 IN NS		b.c.d.
b.a.			      500 IN CNAME	c.

and this Corefile:

a.:1053 {
    header {
        response set ra
    }
    file a.txt
}

Response for querying <b.a., A> :

root@e10adfbeed3f:/v# dig @127.0.0.1 -p 1053 b.a. A

; <<>> DiG 9.18.24-1-Debian <<>> @127.0.0.1 -p 1053 b.a. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22063
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 5bc0432ca10e47b3 (echoed)
;; QUESTION SECTION:
;b.a.                           IN      A

;; ANSWER SECTION:
b.a.                    500     IN      CNAME   c.

;; AUTHORITY SECTION:
a.                      500     IN      NS      b.c.d.

;; Query time: 8 msec
;; SERVER: 127.0.0.1#1053(127.0.0.1) (UDP)
;; WHEN: Sun Apr 21 07:14:35 UTC 2024
;; MSG SIZE  rcvd: 82

What you expected to happen:

The RCODE should be NXDOMAIN(as the CNAME target c. is non-existent) or REFUSED (as the zone for c. doesn't exist). At least it should not be NOERROR.

Anything else we need to know?:

Environment:

• the version of CoreDNS: CoreDNS-1.11.1, linux/arm64, go1.21.5, 45923b6e
• Corefile: given above.
• OS: this uses the docker environment from "Compilation with Docker".
• Others:

Notably, Bind9 replies with NXDOMAIN under the same setup.

Bind9 will do the same as CoreDNS (NOERROR) if +norec is provided, but here the recursion isn't disabled in the Corefile.

This looks closely related to #4288. In fact, the fix for it pointed out that this is caused by the file plugin using an alternate response code type file.Result, and added conversion code. However, the mapping still isn't exhaustive. Here I believe the actual rcode, dns.RcodeRefused, is not mapped correctly.