Operational Notification: Domain with apex CNAME and unsigned delegation fails to resolve

[Cathy Almond]

Hello BIND users,

We have just published an Operational Notification at:

https://kb.isc.org/docs/apex-cname-unsigned-delegation

The text version is included below. This is an issue you should be aware 
of, but it is not a software vulnerability, so there is no associated 
updated version of BIND.

- ISC Support

--------------------------

TITLE: Operational Notification: Domain with apex CNAME and unsigned 
delegation fails to resolve

DOCUMENT VERSION: 1.0

POSTING DATE: 7 October 2026

CANONICAL URL: https://kb.isc.org/docs/apex-cname-unsigned-delegation

PROGRAM IMPACTED: BIND

VERSIONS AFFECTED: 9.20.26 to 9.20.29

DESCRIPTION

   A BIND resolver may fail to resolve records within a child zone when 
all of the following are true:

* The child zone is delegated from a DNSSEC-signed parent zone
* The child zone is itself not DNSSEC-signed
* The child zone contains a CNAME record at the zone apex

   While a CNAME at the zone apex is a violation of DNS standards, 
preventing resolution of other records in the same zone was not intended 
behavior.

SOLUTION

   A fix to the BIND software has been developed.  It is scheduled for 
inclusion in BIND 9.20.30, which is currently planned for public release 
on 21 October 2026.  Note that plans are subject to change.

   A preliminary source code fix is available.  This fix is still 
undergoing integration testing.  Operators considering a source patch 
must weigh the risks against their individual needs.  For more 
information, consult the bug report on the ISC GitLab website (see 
"References", below).

WORKAROUNDS

   Operators encountering a domain name that cannot be resolved due to 
this problem can configure their resolver to skip DNSSEC checking for 
the domain in question.

   In "named.conf", the "validate-except" statement can be used to 
exempt a domain name (and its children) from DNSSEC validation.  The 
statement can appear in the global "options" block, or in a "view" 
block.  In both cases the syntax would appear similar to the below.  An 
"rndc reconfig" or daemon restart will be required for this change to 
take effect.

	validate-except { example.com; };

   Alternatively, a negative trust anchor (NTA) can be added using the 
"rndc nta" command.  NTAs have a built-in expiration timer 
("nta-lifetime", default 1 hour, maximum 1 week).  However, they can be 
added to a running server without a reconfig, and thus are less 
disruptive to active queries.

	rndc nta -lifetime 7d example.com

   Both mechanisms can be used together.  For example, "rndc nta" might 
be done immediately, with a config file change and reconfig scheduled 
for a maintenance window.

DIAGNOSTICS

   When experiencing this problem, BIND may log messages similar to the 
following:

	validating example.com/CNAME: checking existence of DS at 'example.com'
	validating example.com/CNAME: fetch would not advance the alias chain: 
aborting validation
	deadlock found resolving 'example.com/A/IN'

   The "deadlock" message is logged at level INFO in category 
"lame-severs".  The two "validating" messages are logged at DEBUG level 
3 in category "dnssec".

MORE INFORMATION

   CNAME records state that a given owner name (left-hand side) should 
be replaced with the canonical name given on the right-hand side.  At 
the same time, SOA and NS records are required to exist at the zone apex 
with the zone name as owner.  Both conditions cannot be true at once. 
The DNS specifications solve this conflict by prohibiting CNAME records 
at the zone apex.

   The intended behavior in BIND is to recognize CNAME records at the 
zone apex.  Recent changes to harden BIND against unrelated attacks 
accidentally resulted in the invalid CNAME construct instead causing the 
entire zone to fail validation.

REFERENCES

* ISC BIND bug report
     * "Deadlock detection triggered when querying DS for insecure 
delegation to child zone with an apex CNAME"
     * https://gitlab.isc.org/isc-projects/bind9/-/work_items/6435
* ISC blog post
     * "CNAME at the apex of a zone"
     * https://www.isc.org/blogs/cname-at-the-apex-of-a-zone/
* BIND ARM
    * "rndc nta" command
    * 
https://bind9.readthedocs.io/en/v9.20.29/manpages.html#cmdoption-rndc-arg-nta
* BIND ARM
    * "nta-lifetime" statement
    * 
https://bind9.readthedocs.io/en/v9.20.29/reference.html#namedconf-statement-nta-lifetime
* BIND ARM
    * "validate-except" statement
    * 
https://bind9.readthedocs.io/en/v9.20.29/reference.html#namedconf-statement-validate-except
* RFC-9499
     * "DNS Terminology"
     * https://www.rfc-editor.org/rfc/rfc9499.html

DOCUMENT REVISION HISTORY

- 1.0 Initial publication, 7 October 2026

DO YOU STILL HAVE QUESTIONS?

   General questions and discussion can be raised on the bind-users 
mailing list: https://lists.isc.org/mailman/listinfo/bind-users 
Developer contributions can be made on the ISC GitLab issue for the 
problem (see above).

   ISC customers with an active support agreement may open a support ticket.

ISC SECURITY VULNERABILITY DISCLOSURE POLICY

   Details of our current security advisory policy and practice can be 
found in the ISC Software Defect and Security Vulnerability Disclosure 
Policy at: https://kb.isc.org/docs/aa-00861

HOW TO SUBMIT A BUG REPORT TO ISC

   If you have encountered a problem with BIND (or with any other ISC 
software), details on how to submit a report can be found at: 
https://www.isc.org/reportbug/

LEGAL DISCLAIMER

   Internet Systems Consortium (ISC) is providing this notice on an "AS 
IS" basis. No warranty or guarantee of any kind is expressed in this 
notice and none should be implied. ISC expressly excludes and disclaims 
any warranties regarding this notice or materials referred to in this 
notice, including, without limitation, any implied warranty of 
merchantability, fitness for a particular purpose, absence of hidden 
defects, or of non-infringement. Your use or reliance on this notice or 
materials referred to in this notice is at your own risk. ISC may change 
this notice at any time. A stand-alone copy or paraphrase of the text of 
this document that omits the document URL is an uncontrolled copy. 
Uncontrolled copies may lack important information, be out of date, or 
contain factual errors.