Bugzilla – Bug 677
CNAME corresponding to a DNAME is checked incorrectly
Last modified: 2015-06-26 09:32:33 CEST
The function scrub_normalize in iterator/iter_scrub.c does not check the synthesized CNAME that might follow a DNAME correctly.
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))
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).
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.
Fixed it; in svn trunk. Fix was in the cname chain consistency check. Thanks for the report!