RFC1034 3.6, A zero TTL prohibits caching of the data. The CNAME has a
0 TTL and therefore the message cannot be cached.
The DNAME RR is stored in the cache (since it has a TTL greater than
zero). However, unbound will not synthesize from the DNAME unless it is
DNSSEC signed, to avoid spoof trouble.
Basically, unbound will trust the DNAME record only within the context
of the query for which the DNAME was asked. But since the CNAME had TTL
0, this context is not stored. If the CNAME had TTL equal to the TTL of
the DNAME, say, then unbound would cache, and return a DNAME and CNAME
message as you expect (for that qname).
When I query repeatedly a name which is covered by a DNAME, the TTL in
the answer makes me thing Unbound does not cache it:
% dig -x 128.232.233.1
...
233.232.128.in-addr.arpa. 86400 IN DNAME 233.232.128.in-addr.arpa.cam.ac.uk.
Note:
1.233.232.128.in-addr.arpa. 0 IN CNAME
1.233.232.128.in-addr.arpa.cam.ac.uk.
% dig -x 128.232.233.1
...
233.232.128.in-addr.arpa. 86400 IN DNAME 233.232.128.in-addr.arpa.cam.ac.uk.
Yes.
While BIND has the expected behaviour:
% dig -x 128.232.233.1
...
233.232.128.in-addr.arpa. 86180 IN DNAME 233.232.128.in-addr.arpa.cam.ac.uk.
% dig -x 128.232.233.1
...
233.232.128.in-addr.arpa. 86168 IN DNAME 233.232.128.in-addr.arpa.cam.ac.uk.
Unbound 1.4.6
I see ARIN and RIPE offer signed reverse delegations, perhaps a good
reason to sign these zones
Another solution is to deploy an authority server that gives TTL to the
synthesized CNAME equal to the TTL of the DNAME.
