Duplicate additional section records

[EchoStone1101]

What happened:

The response from the file plugin may contain duplicate additional section records.

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

Using the following zone file (e.txt):

e.              500 IN SOA      mname.com. rname.com. 3 604800 86400 2419200 604800
e.              500 IN NS       f.
f.e.            500 IN MX       10 a.e.
f.e.            500 IN MX       20 a.e.
a.e.            500 IN A        1.1.1.1

and this Corefile:

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

Response for querying <f.e., MX> :

root@e10adfbeed3f:/v# dig @127.0.0.1 -p 1053 f.e. MX

; <<>> DiG 9.18.24-1-Debian <<>> @127.0.0.1 -p 1053 f.e. MX
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3930
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9d5beafaff632ac3 (echoed)
;; QUESTION SECTION:
;f.e.                           IN      MX

;; ANSWER SECTION:
f.e.                    500     IN      MX      10 a.e.
f.e.                    500     IN      MX      20 a.e.

;; AUTHORITY SECTION:
e.                      500     IN      NS      f.

;; ADDITIONAL SECTION:
a.e.                    500     IN      A       1.1.1.1
a.e.                    500     IN      A       1.1.1.1

;; Query time: 7 msec
;; SERVER: 127.0.0.1#1053(127.0.0.1) (UDP)
;; WHEN: Sun Apr 21 07:30:57 UTC 2024
;; MSG SIZE  rcvd: 142

What you expected to happen:

There is only one A record in the zone for the name a.e., and it should not be duplicated in the additional section.

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:

What's happening here is that querying for MX triggers the additional section processing, and both answers (the two MX records) have the same host, leading to the address record being added twice.

This is a relatively minor issue. Nevertheless, I'm filing this because Bind9 does deduplicate message sections. It can be argued that if too much of this duplication occurs, then there might be actually relevant additional records dropped because of truncation.

The two MX records having only the preferences different might seem strange; however there can be other record types that also trigger additional section processing (SRV, for example; it would make sense to have two records with the same target but different ports).