What happened:

A CoreDNS instance (v1.12.1) configured with both the cache plugin and the rewrite cname directive exhibits incorrect behavior when resolving a CNAME whose upstream response is truncated.

The setup involves:

1. A downstream CoreDNS instance acting as a recursive resolver/forwarder.
2. This instance uses rewrite cname suffix . . to enable internal CNAME chasing.
3. It also uses the cache plugin.
4. When a query results in a CNAME response internally (e.g., from template or another plugin), the rewrite directive triggers a recursive lookup for the CNAME target.
5. This recursive lookup is directed to an upstream server (via forward).
6. The upstream server returns a large UDP response (with TC bit set) for the CNAME target query, as the full record set exceeds UDP size limits.

The downstream CoreDNS instance receives the truncated UDP response from upstream. It then synthesizes a response to the original client query. This response includes the CNAME and only the partial record set from the truncated upstream response. The downstream instance correctly sets the TC bit in this response to the client because the combined CNAME + partial data is still large.

However, when the client sees the TC bit and retries the original query via TCP to the downstream instance, it still receives the truncated/partial record set. The downstream instance serves the incomplete result from its cache instead of fetching the complete result from the upstream via TCP.

What you expected to happen:

When the client retries its original query via TCP, the CoreDNS should return the CNAME record plus the full, non-truncated record set retrieved from the upstream.

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

A minimal, reproducible test case is available at:
https://github.com/yannickepstein/coredns-rewrite-cname-issue

Steps:

1. Clone the repository.
2. Ensure coredns (v1.12.1 recommended for testing this version) and make are installed.
3. Run make start to launch the two CoreDNS instances acting as downstream (entrypoint for queries) and upstream DNS servers.
4. Run make test to execute a DNS lookup showing the faulty behaviour.

Observe the output of make test. The dig command will show a warning about retrying via TCP, but the final ANSWER section will contain the CNAME record plus only a partial list of the expected 100 SRV records (typically stopping around target072).

Environment:

• the version of CoreDNS: v1.12.1 (Issue also exists in other versions)
• Corefile: Corefile
• OS (e.g: cat /etc/os-release): macOS 15.4.1, Build: 24E263 - Issue likely OS-independent