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

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:

BIND

• 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. 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.