[CVE-2021-25215] Properly answer queries for DNAME records that require the DNAME to be processed to resolve itself

See merge request isc-private/bind9!281

https://kb.isc.org/v1/docs/cve-2021-25215

Change-Id: Ibd8d0ee0e637eda7d4540c567dca6a7569f04058

2 files changed, 14 insertions, 4 deletions

diff --git a/CHANGES b/CHANGES
index 955fe4f2..953e5335 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,7 @@
+5616.	[security]	named crashed when a DNAME record placed in the ANSWER
+			section during DNAME chasing turned out to be the final
+			answer to a client query. (CVE-2021-25215) [GL #2540]
+
 5562.	[security]	Fix off-by-one bug in ISC SPNEGO implementation.
 			(CVE-2020-8625) [GL #2354]
 
diff --git a/lib/ns/query.c b/lib/ns/query.c
index 0d29a80a..7203070f 100644
--- a/lib/ns/query.c
+++ b/lib/ns/query.c
@@ -7306,10 +7306,16 @@ query_respond(query_ctx_t *qctx) {
 	query_addnoqnameproof(qctx);
 
 	/*
-	 * We shouldn't ever fail to add 'rdataset'
-	 * because it's already in the answer.
-	 */
-	INSIST(qctx->rdataset == NULL);
+	 * 'qctx->rdataset' will only be non-NULL here if the ANSWER section of
+	 * the message to be sent to the client already contains an RRset with
+	 * the same owner name and the same type as 'qctx->rdataset'.  This
+	 * should never happen, with one exception: when chasing DNAME records,
+	 * one of the DNAME records placed in the ANSWER section may turn out
+	 * to be the final answer to the client's query, but we have no way of
+	 * knowing that until now.  In such a case, 'qctx->rdataset' will be
+	 * freed later, so we do not need to free it here.
+	 */
+	INSIST(qctx->rdataset == NULL || qctx->qtype == dns_rdatatype_dname);
 
 	query_addauth(qctx);