fix SERVFAIL in *FORWARD modes with CNAME to sibling zone

It failed on a CNAME to a sibling name that's a zone cut.
Fixed by a minimalistic approach - tweaking the conditions
to always ask each CNAME step separately when forwarding.

NEWS

@@ -23,6 +23,7 @@ Incompatible changes
 --------------------
 - minor changes in module API; see upgrading guide:
   https://knot-resolver.readthedocs.io/en/stable/upgrading.html
+- fix SERVFAIL while processing forwarded CNAME to a sibling zone (#614, !1070)
 
 
 Knot Resolver 5.1.3 (2020-09-08)

lib/layer/iterate.c

@@ -609,15 +609,17 @@ static int unroll_cname(knot_pkt_t *pkt, struct kr_request *req, bool referral,
 		}
 		/* The validator still can't handle multiple zones in one answer,
 		 * so we only follow if a single label is replaced.
-		 * TODO: this still isn't 100%, as the target might have a NS+DS,
-		 * possibly leading to a SERVFAIL for the in-bailiwick name. */
+		 * Forwarding appears to be even more sensitive to this.
+		 * TODO: iteration can probably handle the remaining cases,
+		 * but overall it would be better to have a smarter validator
+		 * (and thus save roundtrips).*/
 		const int pending_labels = knot_dname_labels(pending_cname, NULL);
 		if (pending_labels != cname_labels) {
 			cname = pending_cname;
 			break;
 		}
-		if (knot_dname_matched_labels(pending_cname, cname) !=
-		    (cname_labels - 1)) {
+		if (knot_dname_matched_labels(pending_cname, cname) != cname_labels - 1
+		    || query->flags.FORWARD) {
 			cname = pending_cname;
 			break;
 		}

deckard @ 5516e290

-Subproject commit 6168c4f31eea1193c202cbb14fe7c34002b53765
+Subproject commit 5516e290cbd6a578f3ac907d9244ef20ff280bf8