Missing additional info after DNAME substitution

[EchoStone1101]

What happened:

When a record that triggers additional section processing is found after doing DNAME substitution, the additional section is not populated by the file plugin.

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

Using the following zone file (j.txt):

j.		    500 IN SOA	    mname.com. rname.com. 3 604800 86400 2419200 604800
j.		    500 IN NS	    a.
j.		    500 IN AAAA	    5:2:2:5:5:3:7:5
h.j.		500 IN SRV	    10 50 7890 j.
g.j.		500 IN DNAME	j.

and this Corefile:

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

Response for querying <h.g.j., SRV> (output beautified):

root@e10adfbeed3f:/v# dig @127.0.0.1 -p 1053 h.g.j. SRV

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 834
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;h.g.j.                         IN      SRV

;; ANSWER SECTION:
g.j.                    500     IN      DNAME   j.
h.g.j.                  500     IN      CNAME   h.j.
h.j.                    500     IN      SRV     10 50 7890 j.

;; AUTHORITY SECTION:
j.                      500     IN      NS      a.

What you expected to happen:

The ADDITIONAL section should include the j. AAAA record because it is relevant to h.j. SRV j..

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:

The same problem occurs if DNAME is changed to CNAME (here a h.j. CNAME g.j. would trigger the same issue), so the problem probably is related to externalLookup. The ADDITIONAL section is populated if h.j. SRV is queried directly.

Also, bind9 does populate the ADDITIONAL section with the same setup, no matter what.