Let's assume that we have the following record in zone zone.net, authoritatitve name server responses correctly in such way

dig @ns1.zone.net c-c9qah5rl9qm58427p78r.rw.db.zone.net. -t A
c-c9qah5rl9qm58427p78r.rw.db.zone.net. 10 IN CNAME rc1a-ty9dwtfubb3dq8ti.db.zone.net.
rc1a-ty9dwtfubb3dq8ti.db.zone.net. 300 IN A 178.154.226.240

Also we have recursive unbound that could return (from cache) for A question either eventually only CNAME or CNAME and A resolved (as expected). Steps to reproduce: against recursive unbound ::1 do in cycle:

dig @::1 c-c9qah5rl9qm58427p78r.rw.db.zone.net. -t CNAME && dig @::1 c-c9qah5rl9qm58427p78r.rw.db.zone.net. -t A

response for -t CNAME (it always OK)
; QUESTION SECTION:
c-c9qah5rl9qm58427p78r.rw.db.zone.net. IN CNAME
;; ANSWER SECTION:
c-c9qah5rl9qm58427p78r.rw.db.zone.net. 5 IN CNAME rc1a-ty9dwtfubb3dq8ti.db.zone.net.

response for -t A (it sometimes ok, but not always) here could be two possible answers:

1. incorrect answer (please note that we request A type, expecting that unbound will resolve CNAME and than A in chain to return A record also), it could return this kind of replies eventually, I suppose it correlates with cache ttl time
;; QUESTION SECTION:
;c-c9qah5rl9qm58427p78r.rw.db.zone.net. IN A
;; ANSWER SECTION:
c-c9qah5rl9qm58427p78r.rw.db.zone.net. 5 IN CNAME rc1a-ty9dwtfubb3dq8ti.db.zone.net.
;; AUTHORITY SECTION:
zone.net. 81820 IN NS ns1.zone.net.
zone.net. 81820 IN NS ns1.zone.net.

2. correct answer
;; QUESTION SECTION:
;c-c9qah5rl9qm58427p78r.rw.db.zone.net. IN A
;; ANSWER SECTION:
c-c9qah5rl9qm58427p78r.rw.db.zone.net. 12 IN CNAME rc1a-ty9dwtfubb3dq8ti.db.zone.net.
rc1a-ty9dwtfubb3dq8ti.db.zone.net. 178 IN A 178.154.226.240

It seems that CNAME request for record c-c9qah5rl9qm58427p78r.rw.db.zone.net. somehow invalidates cache with incorrect answer and unbound tries to use it for question with A also.

Unbound versions checked and affected 1.10.1, 1.13.0.