Bug 677 - CNAME corresponding to a DNAME is checked incorrectly
CNAME corresponding to a DNAME is checked incorrectly
Status: RESOLVED FIXED
Product: unbound
Classification: Unclassified
Component: server
1.5.3
x86_64 Linux
: P5 minor
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-06-12 02:21 CEST by Valentin Dietrich
Modified: 2015-06-26 09:32 CEST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Valentin Dietrich 2015-06-12 02:21:32 CEST
The function scrub_normalize in iterator/iter_scrub.c does not check the synthesized CNAME that might follow a DNAME correctly.

Line 375:
if(!parse_get_cname_target(rrset, &t, &tlen))

This is probably supposed to get the CNAME target, to then compare it to the alias which was constructed before using the DNAME.
However, it does not, because the rrset reference is not yet changed at this point, so &t will contain the DNAME target instead. 
Therefore, a correctly synthesized CNAME will always be considered mismatching and then synthesized by the function itself, but with TTL 0.
This means that a received query response containing a DNAME will never be retrievable as a whole from the message cache, because of the zero TTL CNAME in it. Also, it probably contains 2 equal CNAMES (except for the TTL).

The correct call would be
if(!parse_get_cname_target(nx, &t, &tlen))
Comment 1 Wouter Wijngaards 2015-06-22 11:25:21 CEST
Hi Valentin,

Yes that code fix is good, thank you very much for spotting it.

I have applied the fix to the code repository (for the next release).

Best regards,
   Wouter
Comment 2 Valentin Dietrich 2015-06-25 16:19:10 CEST
I've noticed something else after applying the fix myself:

When such a DNAME response is cached in the message cache, the RRSETs get sorted and the DNAME ends up as the last record. While this seems legit, because the DNAME name does indeed not match the original query name, the DNAME does not get restored when looking up the message from cache. Only the CNAME (now with proper TTL) and the A record will be returned in the answer.

I'm not sure where exactly this could be fixed, but probably somewhere in the lookup function.
Comment 3 Wouter Wijngaards 2015-06-26 09:32:33 CEST
Hi Valentin,

Fixed it; in svn trunk.  Fix was in the cname chain consistency check.  Thanks for the report!

Best regards,
   Wouter