Bottom line: CISA published Update A to ICSA-26-204-01 on August 11, revising affected-product and mitigation information for three vulnerabilities in Johnson Controls C-CURE 9000 and victor products. The most consequential finding, CVE-2026-21655, can allow an unauthenticated attacker with adjacent-network access to execute code on security-management servers and connected clients, including physical-security operator workstations. CISA rates the advisory up to CVSS 9.6, Critical. As of August 12, CISA reports no known public exploitation specifically targeting these vulnerabilities.
\r\n\r\nCISA ICSA-26-204-01 Update A covers CVE-2026-21655, CVE-2026-21653, and CVE-2026-34496. Update A revises the affected-product and mitigation details from the advisory first published July 23.
\r\nJohnson Controls describes CVE-2026-21655 as deserialization of untrusted data. Under certain circumstances, an unauthenticated attacker on an adjacent network could execute arbitrary code on C-CURE 9000, victor Application Server, victor, and connected clients. The vendor says the attack could affect physical-security controls. Its product advisory also says the C-CURE IQ client, victor Web Services integrations, and communications between iSTAR controllers, VideoEdge NVRs, and victor Application Server are not affected by this CVE.
\r\nCVE-2026-21653 is a server-side request forgery issue in victor Web. It can cause the application to make requests to services on the host or local network, creating possible information-disclosure or lateral-movement risk. CVE-2026-34496 has a different prerequisite: a low-privilege victor Web user may reach unauthorized pages such as Users and Logs and view sensitive account, system, or audit information.
\r\n\r\n| Finding | Affected product | Vendor-directed update |
|---|---|---|
| CVE-2026-21655 | C-CURE 9000 3.10.1 and earlier | Upgrade to 3.20 or later |
| CVE-2026-21655 | victor Application Server 4.10 and earlier | Upgrade to 4.20 or later |
| CVE-2026-21655 | victor 7.0 and earlier | Upgrade to 8.0 or later |
| CVE-2026-21653 | victor Web versions before 7.0 | Upgrade to 7.0 or later |
| CVE-2026-34496 | victor Web 7.1 and earlier | Use the latest available fixed release; confirm the exact build with Johnson Controls or the authorized integrator |
The Johnson Controls bulletin for CVE-2026-34496 directs customers to the latest available version but does not name a minimum fixed build. That distinction should be confirmed before closing the change record.
\r\n\r\nThe RCE path is not described as arbitrary internet-wide exploitation. However, “not internet-facing” is not a complete exposure test. A vulnerable service may still be reachable from a compromised workstation, shared server segment, vendor-access path, or another connected security network. Actual operational consequences depend on privileges, integrations, segmentation, and configuration.
\r\nNeither CISA nor Johnson Controls says these flaws automatically unlock doors, disable cameras, or create a specific physical outcome. The verified concern is code execution and access to security-system information, with potential impact to physical-security controls.
\r\n\r\nFor CVE-2026-21655, Johnson Controls recommends isolating application servers on a dedicated segment and allowing port 8999 only from authorized systems. It also recommends blocking unnecessary inbound port 8999 traffic, detecting known .NET deserialization patterns, using application allowlisting and least privilege, and monitoring anomalous process creation by SoftwareHouse.CrossFire.Server.exe. If the ClientConnectionManager_NF.SynchronousServerNotification callback is unnecessary, disable or restrict it.
For CVE-2026-21653, the vendor recommends trusted-management-only access to victor Web, internal segmentation, unusual outbound HTTP monitoring, and egress filtering. For CVE-2026-34496, it recommends strict role-based access control, server-side restrictions on administrative pages, auditing, management-network segmentation, and a web application firewall. These controls reduce exposure while an upgrade is pending; they do not replace fixed releases.
\r\n\r\nThe following steps are DSE recommendations based on the official advisories.
\r\nSoftwareHouse.CrossFire.Server.exe, unusual port 8999 traffic, unexpected outbound HTTP from victor Web, and low-privilege access to Users or Logs. Preserve relevant records and escalate unexplained findings; none alone proves exploitation.Source review completed August 12, 2026. Recheck the official advisories before changing production systems.
\r\n", "content_text": "Bottom line: CISA published Update A to ICSA-26-204-01 on August 11, revising affected-product and mitigation information for three vulnerabilities in Johnson Controls C-CURE 9000 and victor products. The most consequential finding, CVE-2026-21655, can allow an unauthenticated attacker with adjacent-network access to execute code on security-management servers and connected clients, including physical-security operator workstations. CISA rates the advisory up to CVSS 9.6, Critical. As of August 12, CISA reports no known public exploitation specifically targeting these vulnerabilities.\r\n\r\nSource fact: what CISA Update A covers\r\nCISA ICSA-26-204-01 Update A covers CVE-2026-21655, CVE-2026-21653, and CVE-2026-34496. Update A revises the affected-product and mitigation details from the advisory first published July 23.\r\nJohnson Controls describes CVE-2026-21655 as deserialization of untrusted data. Under certain circumstances, an unauthenticated attacker on an adjacent network could execute arbitrary code on C-CURE 9000, victor Application Server, victor, and connected clients. The vendor says the attack could affect physical-security controls. Its product advisory also says the C-CURE IQ client, victor Web Services integrations, and communications between iSTAR controllers, VideoEdge NVRs, and victor Application Server are not affected by this CVE.\r\nCVE-2026-21653 is a server-side request forgery issue in victor Web. It can cause the application to make requests to services on the host or local network, creating possible information-disclosure or lateral-movement risk. CVE-2026-34496 has a different prerequisite: a low-privilege victor Web user may reach unauthorized pages such as Users and Logs and view sensitive account, system, or audit information.\r\n\r\nAffected versions and vendor-directed updates\r\n\r\nFindingAffected productVendor-directed update\r\n\r\nCVE-2026-21655C-CURE 9000 3.10.1 and earlierUpgrade to 3.20 or later\r\nCVE-2026-21655victor Application Server 4.10 and earlierUpgrade to 4.20 or later\r\nCVE-2026-21655victor 7.0 and earlierUpgrade to 8.0 or later\r\nCVE-2026-21653victor Web versions before 7.0Upgrade to 7.0 or later\r\nCVE-2026-34496victor Web 7.1 and earlierUse the latest available fixed release; confirm the exact build with Johnson Controls or the authorized integrator\r\n\r\n\r\nThe Johnson Controls bulletin for CVE-2026-34496 directs customers to the latest available version but does not name a minimum fixed build. That distinction should be confirmed before closing the change record.\r\n\r\nWhy “adjacent network” still deserves urgency\r\nThe RCE path is not described as arbitrary internet-wide exploitation. However, “not internet-facing” is not a complete exposure test. A vulnerable service may still be reachable from a compromised workstation, shared server segment, vendor-access path, or another connected security network. Actual operational consequences depend on privileges, integrations, segmentation, and configuration.\r\nNeither CISA nor Johnson Controls says these flaws automatically unlock doors, disable cameras, or create a specific physical outcome. The verified concern is code execution and access to security-system information, with potential impact to physical-security controls.\r\n\r\nVendor-provided temporary mitigations\r\nFor CVE-2026-21655, Johnson Controls recommends isolating application servers on a dedicated segment and allowing port 8999 only from authorized systems. It also recommends blocking unnecessary inbound port 8999 traffic, detecting known .NET deserialization patterns, using application allowlisting and least privilege, and monitoring anomalous process creation by SoftwareHouse.CrossFire.Server.exe. If the ClientConnectionManager_NF.SynchronousServerNotification callback is unnecessary, disable or restrict it.\r\nFor CVE-2026-21653, the vendor recommends trusted-management-only access to victor Web, internal segmentation, unusual outbound HTTP monitoring, and egress filtering. For CVE-2026-34496, it recommends strict role-based access control, server-side restrictions on administrative pages, auditing, management-network segmentation, and a web application firewall. These controls reduce exposure while an upgrade is pending; they do not replace fixed releases.\r\n\r\nDSE recommendation: prioritized response\r\nThe following steps are DSE recommendations based on the official advisories.\r\n\r\nConfirm exposure now. Inventory every production, disaster-recovery, and test deployment. Record exact product versions, application and web servers, operator clients, network paths, owners, integrations, and remote-support routes.\r\nContain pending upgrades. Restrict port 8999, remove unnecessary cross-segment access, limit victor Web to trusted management paths, and constrain outbound web traffic. Give every temporary exception an owner and expiration date.\r\nExpedite vendor-supported updates. Prioritize the RCE path. For CVE-2026-34496, verify the precise fixed victor Web build with the vendor or integrator.\r\nProtect operations during the change. Follow supported backup and rollback procedures. After updating, test operator sign-in, access-control commands, alarm receipt and acknowledgment, video recording and retrieval, event-to-video associations, reports, and critical integrations.\r\nReview available evidence. Look for unexplained child processes from SoftwareHouse.CrossFire.Server.exe, unusual port 8999 traffic, unexpected outbound HTTP from victor Web, and low-privilege access to Users or Logs. Preserve relevant records and escalate unexplained findings; none alone proves exploitation.\r\nDocument closure. Record fixed versions, containment changes, functional-test results, residual exceptions, and the date the official advisories were rechecked.\r\n\r\n\r\nOfficial reference\r\n\r\nCISA ICSA-26-204-01 Update A, updated August 11, 2026\r\nJohnson Controls JCI-PSA-2026-13 v2, updated August 6, 2026\r\nJohnson Controls JCI-PSA-2026-07\r\nJohnson Controls JCI-PSA-2026-16\r\nJohnson Controls Product Security Advisory register\r\n\r\nSource review completed August 12, 2026. Recheck the official advisories before changing production systems.", "content_markdown": "Bottom line: CISA published Update A to ICSA-26-204-01 on August 11, revising affected-product and mitigation information for three vulnerabilities in Johnson Controls C-CURE 9000 and victor products. The most consequential finding, CVE-2026-21655, can allow an unauthenticated attacker with adjacent-network access to execute code on security-management servers and connected clients, including physical-security operator workstations. CISA rates the advisory up to CVSS 9.6, Critical. As of August 12, CISA reports no known public exploitation specifically targeting these vulnerabilities.\n\n## Source fact: what CISA Update A covers\n\n[CISA ICSA-26-204-01 Update A](https://www.cisa.gov/news-events/ics-advisories/icsa-26-204-01) covers CVE-2026-21655, CVE-2026-21653, and CVE-2026-34496. Update A revises the affected-product and mitigation details from the advisory first published July 23.\n\nJohnson Controls describes CVE-2026-21655 as deserialization of untrusted data. Under certain circumstances, an unauthenticated attacker on an adjacent network could execute arbitrary code on C-CURE 9000, victor Application Server, victor, and connected clients. The vendor says the attack could affect physical-security controls. Its [product advisory](https://tyco.widen.net/s/9xktps8hl6/jci-psa-2026-13-v2) also says the C-CURE IQ client, victor Web Services integrations, and communications between iSTAR controllers, VideoEdge NVRs, and victor Application Server are not affected by this CVE.\n\nCVE-2026-21653 is a server-side request forgery issue in victor Web. It can cause the application to make requests to services on the host or local network, creating possible information-disclosure or lateral-movement risk. CVE-2026-34496 has a different prerequisite: a low-privilege victor Web user may reach unauthorized pages such as Users and Logs and view sensitive account, system, or audit information.\n\n## Affected versions and vendor-directed updates\n\nFindingAffected productVendor-directed update\n\nCVE-2026-21655C-CURE 9000 3.10.1 and earlierUpgrade to 3.20 or later\n\nCVE-2026-21655victor Application Server 4.10 and earlierUpgrade to 4.20 or later\n\nCVE-2026-21655victor 7.0 and earlierUpgrade to 8.0 or later\n\nCVE-2026-21653victor Web versions before 7.0Upgrade to 7.0 or later\n\nCVE-2026-34496victor Web 7.1 and earlierUse the latest available fixed release; confirm the exact build with Johnson Controls or the authorized integrator\n\nThe Johnson Controls bulletin for CVE-2026-34496 directs customers to the latest available version but does not name a minimum fixed build. That distinction should be confirmed before closing the change record.\n\n## Why “adjacent network” still deserves urgency\n\nThe RCE path is not described as arbitrary internet-wide exploitation. However, “not internet-facing” is not a complete exposure test. A vulnerable service may still be reachable from a compromised workstation, shared server segment, vendor-access path, or another connected security network. Actual operational consequences depend on privileges, integrations, segmentation, and configuration.\n\nNeither CISA nor Johnson Controls says these flaws automatically unlock doors, disable cameras, or create a specific physical outcome. The verified concern is code execution and access to security-system information, with potential impact to physical-security controls.\n\n## Vendor-provided temporary mitigations\n\nFor CVE-2026-21655, Johnson Controls recommends isolating application servers on a dedicated segment and allowing port 8999 only from authorized systems. It also recommends blocking unnecessary inbound port 8999 traffic, detecting known .NET deserialization patterns, using application allowlisting and least privilege, and monitoring anomalous process creation by SoftwareHouse.CrossFire.Server.exe. If the ClientConnectionManager_NF.SynchronousServerNotification callback is unnecessary, disable or restrict it.\n\nFor CVE-2026-21653, the vendor recommends trusted-management-only access to victor Web, internal segmentation, unusual outbound HTTP monitoring, and egress filtering. For CVE-2026-34496, it recommends strict role-based access control, server-side restrictions on administrative pages, auditing, management-network segmentation, and a web application firewall. These controls reduce exposure while an upgrade is pending; they do not replace fixed releases.\n\n## DSE recommendation: prioritized response\n\nThe following steps are DSE recommendations based on the official advisories.\n\n- Confirm exposure now. Inventory every production, disaster-recovery, and test deployment. Record exact product versions, application and web servers, operator clients, network paths, owners, integrations, and remote-support routes.\n\n- Contain pending upgrades. Restrict port 8999, remove unnecessary cross-segment access, limit victor Web to trusted management paths, and constrain outbound web traffic. Give every temporary exception an owner and expiration date.\n\n- Expedite vendor-supported updates. Prioritize the RCE path. For CVE-2026-34496, verify the precise fixed victor Web build with the vendor or integrator.\n\n- Protect operations during the change. Follow supported backup and rollback procedures. After updating, test operator sign-in, access-control commands, alarm receipt and acknowledgment, video recording and retrieval, event-to-video associations, reports, and critical integrations.\n\n- Review available evidence. Look for unexplained child processes from SoftwareHouse.CrossFire.Server.exe, unusual port 8999 traffic, unexpected outbound HTTP from victor Web, and low-privilege access to Users or Logs. Preserve relevant records and escalate unexplained findings; none alone proves exploitation.\n\n- Document closure. Record fixed versions, containment changes, functional-test results, residual exceptions, and the date the official advisories were rechecked.\n\n## Official reference\n\n- [CISA ICSA-26-204-01 Update A](https://www.cisa.gov/news-events/ics-advisories/icsa-26-204-01), updated August 11, 2026\n\n- [Johnson Controls JCI-PSA-2026-13 v2](https://tyco.widen.net/s/9xktps8hl6/jci-psa-2026-13-v2), updated August 6, 2026\n\n- [Johnson Controls JCI-PSA-2026-07](https://tyco.widen.net/s/n5vdddqbcs/jci-psa-2026-07)\n\n- [Johnson Controls JCI-PSA-2026-16](https://tyco.widen.net/s/s9cchrkg87/jci-psa-2026-16)\n\n- [Johnson Controls Product Security Advisory register](https://www.johnsoncontrols.com/trust-center/cybersecurity/security-advisories)\n\nSource review completed August 12, 2026. Recheck the official advisories before changing production systems." }, { "id": "https://update.dsesecurity.com/updates/welcome-to-dse-updates/", "slug": "welcome-to-dse-updates", "url": "https://update.dsesecurity.com/updates/welcome-to-dse-updates/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/welcome-to-dse-updates.md", "json": "https://update.dsesecurity.com/api/v1/posts/welcome-to-dse-updates/" }, "title": "Welcome to DSE Updates: security guidance without the noise", "summary": "A public, read-only knowledge hub where DSE turns selected, source-backed physical security, IT, and cybersecurity developments into practical guidance.", "format": { "slug": "explainer", "name": "Explainer" }, "priority": { "slug": "info", "name": "Information" }, "featured": true, "image": { "theme": "dse-engineering", "label": "DSE engineering", "alt": "Physical security, networks, and engineered systems converging into one integrated platform.", "card_url": "https://update.dsesecurity.com/assets/editorial/dse-engineering-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/dse-engineering-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/dse-engineering-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "dse-world", "name": "DSE World", "url": "https://update.dsesecurity.com/topic/dse-world/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-17T09:00:00+00:00", "modified_at": "2026-07-19T19:29:33+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 1, "word_count": 215, "potentially_affected": "DSE customers and Michigan organizations responsible for surveillance, access control, networks, endpoints, cloud services, and cybersecurity operations.", "dse_recommendation": "Bookmark this publication, share it with the people who own your security and technology systems, and contact DSE when an update may affect your environment.", "primary_source": { "name": "DSE Updates editorial methodology", "url": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "published_on": null, "authority": "DSE Security editorial guidance" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Security and technology teams receive a constant stream of release notes, vulnerability disclosures, product notices, and urgent-sounding headlines. DSE Updates is a public editorial library designed to make selected information easier to use. Authorized DSE staff periodically review official vendor and government sources and publish source-backed guidance when an item is selected for coverage. It is not a continuous monitoring service, a customer-specific alert feed, or a substitute for opening a support ticket.
\nEvery time-sensitive briefing links to an official source and separates confirmed facts from DSE recommendations. Priority labels reflect likely operational urgency, but they do not replace an environment-specific assessment. Product versions, configurations, exposure, and business impact all matter.
\nOnly authorized DSE staff can publish or change articles. Customers can read, search, filter, and share updates without public posting, comments, or voting. This keeps the publication focused, professional, and accountable.
", "content_text": "What this publication is for\nSecurity and technology teams receive a constant stream of release notes, vulnerability disclosures, product notices, and urgent-sounding headlines. DSE Updates is a public editorial library designed to make selected information easier to use. Authorized DSE staff periodically review official vendor and government sources and publish source-backed guidance when an item is selected for coverage. It is not a continuous monitoring service, a customer-specific alert feed, or a substitute for opening a support ticket.\nWhat we cover\n\nVideo surveillance: device firmware, video-management platforms, recording infrastructure, and secure deployment practices.\nAccess control: controllers, readers, credentials, management software, and connected door hardware.\nIT: operating systems, networks, cloud platforms, endpoints, servers, and business applications.\nCybersecurity: exploited vulnerabilities, defensive guidance, identity, hardening, and recovery readiness.\nDSE World: service announcements, new capabilities, and guidance from Detection Systems & Engineering.\n\nOur editorial standard\nEvery time-sensitive briefing links to an official source and separates confirmed facts from DSE recommendations. Priority labels reflect likely operational urgency, but they do not replace an environment-specific assessment. Product versions, configurations, exposure, and business impact all matter.\nA focused, read-only customer experience\nOnly authorized DSE staff can publish or change articles. Customers can read, search, filter, and share updates without public posting, comments, or voting. This keeps the publication focused, professional, and accountable.", "content_markdown": "## What this publication is for\n\nSecurity and technology teams receive a constant stream of release notes, vulnerability disclosures, product notices, and urgent-sounding headlines. DSE Updates is a public editorial library designed to make selected information easier to use. Authorized DSE staff periodically review official vendor and government sources and publish source-backed guidance when an item is selected for coverage. It is not a continuous monitoring service, a customer-specific alert feed, or a substitute for opening a support ticket.\n\n## What we cover\n\n- Video surveillance: device firmware, video-management platforms, recording infrastructure, and secure deployment practices.\n\n- Access control: controllers, readers, credentials, management software, and connected door hardware.\n\n- IT: operating systems, networks, cloud platforms, endpoints, servers, and business applications.\n\n- Cybersecurity: exploited vulnerabilities, defensive guidance, identity, hardening, and recovery readiness.\n\n- DSE World: service announcements, new capabilities, and guidance from Detection Systems & Engineering.\n\n## Our editorial standard\n\nEvery time-sensitive briefing links to an official source and separates confirmed facts from DSE recommendations. Priority labels reflect likely operational urgency, but they do not replace an environment-specific assessment. Product versions, configurations, exposure, and business impact all matter.\n\n## A focused, read-only customer experience\n\nOnly authorized DSE staff can publish or change articles. Customers can read, search, filter, and share updates without public posting, comments, or voting. This keeps the publication focused, professional, and accountable." }, { "id": "https://update.dsesecurity.com/updates/plan-cloudflare-hsts-rollback-before-removing-https-or-changing-proxy-routing/", "slug": "plan-cloudflare-hsts-rollback-before-removing-https-or-changing-proxy-routing", "url": "https://update.dsesecurity.com/updates/plan-cloudflare-hsts-rollback-before-removing-https-or-changing-proxy-routing/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/plan-cloudflare-hsts-rollback-before-removing-https-or-changing-proxy-routing.md", "json": "https://update.dsesecurity.com/api/v1/posts/plan-cloudflare-hsts-rollback-before-removing-https-or-changing-proxy-routing/" }, "title": "Plan Cloudflare HSTS rollback before removing HTTPS or changing proxy routing", "summary": "A browser can retain the HTTPS requirement after a dashboard setting changes.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:17:05+00:00", "modified_at": "2026-10-20T18:34:37+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 254, "potentially_affected": "This concerns Cloudflare HSTS configuration and browser-retained policy.", "dse_recommendation": "DSE recommends inventorying all affected hostnames and their certificate coverage before choosing includeSubDomains or preload.", "primary_source": { "name": "Cloudflare — HTTP Strict Transport Security (HSTS)", "url": "https://developers.cloudflare.com/ssl/edge-certificates/additional-options/http-strict-transport-security/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A browser can retain the HTTPS requirement after a dashboard setting changes.
\nCloudflare warns that removing HTTPS before disabling HSTS and waiting out the original max-age can leave the website inaccessible to affected browsers. Its disable procedure sends a zero max-age. includeSubDomains extends the requirement to child names, which become inaccessible if they lack working HTTPS. Preload introduces an additional browser-list process beyond merely enabling the setting.
\nSource: Cloudflare — HTTP Strict Transport Security (HSTS).
\nThis concerns Cloudflare HSTS configuration and browser-retained policy.
\nDSE recommends inventorying all affected hostnames and their certificate coverage before choosing includeSubDomains or preload. Keep valid HTTPS available throughout migrations, emergency routing changes, and policy retirement. Record max-age and any preload submission in the recovery plan so a future administrator does not assume switching the dashboard off immediately reverses prior browser policy. Prefer a staged rollout with a verified certificate-renewal process. Ask the recovery owner to review the longest retained policy interval and every child name before approving proxy removal or HTTPS retirement. Keep the zero-age delivery plan and any preload-removal work as separate checkpoints. A dashboard toggle alone should not close the recovery exercise.
\nUse controlled browser profiles to inspect the HTTPS header on the exact hostname and confirm valid TLS throughout the proposed recovery route. Rehearse zero max-age delivery where appropriate and account for clients that have not revisited. Verify child hostnames independently rather than assuming the parent site’s successful test covers them.
\nCloudflare — HTTP Strict Transport Security (HSTS). Reviewed October 20, 2026.
", "content_text": "A browser can retain the HTTPS requirement after a dashboard setting changes.\nSource facts\nCloudflare warns that removing HTTPS before disabling HSTS and waiting out the original max-age can leave the website inaccessible to affected browsers. Its disable procedure sends a zero max-age. includeSubDomains extends the requirement to child names, which become inaccessible if they lack working HTTPS. Preload introduces an additional browser-list process beyond merely enabling the setting.\nSource: Cloudflare — HTTP Strict Transport Security (HSTS).\nApplicability\nThis concerns Cloudflare HSTS configuration and browser-retained policy.\nDSE recommendation\nDSE recommends inventorying all affected hostnames and their certificate coverage before choosing includeSubDomains or preload. Keep valid HTTPS available throughout migrations, emergency routing changes, and policy retirement. Record max-age and any preload submission in the recovery plan so a future administrator does not assume switching the dashboard off immediately reverses prior browser policy. Prefer a staged rollout with a verified certificate-renewal process. Ask the recovery owner to review the longest retained policy interval and every child name before approving proxy removal or HTTPS retirement. Keep the zero-age delivery plan and any preload-removal work as separate checkpoints. A dashboard toggle alone should not close the recovery exercise.\nVerification\nUse controlled browser profiles to inspect the HTTPS header on the exact hostname and confirm valid TLS throughout the proposed recovery route. Rehearse zero max-age delivery where appropriate and account for clients that have not revisited. Verify child hostnames independently rather than assuming the parent site’s successful test covers them.\nOfficial reference\nCloudflare — HTTP Strict Transport Security (HSTS). Reviewed October 20, 2026.", "content_markdown": "A browser can retain the HTTPS requirement after a dashboard setting changes.\n\n## Source facts\n\nCloudflare warns that removing HTTPS before disabling HSTS and waiting out the original max-age can leave the website inaccessible to affected browsers. Its disable procedure sends a zero max-age. includeSubDomains extends the requirement to child names, which become inaccessible if they lack working HTTPS. Preload introduces an additional browser-list process beyond merely enabling the setting.\n\nSource: [Cloudflare — HTTP Strict Transport Security (HSTS)](https://developers.cloudflare.com/ssl/edge-certificates/additional-options/http-strict-transport-security/).\n\n## Applicability\n\nThis concerns Cloudflare HSTS configuration and browser-retained policy.\n\n## DSE recommendation\n\nDSE recommends inventorying all affected hostnames and their certificate coverage before choosing includeSubDomains or preload. Keep valid HTTPS available throughout migrations, emergency routing changes, and policy retirement. Record max-age and any preload submission in the recovery plan so a future administrator does not assume switching the dashboard off immediately reverses prior browser policy. Prefer a staged rollout with a verified certificate-renewal process. Ask the recovery owner to review the longest retained policy interval and every child name before approving proxy removal or HTTPS retirement. Keep the zero-age delivery plan and any preload-removal work as separate checkpoints. A dashboard toggle alone should not close the recovery exercise.\n\n## Verification\n\nUse controlled browser profiles to inspect the HTTPS header on the exact hostname and confirm valid TLS throughout the proposed recovery route. Rehearse zero max-age delivery where appropriate and account for clients that have not revisited. Verify child hostnames independently rather than assuming the parent site’s successful test covers them.\n\n## Official reference\n\n[Cloudflare — HTTP Strict Transport Security (HSTS)](https://developers.cloudflare.com/ssl/edge-certificates/additional-options/http-strict-transport-security/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/choose-account-specific-cloudflare-origin-authentication-when-a-shared-network-certificate-is-insufficient/", "slug": "choose-account-specific-cloudflare-origin-authentication-when-a-shared-network-certificate-is-insufficient", "url": "https://update.dsesecurity.com/updates/choose-account-specific-cloudflare-origin-authentication-when-a-shared-network-certificate-is-insufficient/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/choose-account-specific-cloudflare-origin-authentication-when-a-shared-network-certificate-is-insufficient.md", "json": "https://update.dsesecurity.com/api/v1/posts/choose-account-specific-cloudflare-origin-authentication-when-a-shared-network-certificate-is-insufficient/" }, "title": "Choose account-specific Cloudflare origin authentication when a shared network certificate is insufficient", "summary": "Global Authenticated Origin Pulls proves Cloudflare network origin, not your account specifically.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:17:04+00:00", "modified_at": "2026-10-20T18:34:37+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 250, "potentially_affected": "This concerns client-certificate authentication of Cloudflare-to-origin web requests.", "dse_recommendation": "DSE recommends stating whether the requirement is network provenance or account-specific origin access before choosing a level.", "primary_source": { "name": "Cloudflare — Authenticated Origin Pulls (mTLS)", "url": "https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Global Authenticated Origin Pulls proves Cloudflare network origin, not your account specifically.
\nCloudflare documents global AOP using a certificate shared across accounts, while zone-level and per-hostname configurations use uploaded certificates. The more specific levels take precedence and are independently enabled. The source also states AOP has no effect for Cloudflare Tunnel origins, whose connector credentials authenticate the outbound tunnel path instead.
\nSource: Cloudflare — Authenticated Origin Pulls (mTLS).
\nThis concerns client-certificate authentication of Cloudflare-to-origin web requests.
\nDSE recommends stating whether the requirement is network provenance or account-specific origin access before choosing a level. Configure and enforce the corresponding certificate trust at the origin; a dashboard switch alone does not establish rejection of unauthorized requests. Keep certificate rotation, private-key custody, and hostname scope documented. Do not add AOP to a Tunnel hostname expecting it to change the connector’s authentication model. Ask the origin owner to write the exact identity that must be proven: any Cloudflare network request or the organization’s chosen certificate. Keep a rejected unauthorized request beside the successful proxy request. Review the most-specific enabled level when rotating certificates rather than assuming a zone change overrides every hostname.
\nIn a controlled origin test, confirm valid proxied requests succeed and direct requests lacking the required client certificate are rejected. Verify the presented certificate at each configured level and test rotation before expiry. Inspect server-certificate validation separately so origin authentication does not conceal an unrelated TLS trust problem.
\nCloudflare — Authenticated Origin Pulls (mTLS). Reviewed October 20, 2026.
", "content_text": "Global Authenticated Origin Pulls proves Cloudflare network origin, not your account specifically.\nSource facts\nCloudflare documents global AOP using a certificate shared across accounts, while zone-level and per-hostname configurations use uploaded certificates. The more specific levels take precedence and are independently enabled. The source also states AOP has no effect for Cloudflare Tunnel origins, whose connector credentials authenticate the outbound tunnel path instead.\nSource: Cloudflare — Authenticated Origin Pulls (mTLS).\nApplicability\nThis concerns client-certificate authentication of Cloudflare-to-origin web requests.\nDSE recommendation\nDSE recommends stating whether the requirement is network provenance or account-specific origin access before choosing a level. Configure and enforce the corresponding certificate trust at the origin; a dashboard switch alone does not establish rejection of unauthorized requests. Keep certificate rotation, private-key custody, and hostname scope documented. Do not add AOP to a Tunnel hostname expecting it to change the connector’s authentication model. Ask the origin owner to write the exact identity that must be proven: any Cloudflare network request or the organization’s chosen certificate. Keep a rejected unauthorized request beside the successful proxy request. Review the most-specific enabled level when rotating certificates rather than assuming a zone change overrides every hostname.\nVerification\nIn a controlled origin test, confirm valid proxied requests succeed and direct requests lacking the required client certificate are rejected. Verify the presented certificate at each configured level and test rotation before expiry. Inspect server-certificate validation separately so origin authentication does not conceal an unrelated TLS trust problem.\nOfficial reference\nCloudflare — Authenticated Origin Pulls (mTLS). Reviewed October 20, 2026.", "content_markdown": "Global Authenticated Origin Pulls proves Cloudflare network origin, not your account specifically.\n\n## Source facts\n\nCloudflare documents global AOP using a certificate shared across accounts, while zone-level and per-hostname configurations use uploaded certificates. The more specific levels take precedence and are independently enabled. The source also states AOP has no effect for Cloudflare Tunnel origins, whose connector credentials authenticate the outbound tunnel path instead.\n\nSource: [Cloudflare — Authenticated Origin Pulls (mTLS)](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/).\n\n## Applicability\n\nThis concerns client-certificate authentication of Cloudflare-to-origin web requests.\n\n## DSE recommendation\n\nDSE recommends stating whether the requirement is network provenance or account-specific origin access before choosing a level. Configure and enforce the corresponding certificate trust at the origin; a dashboard switch alone does not establish rejection of unauthorized requests. Keep certificate rotation, private-key custody, and hostname scope documented. Do not add AOP to a Tunnel hostname expecting it to change the connector’s authentication model. Ask the origin owner to write the exact identity that must be proven: any Cloudflare network request or the organization’s chosen certificate. Keep a rejected unauthorized request beside the successful proxy request. Review the most-specific enabled level when rotating certificates rather than assuming a zone change overrides every hostname.\n\n## Verification\n\nIn a controlled origin test, confirm valid proxied requests succeed and direct requests lacking the required client certificate are rejected. Verify the presented certificate at each configured level and test rotation before expiry. Inspect server-certificate validation separately so origin authentication does not conceal an unrelated TLS trust problem.\n\n## Official reference\n\n[Cloudflare — Authenticated Origin Pulls (mTLS)](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/plan-direct-access-behavior-before-using-cloudflare-origin-ca-certificates/", "slug": "plan-direct-access-behavior-before-using-cloudflare-origin-ca-certificates", "url": "https://update.dsesecurity.com/updates/plan-direct-access-behavior-before-using-cloudflare-origin-ca-certificates/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/plan-direct-access-behavior-before-using-cloudflare-origin-ca-certificates.md", "json": "https://update.dsesecurity.com/api/v1/posts/plan-direct-access-behavior-before-using-cloudflare-origin-ca-certificates/" }, "title": "Plan direct-access behavior before using Cloudflare Origin CA certificates", "summary": "A certificate trusted by Cloudflare is not necessarily trusted by a visitor connecting directly.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:17:03+00:00", "modified_at": "2026-10-20T18:34:37+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 268, "potentially_affected": "This concerns Cloudflare Origin CA, not a publicly trusted visitor-facing certificate or a client certificate for authenticated origin requests.", "dse_recommendation": "DSE recommends deciding whether emergency direct access is an intended recovery path before selecting the issuer.", "primary_source": { "name": "Cloudflare — Cloudflare origin CA", "url": "https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A certificate trusted by Cloudflare is not necessarily trusted by a visitor connecting directly.
\nCloudflare documents Origin CA certificates for the connection between its proxy and an origin. It warns that pausing Cloudflare or disabling proxying can expose visitors to untrusted-certificate errors because ordinary browsers do not use that origin-only trust model. The source also states that Origin CA expiry notifications are not currently sent, requiring independent inventory or monitoring.
\nSource: Cloudflare — Cloudflare origin CA.
\nThis concerns Cloudflare Origin CA, not a publicly trusted visitor-facing certificate or a client certificate for authenticated origin requests.
\nDSE recommends deciding whether emergency direct access is an intended recovery path before selecting the issuer. If it is required, prepare an appropriate publicly trusted certificate or another supported recovery method rather than assuming proxy removal is transparent. Track origin certificate expiry independently and assign a renewal owner. Keep the private key outside public web paths and do not copy it into support evidence. Mark emergency direct access as supported, deliberately unavailable, or unresolved in the recovery plan. Ask the website owner to demonstrate the chosen recovery path without trust warnings. Include expiry ownership in that same review so an origin-only certificate is not omitted from the normal renewal inventory.
\nInspect the origin certificate and test the normal proxied website path. In an isolated or controlled recovery rehearsal, verify the planned direct-access method with normal trust validation and the correct hostname. Confirm the expiry-monitoring path reaches the responsible team, recording certificate metadata without exposing key material or disabling browser warnings.
\nCloudflare — Cloudflare origin CA. Reviewed October 20, 2026.
", "content_text": "A certificate trusted by Cloudflare is not necessarily trusted by a visitor connecting directly.\nSource facts\nCloudflare documents Origin CA certificates for the connection between its proxy and an origin. It warns that pausing Cloudflare or disabling proxying can expose visitors to untrusted-certificate errors because ordinary browsers do not use that origin-only trust model. The source also states that Origin CA expiry notifications are not currently sent, requiring independent inventory or monitoring.\nSource: Cloudflare — Cloudflare origin CA.\nApplicability\nThis concerns Cloudflare Origin CA, not a publicly trusted visitor-facing certificate or a client certificate for authenticated origin requests.\nDSE recommendation\nDSE recommends deciding whether emergency direct access is an intended recovery path before selecting the issuer. If it is required, prepare an appropriate publicly trusted certificate or another supported recovery method rather than assuming proxy removal is transparent. Track origin certificate expiry independently and assign a renewal owner. Keep the private key outside public web paths and do not copy it into support evidence. Mark emergency direct access as supported, deliberately unavailable, or unresolved in the recovery plan. Ask the website owner to demonstrate the chosen recovery path without trust warnings. Include expiry ownership in that same review so an origin-only certificate is not omitted from the normal renewal inventory.\nVerification\nInspect the origin certificate and test the normal proxied website path. In an isolated or controlled recovery rehearsal, verify the planned direct-access method with normal trust validation and the correct hostname. Confirm the expiry-monitoring path reaches the responsible team, recording certificate metadata without exposing key material or disabling browser warnings.\nOfficial reference\nCloudflare — Cloudflare origin CA. Reviewed October 20, 2026.", "content_markdown": "A certificate trusted by Cloudflare is not necessarily trusted by a visitor connecting directly.\n\n## Source facts\n\nCloudflare documents Origin CA certificates for the connection between its proxy and an origin. It warns that pausing Cloudflare or disabling proxying can expose visitors to untrusted-certificate errors because ordinary browsers do not use that origin-only trust model. The source also states that Origin CA expiry notifications are not currently sent, requiring independent inventory or monitoring.\n\nSource: [Cloudflare — Cloudflare origin CA](https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/).\n\n## Applicability\n\nThis concerns Cloudflare Origin CA, not a publicly trusted visitor-facing certificate or a client certificate for authenticated origin requests.\n\n## DSE recommendation\n\nDSE recommends deciding whether emergency direct access is an intended recovery path before selecting the issuer. If it is required, prepare an appropriate publicly trusted certificate or another supported recovery method rather than assuming proxy removal is transparent. Track origin certificate expiry independently and assign a renewal owner. Keep the private key outside public web paths and do not copy it into support evidence. Mark emergency direct access as supported, deliberately unavailable, or unresolved in the recovery plan. Ask the website owner to demonstrate the chosen recovery path without trust warnings. Include expiry ownership in that same review so an origin-only certificate is not omitted from the normal renewal inventory.\n\n## Verification\n\nInspect the origin certificate and test the normal proxied website path. In an isolated or controlled recovery rehearsal, verify the planned direct-access method with normal trust validation and the correct hostname. Confirm the expiry-monitoring path reaches the responsible team, recording certificate metadata without exposing key material or disabling browser warnings.\n\n## Official reference\n\n[Cloudflare — Cloudflare origin CA](https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/prepare-the-origin-certificate-before-switching-cloudflare-to-full-strict/", "slug": "prepare-the-origin-certificate-before-switching-cloudflare-to-full-strict", "url": "https://update.dsesecurity.com/updates/prepare-the-origin-certificate-before-switching-cloudflare-to-full-strict/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/prepare-the-origin-certificate-before-switching-cloudflare-to-full-strict.md", "json": "https://update.dsesecurity.com/api/v1/posts/prepare-the-origin-certificate-before-switching-cloudflare-to-full-strict/" }, "title": "Prepare the origin certificate before switching Cloudflare to Full strict", "summary": "The edge-to-origin connection must meet validity, issuer, and hostname requirements.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:17:02+00:00", "modified_at": "2026-10-20T18:34:37+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 268, "potentially_affected": "This concerns Cloudflare's website origin TLS mode.", "dse_recommendation": "DSE recommends inventorying every origin and hostname affected by the mode before changing it.", "primary_source": { "name": "Cloudflare — Full (strict) - SSL/TLS encryption modes", "url": "https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "The edge-to-origin connection must meet validity, issuer, and hostname requirements.
\nCloudflare states that Full (strict) validates the origin certificate rather than merely encrypting that connection. The certificate must be within its validity period, issued by a publicly trusted CA or Cloudflare Origin CA, and match the requested or target hostname. The origin must accept HTTPS on the required port; failing the prerequisites can produce a 526 error.
\nSource: Cloudflare — Full (strict) – SSL/TLS encryption modes.
\nThis concerns Cloudflare’s website origin TLS mode.
\nDSE recommends inventorying every origin and hostname affected by the mode before changing it. Install and validate the origin certificate and chain first, including renewal ownership and required network access. Check the actual target hostname used by origin routing rather than assuming it always equals the public name. Keep a tested rollback that preserves an appropriate security posture instead of leaving validation disabled as a permanent workaround. Have each origin owner approve the hostname used for the TLS validation check, including any configured target override. Keep the intended issuer and renewal contact beside that name. Require the origin prerequisites to pass before the edge setting changes rather than troubleshooting certificate eligibility after production traffic fails.
\nFor each approved origin, inspect certificate name, validity, chain, and listener before enabling the mode. Then request representative public paths through Cloudflare with normal browser validation. Confirm the origin connection succeeds, review any 526 evidence, and separately verify redirects and mixed-content behavior rather than treating a single successful TLS handshake as complete website acceptance.
\nCloudflare — Full (strict) – SSL/TLS encryption modes. Reviewed October 20, 2026.
", "content_text": "The edge-to-origin connection must meet validity, issuer, and hostname requirements.\nSource facts\nCloudflare states that Full (strict) validates the origin certificate rather than merely encrypting that connection. The certificate must be within its validity period, issued by a publicly trusted CA or Cloudflare Origin CA, and match the requested or target hostname. The origin must accept HTTPS on the required port; failing the prerequisites can produce a 526 error.\nSource: Cloudflare — Full (strict) – SSL/TLS encryption modes.\nApplicability\nThis concerns Cloudflare’s website origin TLS mode.\nDSE recommendation\nDSE recommends inventorying every origin and hostname affected by the mode before changing it. Install and validate the origin certificate and chain first, including renewal ownership and required network access. Check the actual target hostname used by origin routing rather than assuming it always equals the public name. Keep a tested rollback that preserves an appropriate security posture instead of leaving validation disabled as a permanent workaround. Have each origin owner approve the hostname used for the TLS validation check, including any configured target override. Keep the intended issuer and renewal contact beside that name. Require the origin prerequisites to pass before the edge setting changes rather than troubleshooting certificate eligibility after production traffic fails.\nVerification\nFor each approved origin, inspect certificate name, validity, chain, and listener before enabling the mode. Then request representative public paths through Cloudflare with normal browser validation. Confirm the origin connection succeeds, review any 526 evidence, and separately verify redirects and mixed-content behavior rather than treating a single successful TLS handshake as complete website acceptance.\nOfficial reference\nCloudflare — Full (strict) – SSL/TLS encryption modes. Reviewed October 20, 2026.", "content_markdown": "The edge-to-origin connection must meet validity, issuer, and hostname requirements.\n\n## Source facts\n\nCloudflare states that Full (strict) validates the origin certificate rather than merely encrypting that connection. The certificate must be within its validity period, issued by a publicly trusted CA or Cloudflare Origin CA, and match the requested or target hostname. The origin must accept HTTPS on the required port; failing the prerequisites can produce a 526 error.\n\nSource: [Cloudflare — Full (strict) – SSL/TLS encryption modes](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/).\n\n## Applicability\n\nThis concerns Cloudflare’s website origin TLS mode.\n\n## DSE recommendation\n\nDSE recommends inventorying every origin and hostname affected by the mode before changing it. Install and validate the origin certificate and chain first, including renewal ownership and required network access. Check the actual target hostname used by origin routing rather than assuming it always equals the public name. Keep a tested rollback that preserves an appropriate security posture instead of leaving validation disabled as a permanent workaround. Have each origin owner approve the hostname used for the TLS validation check, including any configured target override. Keep the intended issuer and renewal contact beside that name. Require the origin prerequisites to pass before the edge setting changes rather than troubleshooting certificate eligibility after production traffic fails.\n\n## Verification\n\nFor each approved origin, inspect certificate name, validity, chain, and listener before enabling the mode. Then request representative public paths through Cloudflare with normal browser validation. Confirm the origin connection succeeds, review any 526 evidence, and separately verify redirects and mixed-content behavior rather than treating a single successful TLS handshake as complete website acceptance.\n\n## Official reference\n\n[Cloudflare — Full (strict) – SSL/TLS encryption modes](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/keep-the-cloudflare-mail-server-address-path-separate-from-the-web-proxy/", "slug": "keep-the-cloudflare-mail-server-address-path-separate-from-the-web-proxy", "url": "https://update.dsesecurity.com/updates/keep-the-cloudflare-mail-server-address-path-separate-from-the-web-proxy/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/keep-the-cloudflare-mail-server-address-path-separate-from-the-web-proxy.md", "json": "https://update.dsesecurity.com/api/v1/posts/keep-the-cloudflare-mail-server-address-path-separate-from-the-web-proxy/" }, "title": "Keep the Cloudflare mail-server address path separate from the web proxy", "summary": "An MX target needs the correct mail host address, not a website proxy endpoint.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:17:01+00:00", "modified_at": "2026-10-20T18:34:37+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 257, "potentially_affected": "This concerns DNS for mail services using Cloudflare authoritative DNS.", "dse_recommendation": "DSE recommends identifying every hostname used by MX, submission, IMAP, and webmail before changing proxy status.", "primary_source": { "name": "Cloudflare — Set up email records", "url": "https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "An MX target needs the correct mail host address, not a website proxy endpoint.
\nCloudflare’s mail setup guide pairs an MX record with an A or AAAA address for the mail subdomain and shows that address as DNS-only. It states that ordinary Cloudflare service does not proxy SMTP on port 25. The exact records must come from the mail provider; receiving mail, sending mail, and email-authentication records serve different purposes.
\nSource: Cloudflare — Set up email records.
\nThis concerns DNS for mail services using Cloudflare authoritative DNS.
\nDSE recommends identifying every hostname used by MX, submission, IMAP, and webmail before changing proxy status. Keep ordinary mail transports on the provider-supported DNS-only path and review webmail separately as a web service. Preserve SPF, DKIM, and DMARC during a website migration. Do not repoint mail to the website’s address solely because both services share a domain or because the homepage works through Cloudflare. Keep the MX target, its resolved address, and its approved proxy status together in the mail inventory. Have the messaging owner approve them during a website DNS migration. Test the actual delivery path independently from webmail so success of one service cannot hide a broken transport hostname.
\nQuery the domain’s MX and each target’s address records, then compare them with the mail provider’s instructions. Perform authorized inbound and outbound delivery tests and inspect server evidence separately from DNS. Verify the client-facing TLS hostname and avoid reporting delivery success from a DNS lookup alone.
\nCloudflare — Set up email records. Reviewed October 20, 2026.
", "content_text": "An MX target needs the correct mail host address, not a website proxy endpoint.\nSource facts\nCloudflare’s mail setup guide pairs an MX record with an A or AAAA address for the mail subdomain and shows that address as DNS-only. It states that ordinary Cloudflare service does not proxy SMTP on port 25. The exact records must come from the mail provider; receiving mail, sending mail, and email-authentication records serve different purposes.\nSource: Cloudflare — Set up email records.\nApplicability\nThis concerns DNS for mail services using Cloudflare authoritative DNS.\nDSE recommendation\nDSE recommends identifying every hostname used by MX, submission, IMAP, and webmail before changing proxy status. Keep ordinary mail transports on the provider-supported DNS-only path and review webmail separately as a web service. Preserve SPF, DKIM, and DMARC during a website migration. Do not repoint mail to the website’s address solely because both services share a domain or because the homepage works through Cloudflare. Keep the MX target, its resolved address, and its approved proxy status together in the mail inventory. Have the messaging owner approve them during a website DNS migration. Test the actual delivery path independently from webmail so success of one service cannot hide a broken transport hostname.\nVerification\nQuery the domain’s MX and each target’s address records, then compare them with the mail provider’s instructions. Perform authorized inbound and outbound delivery tests and inspect server evidence separately from DNS. Verify the client-facing TLS hostname and avoid reporting delivery success from a DNS lookup alone.\nOfficial reference\nCloudflare — Set up email records. Reviewed October 20, 2026.", "content_markdown": "An MX target needs the correct mail host address, not a website proxy endpoint.\n\n## Source facts\n\nCloudflare’s mail setup guide pairs an MX record with an A or AAAA address for the mail subdomain and shows that address as DNS-only. It states that ordinary Cloudflare service does not proxy SMTP on port 25. The exact records must come from the mail provider; receiving mail, sending mail, and email-authentication records serve different purposes.\n\nSource: [Cloudflare — Set up email records](https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/).\n\n## Applicability\n\nThis concerns DNS for mail services using Cloudflare authoritative DNS.\n\n## DSE recommendation\n\nDSE recommends identifying every hostname used by MX, submission, IMAP, and webmail before changing proxy status. Keep ordinary mail transports on the provider-supported DNS-only path and review webmail separately as a web service. Preserve SPF, DKIM, and DMARC during a website migration. Do not repoint mail to the website’s address solely because both services share a domain or because the homepage works through Cloudflare. Keep the MX target, its resolved address, and its approved proxy status together in the mail inventory. Have the messaging owner approve them during a website DNS migration. Test the actual delivery path independently from webmail so success of one service cannot hide a broken transport hostname.\n\n## Verification\n\nQuery the domain’s MX and each target’s address records, then compare them with the mail provider’s instructions. Perform authorized inbound and outbound delivery tests and inspect server evidence separately from DNS. Verify the client-facing TLS hostname and avoid reporting delivery success from a DNS lookup alone.\n\n## Official reference\n\n[Cloudflare — Set up email records](https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/reconcile-cloudflare-s-onboarding-scan-with-the-authoritative-dns-inventory/", "slug": "reconcile-cloudflare-s-onboarding-scan-with-the-authoritative-dns-inventory", "url": "https://update.dsesecurity.com/updates/reconcile-cloudflare-s-onboarding-scan-with-the-authoritative-dns-inventory/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/reconcile-cloudflare-s-onboarding-scan-with-the-authoritative-dns-inventory.md", "json": "https://update.dsesecurity.com/api/v1/posts/reconcile-cloudflare-s-onboarding-scan-with-the-authoritative-dns-inventory/" }, "title": "Reconcile Cloudflare's onboarding scan with the authoritative DNS inventory", "summary": "Pattern-based discovery can miss unusual hostnames and custom DKIM selectors.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:17:00+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 245, "potentially_affected": "This concerns Cloudflare's onboarding DNS scan.", "dse_recommendation": "DSE recommends obtaining an authoritative export or provider inventory and reconciling the scan row by row.", "primary_source": { "name": "Cloudflare — Records quick scan", "url": "https://developers.cloudflare.com/dns/zone-setups/reference/dns-quick-scan/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Pattern-based discovery can miss unusual hostnames and custom DKIM selectors.
\nCloudflare states that its quick scan uses recurring record type/name patterns rather than a complete zone-specific inventory. Unusual service names and custom DKIM selectors may not be discovered. The guide explicitly instructs users to review records and add missing entries before changing nameservers. A successful scan therefore does not establish migration completeness.
\nSource: Cloudflare — Records quick scan.
\nThis concerns Cloudflare’s onboarding DNS scan.
\nDSE recommends obtaining an authoritative export or provider inventory and reconciling the scan row by row. Include mail routing, authentication, verification, SRV records, uncommon application subdomains, and delegations. Ask service owners about names not visible in a generic website check. Preserve the original export and log deliberate omissions so a later delivery or login failure can be investigated against an actual migration record. Give each unmatched inventory row an explicit disposition: import, deliberate retirement, or unresolved owner review. Ask the mail owner to check custom selector names and the application owner to check uncommon service records. Leave cutover incomplete while an essential name has no accepted disposition.
\nBefore cutover, compare the proposed Cloudflare zone with the approved inventory by record type, owner name, and value. Query representative uncommon names directly against the assigned authoritative servers. After activation, test the dependent services and confirm no records were silently omitted merely because the public homepage and www address work.
\nCloudflare — Records quick scan. Reviewed October 20, 2026.
", "content_text": "Pattern-based discovery can miss unusual hostnames and custom DKIM selectors.\nSource facts\nCloudflare states that its quick scan uses recurring record type/name patterns rather than a complete zone-specific inventory. Unusual service names and custom DKIM selectors may not be discovered. The guide explicitly instructs users to review records and add missing entries before changing nameservers. A successful scan therefore does not establish migration completeness.\nSource: Cloudflare — Records quick scan.\nApplicability\nThis concerns Cloudflare’s onboarding DNS scan.\nDSE recommendation\nDSE recommends obtaining an authoritative export or provider inventory and reconciling the scan row by row. Include mail routing, authentication, verification, SRV records, uncommon application subdomains, and delegations. Ask service owners about names not visible in a generic website check. Preserve the original export and log deliberate omissions so a later delivery or login failure can be investigated against an actual migration record. Give each unmatched inventory row an explicit disposition: import, deliberate retirement, or unresolved owner review. Ask the mail owner to check custom selector names and the application owner to check uncommon service records. Leave cutover incomplete while an essential name has no accepted disposition.\nVerification\nBefore cutover, compare the proposed Cloudflare zone with the approved inventory by record type, owner name, and value. Query representative uncommon names directly against the assigned authoritative servers. After activation, test the dependent services and confirm no records were silently omitted merely because the public homepage and www address work.\nOfficial reference\nCloudflare — Records quick scan. Reviewed October 20, 2026.", "content_markdown": "Pattern-based discovery can miss unusual hostnames and custom DKIM selectors.\n\n## Source facts\n\nCloudflare states that its quick scan uses recurring record type/name patterns rather than a complete zone-specific inventory. Unusual service names and custom DKIM selectors may not be discovered. The guide explicitly instructs users to review records and add missing entries before changing nameservers. A successful scan therefore does not establish migration completeness.\n\nSource: [Cloudflare — Records quick scan](https://developers.cloudflare.com/dns/zone-setups/reference/dns-quick-scan/).\n\n## Applicability\n\nThis concerns Cloudflare’s onboarding DNS scan.\n\n## DSE recommendation\n\nDSE recommends obtaining an authoritative export or provider inventory and reconciling the scan row by row. Include mail routing, authentication, verification, SRV records, uncommon application subdomains, and delegations. Ask service owners about names not visible in a generic website check. Preserve the original export and log deliberate omissions so a later delivery or login failure can be investigated against an actual migration record. Give each unmatched inventory row an explicit disposition: import, deliberate retirement, or unresolved owner review. Ask the mail owner to check custom selector names and the application owner to check uncommon service records. Leave cutover incomplete while an essential name has no accepted disposition.\n\n## Verification\n\nBefore cutover, compare the proposed Cloudflare zone with the approved inventory by record type, owner name, and value. Query representative uncommon names directly against the assigned authoritative servers. After activation, test the dependent services and confirm no records were silently omitted merely because the public homepage and www address work.\n\n## Official reference\n\n[Cloudflare — Records quick scan](https://developers.cloudflare.com/dns/zone-setups/reference/dns-quick-scan/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/coordinate-other-certificate-issuers-before-delegating-cloudflare-dcv/", "slug": "coordinate-other-certificate-issuers-before-delegating-cloudflare-dcv", "url": "https://update.dsesecurity.com/updates/coordinate-other-certificate-issuers-before-delegating-cloudflare-dcv/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/coordinate-other-certificate-issuers-before-delegating-cloudflare-dcv.md", "json": "https://update.dsesecurity.com/api/v1/posts/coordinate-other-certificate-issuers-before-delegating-cloudflare-dcv/" }, "title": "Coordinate other certificate issuers before delegating Cloudflare DCV", "summary": "The validation CNAME becomes a continuing authority path, not a disposable one-time proof.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:59+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 264, "potentially_affected": "This concerns the documented Cloudflare delegated-validation method.", "dse_recommendation": "DSE recommends inventorying all issuers and systems that validate the same hostnames before creating the CNAME.", "primary_source": { "name": "Cloudflare — Delegated DCV — Domain Control Validation — SSL/TLS", "url": "https://developers.cloudflare.com/ssl/edge-certificates/changing-dcv-method/methods/delegated-dcv/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "The validation CNAME becomes a continuing authority path, not a disposable one-time proof.
\nCloudflare documents delegated DCV for Advanced certificates in partial DNS setups, not Universal certificates. It uses persistent validation CNAME records so future orders can validate automatically. The guide warns that delegation is limited to one provider at a time and can interfere with other CDN or origin issuance workflows. Conflicting challenge TXT records also require review.
\nSource: Cloudflare — Delegated DCV — Domain Control Validation — SSL/TLS.
\nThis concerns the documented Cloudflare delegated-validation method.
\nDSE recommends inventorying all issuers and systems that validate the same hostnames before creating the CNAME. Coordinate origin, edge, and other-CDN renewal requirements and choose an alternative method where their coexistence demands it. Keep the validation record in the DNS inventory with a certificate owner and purpose. Do not remove it after initial issuance or delete conflicting records until their current owners and dependencies are understood. Have every current certificate issuer owner review the delegation before creating it. Record the intended ongoing renewal use beside the DNS entry and retain a contact for conflicts. Treat another issuer’s failed challenge as a coordination finding rather than deleting the continuing CNAME speculatively.
\nQuery the challenge CNAME through the authoritative path and inspect the intended target. Confirm certificate issuance and the documented renewal configuration in a controlled workflow. Check other issuer requirements separately and record the retained delegation, avoiding an assumption that temporary absence of a TXT token means the continuing CNAME is unnecessary.
\nCloudflare — Delegated DCV — Domain Control Validation — SSL/TLS. Reviewed October 20, 2026.
", "content_text": "The validation CNAME becomes a continuing authority path, not a disposable one-time proof.\nSource facts\nCloudflare documents delegated DCV for Advanced certificates in partial DNS setups, not Universal certificates. It uses persistent validation CNAME records so future orders can validate automatically. The guide warns that delegation is limited to one provider at a time and can interfere with other CDN or origin issuance workflows. Conflicting challenge TXT records also require review.\nSource: Cloudflare — Delegated DCV — Domain Control Validation — SSL/TLS.\nApplicability\nThis concerns the documented Cloudflare delegated-validation method.\nDSE recommendation\nDSE recommends inventorying all issuers and systems that validate the same hostnames before creating the CNAME. Coordinate origin, edge, and other-CDN renewal requirements and choose an alternative method where their coexistence demands it. Keep the validation record in the DNS inventory with a certificate owner and purpose. Do not remove it after initial issuance or delete conflicting records until their current owners and dependencies are understood. Have every current certificate issuer owner review the delegation before creating it. Record the intended ongoing renewal use beside the DNS entry and retain a contact for conflicts. Treat another issuer’s failed challenge as a coordination finding rather than deleting the continuing CNAME speculatively.\nVerification\nQuery the challenge CNAME through the authoritative path and inspect the intended target. Confirm certificate issuance and the documented renewal configuration in a controlled workflow. Check other issuer requirements separately and record the retained delegation, avoiding an assumption that temporary absence of a TXT token means the continuing CNAME is unnecessary.\nOfficial reference\nCloudflare — Delegated DCV — Domain Control Validation — SSL/TLS. Reviewed October 20, 2026.", "content_markdown": "The validation CNAME becomes a continuing authority path, not a disposable one-time proof.\n\n## Source facts\n\nCloudflare documents delegated DCV for Advanced certificates in partial DNS setups, not Universal certificates. It uses persistent validation CNAME records so future orders can validate automatically. The guide warns that delegation is limited to one provider at a time and can interfere with other CDN or origin issuance workflows. Conflicting challenge TXT records also require review.\n\nSource: [Cloudflare — Delegated DCV — Domain Control Validation — SSL/TLS](https://developers.cloudflare.com/ssl/edge-certificates/changing-dcv-method/methods/delegated-dcv/).\n\n## Applicability\n\nThis concerns the documented Cloudflare delegated-validation method.\n\n## DSE recommendation\n\nDSE recommends inventorying all issuers and systems that validate the same hostnames before creating the CNAME. Coordinate origin, edge, and other-CDN renewal requirements and choose an alternative method where their coexistence demands it. Keep the validation record in the DNS inventory with a certificate owner and purpose. Do not remove it after initial issuance or delete conflicting records until their current owners and dependencies are understood. Have every current certificate issuer owner review the delegation before creating it. Record the intended ongoing renewal use beside the DNS entry and retain a contact for conflicts. Treat another issuer’s failed challenge as a coordination finding rather than deleting the continuing CNAME speculatively.\n\n## Verification\n\nQuery the challenge CNAME through the authoritative path and inspect the intended target. Confirm certificate issuance and the documented renewal configuration in a controlled workflow. Check other issuer requirements separately and record the retained delegation, avoiding an assumption that temporary absence of a TXT token means the continuing CNAME is unnecessary.\n\n## Official reference\n\n[Cloudflare — Delegated DCV — Domain Control Validation — SSL/TLS](https://developers.cloudflare.com/ssl/edge-certificates/changing-dcv-method/methods/delegated-dcv/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/confirm-cross-provider-dnskey-support-before-planning-a-cloudflare-dnssec-preserving-migration/", "slug": "confirm-cross-provider-dnskey-support-before-planning-a-cloudflare-dnssec-preserving-migration", "url": "https://update.dsesecurity.com/updates/confirm-cross-provider-dnskey-support-before-planning-a-cloudflare-dnssec-preserving-migration/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/confirm-cross-provider-dnskey-support-before-planning-a-cloudflare-dnssec-preserving-migration.md", "json": "https://update.dsesecurity.com/api/v1/posts/confirm-cross-provider-dnskey-support-before-planning-a-cloudflare-dnssec-preserving-migration/" }, "title": "Confirm cross-provider DNSKEY support before planning a Cloudflare DNSSEC-preserving migration", "summary": "Keeping validation active requires cooperation from the previous provider, not only a nameserver change.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:58+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 251, "potentially_affected": "This concerns the documented Cloudflare migration path that preserves DNSSEC.", "dse_recommendation": "DSE recommends obtaining explicit confirmation of external DNSKEY support from both DNS teams before scheduling the cutover.", "primary_source": { "name": "Cloudflare — DNSSEC migration tutorial", "url": "https://developers.cloudflare.com/dns/dnssec/dnssec-active-migration/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Keeping validation active requires cooperation from the previous provider, not only a nameserver change.
\nCloudflare’s active-DNSSEC migration procedure requires the previous provider to add DNSKEY records at the apex and return them in answers. The workflow cross-imports zone signing keys and checks that both providers return both ZSKs before moving through registrar and provider-removal stages. This is an advanced coordinated migration rather than an ordinary one-step nameserver replacement.
\nSource: Cloudflare — DNSSEC migration tutorial.
\nThis concerns the documented Cloudflare migration path that preserves DNSSEC.
\nDSE recommends obtaining explicit confirmation of external DNSKEY support from both DNS teams before scheduling the cutover. Record current DS records, keys, nameservers, TTLs, and the exact rollback stage. Follow the full provider procedure rather than combining isolated steps from unrelated migrations. Keep the old provider available until the documented trust and delegation transitions have completed and been checked. Give each key-import, DNSKEY-answer, registrar, and provider-removal checkpoint an explicit owner. Preserve the observed key identifiers at every stage. Stop the migration when either provider cannot demonstrate the required shared key set rather than trying to compensate with an early nameserver change.
\nIn a controlled rehearsal or approved migration, query each authoritative provider for the expected DNSKEY set and inspect the registrar DS state at each stage. Validate representative records through trusted validating resolvers. Record completed checkpoints separately and do not remove the old provider simply because the new dashboard shows the zone as configured.
\nCloudflare — DNSSEC migration tutorial. Reviewed October 20, 2026.
", "content_text": "Keeping validation active requires cooperation from the previous provider, not only a nameserver change.\nSource facts\nCloudflare’s active-DNSSEC migration procedure requires the previous provider to add DNSKEY records at the apex and return them in answers. The workflow cross-imports zone signing keys and checks that both providers return both ZSKs before moving through registrar and provider-removal stages. This is an advanced coordinated migration rather than an ordinary one-step nameserver replacement.\nSource: Cloudflare — DNSSEC migration tutorial.\nApplicability\nThis concerns the documented Cloudflare migration path that preserves DNSSEC.\nDSE recommendation\nDSE recommends obtaining explicit confirmation of external DNSKEY support from both DNS teams before scheduling the cutover. Record current DS records, keys, nameservers, TTLs, and the exact rollback stage. Follow the full provider procedure rather than combining isolated steps from unrelated migrations. Keep the old provider available until the documented trust and delegation transitions have completed and been checked. Give each key-import, DNSKEY-answer, registrar, and provider-removal checkpoint an explicit owner. Preserve the observed key identifiers at every stage. Stop the migration when either provider cannot demonstrate the required shared key set rather than trying to compensate with an early nameserver change.\nVerification\nIn a controlled rehearsal or approved migration, query each authoritative provider for the expected DNSKEY set and inspect the registrar DS state at each stage. Validate representative records through trusted validating resolvers. Record completed checkpoints separately and do not remove the old provider simply because the new dashboard shows the zone as configured.\nOfficial reference\nCloudflare — DNSSEC migration tutorial. Reviewed October 20, 2026.", "content_markdown": "Keeping validation active requires cooperation from the previous provider, not only a nameserver change.\n\n## Source facts\n\nCloudflare’s active-DNSSEC migration procedure requires the previous provider to add DNSKEY records at the apex and return them in answers. The workflow cross-imports zone signing keys and checks that both providers return both ZSKs before moving through registrar and provider-removal stages. This is an advanced coordinated migration rather than an ordinary one-step nameserver replacement.\n\nSource: [Cloudflare — DNSSEC migration tutorial](https://developers.cloudflare.com/dns/dnssec/dnssec-active-migration/).\n\n## Applicability\n\nThis concerns the documented Cloudflare migration path that preserves DNSSEC.\n\n## DSE recommendation\n\nDSE recommends obtaining explicit confirmation of external DNSKEY support from both DNS teams before scheduling the cutover. Record current DS records, keys, nameservers, TTLs, and the exact rollback stage. Follow the full provider procedure rather than combining isolated steps from unrelated migrations. Keep the old provider available until the documented trust and delegation transitions have completed and been checked. Give each key-import, DNSKEY-answer, registrar, and provider-removal checkpoint an explicit owner. Preserve the observed key identifiers at every stage. Stop the migration when either provider cannot demonstrate the required shared key set rather than trying to compensate with an early nameserver change.\n\n## Verification\n\nIn a controlled rehearsal or approved migration, query each authoritative provider for the expected DNSKEY set and inspect the registrar DS state at each stage. Validate representative records through trusted validating resolvers. Record completed checkpoints separately and do not remove the old provider simply because the new dashboard shows the zone as configured.\n\n## Official reference\n\n[Cloudflare — DNSSEC migration tutorial](https://developers.cloudflare.com/dns/dnssec/dnssec-active-migration/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/", "slug": "verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard", "url": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard.md", "json": "https://update.dsesecurity.com/api/v1/posts/verify-a-cloudflare-cname-proof-at-the-authoritative-provider-not-only-in-the-dashboard/" }, "title": "Verify a Cloudflare CNAME proof at the authoritative provider, not only in the dashboard", "summary": "Proxying, flattening, or a child delegation can hide the exact alias a third party expects.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:57+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 256, "potentially_affected": "This concerns third-party verification that requires seeing a CNAME answer.", "dse_recommendation": "DSE recommends copying the exact requested owner name and target into the change record before editing.", "primary_source": { "name": "Cloudflare — Cannot verify a domain with CNAME", "url": "https://developers.cloudflare.com/dns/manage-dns-records/troubleshooting/cname-domain-verification/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Proxying, flattening, or a child delegation can hide the exact alias a third party expects.
\nCloudflare lists several causes of failed CNAME domain verification: a proxied record, all-record or per-record flattening, and an NS delegation making another provider authoritative. Its remedy includes keeping the proof DNS-only with flattening off and ensuring the record exists at the nameservers that actually serve the subdomain.
\nSource: Cloudflare — Cannot verify a domain with CNAME.
\nThis concerns third-party verification that requires seeing a CNAME answer.
\nDSE recommends copying the exact requested owner name and target into the change record before editing. Check delegation first, then proxy and flattening settings. Do not remove an NS record casually to make one proof visible; inventory the child services and coordinate any authority change. Preserve existing mail authentication records and verify that a new proof does not collide with another record at the same name. Keep the third party’s requested CNAME value beside the authoritative answer, without substituting an address lookup for the alias check. If the child-zone owner differs, assign the request there before changing proxy settings in the parent. Record provider verification as a separate completion step.
\nQuery the proof’s authoritative nameservers for the CNAME itself and compare the returned target with the provider’s instructions. Repeat from a representative recursive resolver after cache expiry, then run the provider’s verification. Record the visible alias and authority path rather than treating a saved dashboard row as successful validation.
\nCloudflare — Cannot verify a domain with CNAME. Reviewed October 20, 2026.
", "content_text": "Proxying, flattening, or a child delegation can hide the exact alias a third party expects.\nSource facts\nCloudflare lists several causes of failed CNAME domain verification: a proxied record, all-record or per-record flattening, and an NS delegation making another provider authoritative. Its remedy includes keeping the proof DNS-only with flattening off and ensuring the record exists at the nameservers that actually serve the subdomain.\nSource: Cloudflare — Cannot verify a domain with CNAME.\nApplicability\nThis concerns third-party verification that requires seeing a CNAME answer.\nDSE recommendation\nDSE recommends copying the exact requested owner name and target into the change record before editing. Check delegation first, then proxy and flattening settings. Do not remove an NS record casually to make one proof visible; inventory the child services and coordinate any authority change. Preserve existing mail authentication records and verify that a new proof does not collide with another record at the same name. Keep the third party’s requested CNAME value beside the authoritative answer, without substituting an address lookup for the alias check. If the child-zone owner differs, assign the request there before changing proxy settings in the parent. Record provider verification as a separate completion step.\nVerification\nQuery the proof’s authoritative nameservers for the CNAME itself and compare the returned target with the provider’s instructions. Repeat from a representative recursive resolver after cache expiry, then run the provider’s verification. Record the visible alias and authority path rather than treating a saved dashboard row as successful validation.\nOfficial reference\nCloudflare — Cannot verify a domain with CNAME. Reviewed October 20, 2026.", "content_markdown": "Proxying, flattening, or a child delegation can hide the exact alias a third party expects.\n\n## Source facts\n\nCloudflare lists several causes of failed CNAME domain verification: a proxied record, all-record or per-record flattening, and an NS delegation making another provider authoritative. Its remedy includes keeping the proof DNS-only with flattening off and ensuring the record exists at the nameservers that actually serve the subdomain.\n\nSource: [Cloudflare — Cannot verify a domain with CNAME](https://developers.cloudflare.com/dns/manage-dns-records/troubleshooting/cname-domain-verification/).\n\n## Applicability\n\nThis concerns third-party verification that requires seeing a CNAME answer.\n\n## DSE recommendation\n\nDSE recommends copying the exact requested owner name and target into the change record before editing. Check delegation first, then proxy and flattening settings. Do not remove an NS record casually to make one proof visible; inventory the child services and coordinate any authority change. Preserve existing mail authentication records and verify that a new proof does not collide with another record at the same name. Keep the third party’s requested CNAME value beside the authoritative answer, without substituting an address lookup for the alias check. If the child-zone owner differs, assign the request there before changing proxy settings in the parent. Record provider verification as a separate completion step.\n\n## Verification\n\nQuery the proof’s authoritative nameservers for the CNAME itself and compare the returned target with the provider’s instructions. Repeat from a representative recursive resolver after cache expiry, then run the provider’s verification. Record the visible alias and authority path rather than treating a saved dashboard row as successful validation.\n\n## Official reference\n\n[Cloudflare — Cannot verify a domain with CNAME](https://developers.cloudflare.com/dns/manage-dns-records/troubleshooting/cname-domain-verification/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/preserve-cloudflare-proxy-and-record-attributes-when-moving-dns-through-a-zone-file/", "slug": "preserve-cloudflare-proxy-and-record-attributes-when-moving-dns-through-a-zone-file", "url": "https://update.dsesecurity.com/updates/preserve-cloudflare-proxy-and-record-attributes-when-moving-dns-through-a-zone-file/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/preserve-cloudflare-proxy-and-record-attributes-when-moving-dns-through-a-zone-file.md", "json": "https://update.dsesecurity.com/api/v1/posts/preserve-cloudflare-proxy-and-record-attributes-when-moving-dns-through-a-zone-file/" }, "title": "Preserve Cloudflare proxy and record attributes when moving DNS through a zone file", "summary": "A BIND-format import can carry configuration beyond the visible address values.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:56+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 252, "potentially_affected": "This concerns Cloudflare DNS record import/export.", "dse_recommendation": "DSE recommends retaining an untouched export and reviewing a working copy before import.", "primary_source": { "name": "Cloudflare — Import and export records", "url": "https://developers.cloudflare.com/dns/manage-dns-records/how-to/import-and-export/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A BIND-format import can carry configuration beyond the visible address values.
\nCloudflare documents BIND zone-file import and export, with fully qualified targets ending in a period for relevant record types. Imported applicable records can be proxied unless that option is disabled. Comments and tags use inline metadata, including reserved cf- tags that represent Cloudflare-specific settings. An exported file therefore needs more review than a simple list of hostnames and addresses.
\nSource: Cloudflare — Import and export records.
\nThis concerns Cloudflare DNS record import/export.
\nDSE recommends retaining an untouched export and reviewing a working copy before import. Validate target-name qualification, record types, TTLs, and proxy intentions alongside comments and reserved tags. Keep mail and third-party verification records in the review rather than importing only web addresses. Use the narrow permissions needed for the operation and keep API credentials separate from the zone file and change evidence. Keep a comparison column for values and another for Cloudflare-specific attributes. Ask the destination owner to approve proxy intent for mail, proof, and web names individually. Reject a migration comparison that ignores reserved inline tags merely because the visible record targets appear to match.
\nImport a representative file into a controlled zone and compare its records and relevant attributes with the source. Query fully qualified targets to detect accidental suffix expansion. Confirm intended proxy state and dependent web, mail, or verification behavior separately before using the same process for a production migration.
\nCloudflare — Import and export records. Reviewed October 20, 2026.
", "content_text": "A BIND-format import can carry configuration beyond the visible address values.\nSource facts\nCloudflare documents BIND zone-file import and export, with fully qualified targets ending in a period for relevant record types. Imported applicable records can be proxied unless that option is disabled. Comments and tags use inline metadata, including reserved cf- tags that represent Cloudflare-specific settings. An exported file therefore needs more review than a simple list of hostnames and addresses.\nSource: Cloudflare — Import and export records.\nApplicability\nThis concerns Cloudflare DNS record import/export.\nDSE recommendation\nDSE recommends retaining an untouched export and reviewing a working copy before import. Validate target-name qualification, record types, TTLs, and proxy intentions alongside comments and reserved tags. Keep mail and third-party verification records in the review rather than importing only web addresses. Use the narrow permissions needed for the operation and keep API credentials separate from the zone file and change evidence. Keep a comparison column for values and another for Cloudflare-specific attributes. Ask the destination owner to approve proxy intent for mail, proof, and web names individually. Reject a migration comparison that ignores reserved inline tags merely because the visible record targets appear to match.\nVerification\nImport a representative file into a controlled zone and compare its records and relevant attributes with the source. Query fully qualified targets to detect accidental suffix expansion. Confirm intended proxy state and dependent web, mail, or verification behavior separately before using the same process for a production migration.\nOfficial reference\nCloudflare — Import and export records. Reviewed October 20, 2026.", "content_markdown": "A BIND-format import can carry configuration beyond the visible address values.\n\n## Source facts\n\nCloudflare documents BIND zone-file import and export, with fully qualified targets ending in a period for relevant record types. Imported applicable records can be proxied unless that option is disabled. Comments and tags use inline metadata, including reserved cf- tags that represent Cloudflare-specific settings. An exported file therefore needs more review than a simple list of hostnames and addresses.\n\nSource: [Cloudflare — Import and export records](https://developers.cloudflare.com/dns/manage-dns-records/how-to/import-and-export/).\n\n## Applicability\n\nThis concerns Cloudflare DNS record import/export.\n\n## DSE recommendation\n\nDSE recommends retaining an untouched export and reviewing a working copy before import. Validate target-name qualification, record types, TTLs, and proxy intentions alongside comments and reserved tags. Keep mail and third-party verification records in the review rather than importing only web addresses. Use the narrow permissions needed for the operation and keep API credentials separate from the zone file and change evidence. Keep a comparison column for values and another for Cloudflare-specific attributes. Ask the destination owner to approve proxy intent for mail, proof, and web names individually. Reject a migration comparison that ignores reserved inline tags merely because the visible record targets appear to match.\n\n## Verification\n\nImport a representative file into a controlled zone and compare its records and relevant attributes with the source. Query fully qualified targets to detect accidental suffix expansion. Confirm intended proxy state and dependent web, mail, or verification behavior separately before using the same process for a production migration.\n\n## Official reference\n\n[Cloudflare — Import and export records](https://developers.cloudflare.com/dns/manage-dns-records/how-to/import-and-export/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/do-not-treat-a-cloudflare-dns-batch-transaction-as-atomic-global-propagation/", "slug": "do-not-treat-a-cloudflare-dns-batch-transaction-as-atomic-global-propagation", "url": "https://update.dsesecurity.com/updates/do-not-treat-a-cloudflare-dns-batch-transaction-as-atomic-global-propagation/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/do-not-treat-a-cloudflare-dns-batch-transaction-as-atomic-global-propagation.md", "json": "https://update.dsesecurity.com/api/v1/posts/do-not-treat-a-cloudflare-dns-batch-transaction-as-atomic-global-propagation/" }, "title": "Do not treat a Cloudflare DNS batch transaction as atomic global propagation", "summary": "A successful database transaction can still reach the distributed DNS layer record by record.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:55+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 260, "potentially_affected": "This concerns the Cloudflare batch-record API and its documented commit and propagation semantics.", "dse_recommendation": "DSE recommends designing coordinated record changes to tolerate a transition with mixed old and new answers.", "primary_source": { "name": "Cloudflare — Batch record changes", "url": "https://developers.cloudflare.com/dns/manage-dns-records/how-to/batch-record-changes/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A successful database transaction can still reach the distributed DNS layer record by record.
\nCloudflare states that a DNS batch executes in one database transaction, while propagation through its distributed key-value system is not atomic. Batch operations run in delete, patch, put, then post order. Patches preserve unspecified fields; puts reset unspecified fields to their defaults. A failed operation prevents the database changes and returns the first error.
\nSource: Cloudflare — Batch record changes.
\nThis concerns the Cloudflare batch-record API and its documented commit and propagation semantics.
\nDSE recommends designing coordinated record changes to tolerate a transition with mixed old and new answers. Use patch versus replacement semantics intentionally and preserve an export of the prior records. Review operation order where names or record types conflict. Keep the batch small enough to inspect and match it to an approved change set rather than relying on a single success response as the full acceptance evidence. Ask the application owner to approve a mixed-answer transition before submitting the batch. Include operation order and patch-versus-put intent in the reviewed request description. Keep rollback values for each affected record so a successful database transaction is not mistaken for a service-wide atomic cutover.
\nIn a controlled zone, apply a representative batch and inspect returned results, stored fields, and authoritative answers over time. Confirm unspecified settings stayed unchanged for patches and match intended defaults for replacements. Test the dependent service during the transition and retain the exact before-and-after records without exposing API credentials.
\nCloudflare — Batch record changes. Reviewed October 20, 2026.
", "content_text": "A successful database transaction can still reach the distributed DNS layer record by record.\nSource facts\nCloudflare states that a DNS batch executes in one database transaction, while propagation through its distributed key-value system is not atomic. Batch operations run in delete, patch, put, then post order. Patches preserve unspecified fields; puts reset unspecified fields to their defaults. A failed operation prevents the database changes and returns the first error.\nSource: Cloudflare — Batch record changes.\nApplicability\nThis concerns the Cloudflare batch-record API and its documented commit and propagation semantics.\nDSE recommendation\nDSE recommends designing coordinated record changes to tolerate a transition with mixed old and new answers. Use patch versus replacement semantics intentionally and preserve an export of the prior records. Review operation order where names or record types conflict. Keep the batch small enough to inspect and match it to an approved change set rather than relying on a single success response as the full acceptance evidence. Ask the application owner to approve a mixed-answer transition before submitting the batch. Include operation order and patch-versus-put intent in the reviewed request description. Keep rollback values for each affected record so a successful database transaction is not mistaken for a service-wide atomic cutover.\nVerification\nIn a controlled zone, apply a representative batch and inspect returned results, stored fields, and authoritative answers over time. Confirm unspecified settings stayed unchanged for patches and match intended defaults for replacements. Test the dependent service during the transition and retain the exact before-and-after records without exposing API credentials.\nOfficial reference\nCloudflare — Batch record changes. Reviewed October 20, 2026.", "content_markdown": "A successful database transaction can still reach the distributed DNS layer record by record.\n\n## Source facts\n\nCloudflare states that a DNS batch executes in one database transaction, while propagation through its distributed key-value system is not atomic. Batch operations run in delete, patch, put, then post order. Patches preserve unspecified fields; puts reset unspecified fields to their defaults. A failed operation prevents the database changes and returns the first error.\n\nSource: [Cloudflare — Batch record changes](https://developers.cloudflare.com/dns/manage-dns-records/how-to/batch-record-changes/).\n\n## Applicability\n\nThis concerns the Cloudflare batch-record API and its documented commit and propagation semantics.\n\n## DSE recommendation\n\nDSE recommends designing coordinated record changes to tolerate a transition with mixed old and new answers. Use patch versus replacement semantics intentionally and preserve an export of the prior records. Review operation order where names or record types conflict. Keep the batch small enough to inspect and match it to an approved change set rather than relying on a single success response as the full acceptance evidence. Ask the application owner to approve a mixed-answer transition before submitting the batch. Include operation order and patch-versus-put intent in the reviewed request description. Keep rollback values for each affected record so a successful database transaction is not mistaken for a service-wide atomic cutover.\n\n## Verification\n\nIn a controlled zone, apply a representative batch and inspect returned results, stored fields, and authoritative answers over time. Confirm unspecified settings stayed unchanged for patches and match intended defaults for replacements. Test the dependent service during the transition and retain the exact before-and-after records without exposing API credentials.\n\n## Official reference\n\n[Cloudflare — Batch record changes](https://developers.cloudflare.com/dns/manage-dns-records/how-to/batch-record-changes/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/find-cloudflare-records-shadowed-by-a-subdomain-delegation-before-editing-their-values/", "slug": "find-cloudflare-records-shadowed-by-a-subdomain-delegation-before-editing-their-values", "url": "https://update.dsesecurity.com/updates/find-cloudflare-records-shadowed-by-a-subdomain-delegation-before-editing-their-values/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/find-cloudflare-records-shadowed-by-a-subdomain-delegation-before-editing-their-values.md", "json": "https://update.dsesecurity.com/api/v1/posts/find-cloudflare-records-shadowed-by-a-subdomain-delegation-before-editing-their-values/" }, "title": "Find Cloudflare records shadowed by a subdomain delegation before editing their values", "summary": "A record can remain visible in the parent zone while another nameserver set is authoritative for it.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:54+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 266, "potentially_affected": "This concerns Cloudflare delegation diagnostics and shadow metadata.", "dse_recommendation": "DSE recommends checking the authoritative boundary before changing an apparently ineffective address.", "primary_source": { "name": "Cloudflare — Shadowed records", "url": "https://developers.cloudflare.com/dns/manage-dns-records/reference/shadowed-records/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A record can remain visible in the parent zone while another nameserver set is authoritative for it.
\nCloudflare documents that an NS delegation moves authority for the delegated name and its descendants. Records retained at or below that point can be shadowed even though they still appear in the zone. Shadow metadata identifies the affected records and delegations when requested. Required in-zone A/AAAA glue is a special case and can still be served in referral responses.
\nSource: Cloudflare — Shadowed records.
\nThis concerns Cloudflare delegation diagnostics and shadow metadata.
\nDSE recommends checking the authoritative boundary before changing an apparently ineffective address. Locate the child zone owner and edit the record at the nameservers that actually serve it. Preserve required glue and document any stale parent copies for controlled cleanup. Treat a newly added NS delegation as an impact change for every descendant record, not just the visible NS row. Have the parent and child DNS owners review the same authority diagram before cleaning up retained rows. Mark each candidate deletion as obsolete data or required glue, with an owner for the classification. Keep a referral trace so the reason for editing the child rather than the parent remains reproducible.
\nTrace an approved hostname through the delegation and compare the parent’s stored row with the child’s authoritative answer. Request the relevant shadow metadata and inspect any glue dependency. Confirm the final answer comes from the intended authority, then verify the application without using repeated parent-zone edits as a substitute for fixing the delegation boundary.
\nCloudflare — Shadowed records. Reviewed October 20, 2026.
", "content_text": "A record can remain visible in the parent zone while another nameserver set is authoritative for it.\nSource facts\nCloudflare documents that an NS delegation moves authority for the delegated name and its descendants. Records retained at or below that point can be shadowed even though they still appear in the zone. Shadow metadata identifies the affected records and delegations when requested. Required in-zone A/AAAA glue is a special case and can still be served in referral responses.\nSource: Cloudflare — Shadowed records.\nApplicability\nThis concerns Cloudflare delegation diagnostics and shadow metadata.\nDSE recommendation\nDSE recommends checking the authoritative boundary before changing an apparently ineffective address. Locate the child zone owner and edit the record at the nameservers that actually serve it. Preserve required glue and document any stale parent copies for controlled cleanup. Treat a newly added NS delegation as an impact change for every descendant record, not just the visible NS row. Have the parent and child DNS owners review the same authority diagram before cleaning up retained rows. Mark each candidate deletion as obsolete data or required glue, with an owner for the classification. Keep a referral trace so the reason for editing the child rather than the parent remains reproducible.\nVerification\nTrace an approved hostname through the delegation and compare the parent’s stored row with the child’s authoritative answer. Request the relevant shadow metadata and inspect any glue dependency. Confirm the final answer comes from the intended authority, then verify the application without using repeated parent-zone edits as a substitute for fixing the delegation boundary.\nOfficial reference\nCloudflare — Shadowed records. Reviewed October 20, 2026.", "content_markdown": "A record can remain visible in the parent zone while another nameserver set is authoritative for it.\n\n## Source facts\n\nCloudflare documents that an NS delegation moves authority for the delegated name and its descendants. Records retained at or below that point can be shadowed even though they still appear in the zone. Shadow metadata identifies the affected records and delegations when requested. Required in-zone A/AAAA glue is a special case and can still be served in referral responses.\n\nSource: [Cloudflare — Shadowed records](https://developers.cloudflare.com/dns/manage-dns-records/reference/shadowed-records/).\n\n## Applicability\n\nThis concerns Cloudflare delegation diagnostics and shadow metadata.\n\n## DSE recommendation\n\nDSE recommends checking the authoritative boundary before changing an apparently ineffective address. Locate the child zone owner and edit the record at the nameservers that actually serve it. Preserve required glue and document any stale parent copies for controlled cleanup. Treat a newly added NS delegation as an impact change for every descendant record, not just the visible NS row. Have the parent and child DNS owners review the same authority diagram before cleaning up retained rows. Mark each candidate deletion as obsolete data or required glue, with an owner for the classification. Keep a referral trace so the reason for editing the child rather than the parent remains reproducible.\n\n## Verification\n\nTrace an approved hostname through the delegation and compare the parent’s stored row with the child’s authoritative answer. Request the relevant shadow metadata and inspect any glue dependency. Confirm the final answer comes from the intended authority, then verify the application without using repeated parent-zone edits as a substitute for fixing the delegation boundary.\n\n## Official reference\n\n[Cloudflare — Shadowed records](https://developers.cloudflare.com/dns/manage-dns-records/reference/shadowed-records/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/separate-cloudflare-record-ttl-from-nameserver-delegation-ttl-during-a-dns-change/", "slug": "separate-cloudflare-record-ttl-from-nameserver-delegation-ttl-during-a-dns-change", "url": "https://update.dsesecurity.com/updates/separate-cloudflare-record-ttl-from-nameserver-delegation-ttl-during-a-dns-change/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/separate-cloudflare-record-ttl-from-nameserver-delegation-ttl-during-a-dns-change.md", "json": "https://update.dsesecurity.com/api/v1/posts/separate-cloudflare-record-ttl-from-nameserver-delegation-ttl-during-a-dns-change/" }, "title": "Separate Cloudflare record TTL from nameserver delegation TTL during a DNS change", "summary": "Changing one caching interval does not necessarily shorten every layer of the lookup path.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:53+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 254, "potentially_affected": "This concerns Cloudflare TTL controls and caching boundaries.", "dse_recommendation": "DSE recommends documenting whether the change affects an address, proxy status, or delegation before planning the window.", "primary_source": { "name": "Cloudflare — Time to Live (TTL)", "url": "https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Changing one caching interval does not necessarily shorten every layer of the lookup path.
\nCloudflare distinguishes ordinary DNS record TTL from nameserver TTL. Proxied records use the service’s fixed Auto TTL, while DNS-only records allow a configurable range that depends on plan. The guide notes local caching can make observed changes take longer than the advertised proxied TTL and that nameserver TTL is a separate feature.
\nSource: Cloudflare — Time to Live (TTL).
\nThis concerns Cloudflare TTL controls and caching boundaries.
\nDSE recommends documenting whether the change affects an address, proxy status, or delegation before planning the window. Capture the current authoritative TTL and allow existing cached answers to age out when reducing a value. Keep old and new endpoints viable for the expected transition where possible. Avoid repeatedly changing the record because one client still shows an older result; first identify which resolver or local cache supplied it. Write the transition plan as separate address-record and delegation observations, with the queried authority shown for each. Ask the operator to retain one old-answer sample before cutover. Keep overlap availability decisions tied to the service requirement rather than a promised universal propagation deadline.
\nCompare authoritative answers with selected recursive and local resolver observations, recording TTLs and timestamps. Check delegation data separately when nameservers changed. Confirm the application works through both expected transition paths, and report actual observations rather than promising that every user will switch at the exact configured TTL boundary.
\nCloudflare — Time to Live (TTL). Reviewed October 20, 2026.
", "content_text": "Changing one caching interval does not necessarily shorten every layer of the lookup path.\nSource facts\nCloudflare distinguishes ordinary DNS record TTL from nameserver TTL. Proxied records use the service’s fixed Auto TTL, while DNS-only records allow a configurable range that depends on plan. The guide notes local caching can make observed changes take longer than the advertised proxied TTL and that nameserver TTL is a separate feature.\nSource: Cloudflare — Time to Live (TTL).\nApplicability\nThis concerns Cloudflare TTL controls and caching boundaries.\nDSE recommendation\nDSE recommends documenting whether the change affects an address, proxy status, or delegation before planning the window. Capture the current authoritative TTL and allow existing cached answers to age out when reducing a value. Keep old and new endpoints viable for the expected transition where possible. Avoid repeatedly changing the record because one client still shows an older result; first identify which resolver or local cache supplied it. Write the transition plan as separate address-record and delegation observations, with the queried authority shown for each. Ask the operator to retain one old-answer sample before cutover. Keep overlap availability decisions tied to the service requirement rather than a promised universal propagation deadline.\nVerification\nCompare authoritative answers with selected recursive and local resolver observations, recording TTLs and timestamps. Check delegation data separately when nameservers changed. Confirm the application works through both expected transition paths, and report actual observations rather than promising that every user will switch at the exact configured TTL boundary.\nOfficial reference\nCloudflare — Time to Live (TTL). Reviewed October 20, 2026.", "content_markdown": "Changing one caching interval does not necessarily shorten every layer of the lookup path.\n\n## Source facts\n\nCloudflare distinguishes ordinary DNS record TTL from nameserver TTL. Proxied records use the service’s fixed Auto TTL, while DNS-only records allow a configurable range that depends on plan. The guide notes local caching can make observed changes take longer than the advertised proxied TTL and that nameserver TTL is a separate feature.\n\nSource: [Cloudflare — Time to Live (TTL)](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/).\n\n## Applicability\n\nThis concerns Cloudflare TTL controls and caching boundaries.\n\n## DSE recommendation\n\nDSE recommends documenting whether the change affects an address, proxy status, or delegation before planning the window. Capture the current authoritative TTL and allow existing cached answers to age out when reducing a value. Keep old and new endpoints viable for the expected transition where possible. Avoid repeatedly changing the record because one client still shows an older result; first identify which resolver or local cache supplied it. Write the transition plan as separate address-record and delegation observations, with the queried authority shown for each. Ask the operator to retain one old-answer sample before cutover. Keep overlap availability decisions tied to the service requirement rather than a promised universal propagation deadline.\n\n## Verification\n\nCompare authoritative answers with selected recursive and local resolver observations, recording TTLs and timestamps. Check delegation data separately when nameservers changed. Confirm the application works through both expected transition paths, and report actual observations rather than promising that every user will switch at the exact configured TTL boundary.\n\n## Official reference\n\n[Cloudflare — Time to Live (TTL)](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/do-not-delete-a-cloudflare-total-tls-certificate-as-a-routine-renewal-reset/", "slug": "do-not-delete-a-cloudflare-total-tls-certificate-as-a-routine-renewal-reset", "url": "https://update.dsesecurity.com/updates/do-not-delete-a-cloudflare-total-tls-certificate-as-a-routine-renewal-reset/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/do-not-delete-a-cloudflare-total-tls-certificate-as-a-routine-renewal-reset.md", "json": "https://update.dsesecurity.com/api/v1/posts/do-not-delete-a-cloudflare-total-tls-certificate-as-a-routine-renewal-reset/" }, "title": "Do not delete a Cloudflare Total TLS certificate as a routine renewal reset", "summary": "Deletion can opt that hostname out of future automatic Total TLS orders.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:52+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 258, "potentially_affected": "This concerns the documented Total TLS feature, which requires Advanced Certificate Manager and full DNS setup.", "dse_recommendation": "DSE recommends identifying the certificate type and hostname eligibility before attempting a cleanup or repair.", "primary_source": { "name": "Cloudflare — Total TLS", "url": "https://developers.cloudflare.com/ssl/edge-certificates/additional-options/total-tls/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Deletion can opt that hostname out of future automatic Total TLS orders.
\nCloudflare states that deleting a Total TLS certificate associated with a proxied hostname is interpreted as opting the hostname out, and no new Total TLS certificate is ordered for it. Deleting and recreating the DNS record does not reverse that behavior. The guide also excludes hostnames used with Tunnel, Load Balancing, and Spectrum from Total TLS issuance.
\nSource: Cloudflare — Total TLS.
\nThis concerns the documented Total TLS feature, which requires Advanced Certificate Manager and full DNS setup.
\nDSE recommends identifying the certificate type and hostname eligibility before attempting a cleanup or repair. Preserve metadata for the affected hostname and use the supported troubleshooting path instead of deleting the certificate speculatively. Maintain explicit certificate coverage for excluded product hostnames. Include the opt-out consequence in change review so a cosmetic dashboard cleanup does not become a later expiry incident. Add certificate deletion to the list of changes requiring an issuance-impact review. Ask the operator to name the replacement coverage before approving removal. Keep excluded-product hostnames in a separate certificate inventory with their actual issuer, rather than assuming the zone-wide Total TLS setting covers them.
\nInspect the active certificate type and SAN coverage for each intended hostname, then verify the visitor-facing certificate with normal trust checks. In a test environment, follow the documented recovery process for any intentionally opted-out name. Record the resulting issuance state and avoid claiming that recreating DNS alone restores automatic certificate management.
\nCloudflare — Total TLS. Reviewed October 20, 2026.
", "content_text": "Deletion can opt that hostname out of future automatic Total TLS orders.\nSource facts\nCloudflare states that deleting a Total TLS certificate associated with a proxied hostname is interpreted as opting the hostname out, and no new Total TLS certificate is ordered for it. Deleting and recreating the DNS record does not reverse that behavior. The guide also excludes hostnames used with Tunnel, Load Balancing, and Spectrum from Total TLS issuance.\nSource: Cloudflare — Total TLS.\nApplicability\nThis concerns the documented Total TLS feature, which requires Advanced Certificate Manager and full DNS setup.\nDSE recommendation\nDSE recommends identifying the certificate type and hostname eligibility before attempting a cleanup or repair. Preserve metadata for the affected hostname and use the supported troubleshooting path instead of deleting the certificate speculatively. Maintain explicit certificate coverage for excluded product hostnames. Include the opt-out consequence in change review so a cosmetic dashboard cleanup does not become a later expiry incident. Add certificate deletion to the list of changes requiring an issuance-impact review. Ask the operator to name the replacement coverage before approving removal. Keep excluded-product hostnames in a separate certificate inventory with their actual issuer, rather than assuming the zone-wide Total TLS setting covers them.\nVerification\nInspect the active certificate type and SAN coverage for each intended hostname, then verify the visitor-facing certificate with normal trust checks. In a test environment, follow the documented recovery process for any intentionally opted-out name. Record the resulting issuance state and avoid claiming that recreating DNS alone restores automatic certificate management.\nOfficial reference\nCloudflare — Total TLS. Reviewed October 20, 2026.", "content_markdown": "Deletion can opt that hostname out of future automatic Total TLS orders.\n\n## Source facts\n\nCloudflare states that deleting a Total TLS certificate associated with a proxied hostname is interpreted as opting the hostname out, and no new Total TLS certificate is ordered for it. Deleting and recreating the DNS record does not reverse that behavior. The guide also excludes hostnames used with Tunnel, Load Balancing, and Spectrum from Total TLS issuance.\n\nSource: [Cloudflare — Total TLS](https://developers.cloudflare.com/ssl/edge-certificates/additional-options/total-tls/).\n\n## Applicability\n\nThis concerns the documented Total TLS feature, which requires Advanced Certificate Manager and full DNS setup.\n\n## DSE recommendation\n\nDSE recommends identifying the certificate type and hostname eligibility before attempting a cleanup or repair. Preserve metadata for the affected hostname and use the supported troubleshooting path instead of deleting the certificate speculatively. Maintain explicit certificate coverage for excluded product hostnames. Include the opt-out consequence in change review so a cosmetic dashboard cleanup does not become a later expiry incident. Add certificate deletion to the list of changes requiring an issuance-impact review. Ask the operator to name the replacement coverage before approving removal. Keep excluded-product hostnames in a separate certificate inventory with their actual issuer, rather than assuming the zone-wide Total TLS setting covers them.\n\n## Verification\n\nInspect the active certificate type and SAN coverage for each intended hostname, then verify the visitor-facing certificate with normal trust checks. In a test environment, follow the documented recovery process for any intentionally opted-out name. Record the resulting issuance state and avoid claiming that recreating DNS alone restores automatic certificate management.\n\n## Official reference\n\n[Cloudflare — Total TLS](https://developers.cloudflare.com/ssl/edge-certificates/additional-options/total-tls/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/", "slug": "check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare", "url": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare.md", "json": "https://update.dsesecurity.com/api/v1/posts/check-connection-bound-windows-authentication-before-proxying-an-intranet-through-cloudflare/" }, "title": "Check connection-bound Windows authentication before proxying an intranet through Cloudflare", "summary": "NTLM and Kerberos assumptions can cause repeated prompts when requests do not retain one origin connection.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:51+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 254, "potentially_affected": "This concerns the ordinary Cloudflare HTTP proxy described in the source.", "dse_recommendation": "DSE recommends inventorying the application's authentication mechanism before changing proxy status.", "primary_source": { "name": "Cloudflare — Proxying limitations", "url": "https://developers.cloudflare.com/dns/proxy-status/limitations/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "NTLM and Kerberos assumptions can cause repeated prompts when requests do not retain one origin connection.
\nCloudflare documents that Microsoft Integrated Windows Authentication, NTLM, and Kerberos are not compatible with its proxied DNS records. The explanation notes NTLM’s TCP-connection-level authentication and that consecutive client requests are not guaranteed to reuse one TCP connection to the origin. Repeated prompts or authentication loops can result.
\nSource: Cloudflare — Proxying limitations.
\nThis concerns the ordinary Cloudflare HTTP proxy described in the source.
\nDSE recommends inventorying the application’s authentication mechanism before changing proxy status. Separate modern browser sign-in or application authentication from legacy connection-bound negotiation. Select a supported access design with the application and identity owners rather than disabling authentication to remove a prompt loop. Keep a restricted recovery path and document how direct origin exposure is controlled if a DNS-only service is part of the approved design. Require the identity owner to identify the actual negotiation method from sanitized evidence before the proxy change. Test a multi-request application workflow, not only its initial landing page. Keep any alternate access plan subject to the same authorization requirement instead of using anonymous access as a diagnostic shortcut.
\nIn a nonproduction deployment, test representative users across fresh sessions, repeated requests, and relevant browsers. Inspect the authentication exchange and origin behavior without collecting credentials. Confirm the selected design supports the intended login mechanism before production cutover, and record prompt loops as observations rather than assuming a bad user password.
\nCloudflare — Proxying limitations. Reviewed October 20, 2026.
", "content_text": "NTLM and Kerberos assumptions can cause repeated prompts when requests do not retain one origin connection.\nSource facts\nCloudflare documents that Microsoft Integrated Windows Authentication, NTLM, and Kerberos are not compatible with its proxied DNS records. The explanation notes NTLM’s TCP-connection-level authentication and that consecutive client requests are not guaranteed to reuse one TCP connection to the origin. Repeated prompts or authentication loops can result.\nSource: Cloudflare — Proxying limitations.\nApplicability\nThis concerns the ordinary Cloudflare HTTP proxy described in the source.\nDSE recommendation\nDSE recommends inventorying the application’s authentication mechanism before changing proxy status. Separate modern browser sign-in or application authentication from legacy connection-bound negotiation. Select a supported access design with the application and identity owners rather than disabling authentication to remove a prompt loop. Keep a restricted recovery path and document how direct origin exposure is controlled if a DNS-only service is part of the approved design. Require the identity owner to identify the actual negotiation method from sanitized evidence before the proxy change. Test a multi-request application workflow, not only its initial landing page. Keep any alternate access plan subject to the same authorization requirement instead of using anonymous access as a diagnostic shortcut.\nVerification\nIn a nonproduction deployment, test representative users across fresh sessions, repeated requests, and relevant browsers. Inspect the authentication exchange and origin behavior without collecting credentials. Confirm the selected design supports the intended login mechanism before production cutover, and record prompt loops as observations rather than assuming a bad user password.\nOfficial reference\nCloudflare — Proxying limitations. Reviewed October 20, 2026.", "content_markdown": "NTLM and Kerberos assumptions can cause repeated prompts when requests do not retain one origin connection.\n\n## Source facts\n\nCloudflare documents that Microsoft Integrated Windows Authentication, NTLM, and Kerberos are not compatible with its proxied DNS records. The explanation notes NTLM’s TCP-connection-level authentication and that consecutive client requests are not guaranteed to reuse one TCP connection to the origin. Repeated prompts or authentication loops can result.\n\nSource: [Cloudflare — Proxying limitations](https://developers.cloudflare.com/dns/proxy-status/limitations/).\n\n## Applicability\n\nThis concerns the ordinary Cloudflare HTTP proxy described in the source.\n\n## DSE recommendation\n\nDSE recommends inventorying the application’s authentication mechanism before changing proxy status. Separate modern browser sign-in or application authentication from legacy connection-bound negotiation. Select a supported access design with the application and identity owners rather than disabling authentication to remove a prompt loop. Keep a restricted recovery path and document how direct origin exposure is controlled if a DNS-only service is part of the approved design. Require the identity owner to identify the actual negotiation method from sanitized evidence before the proxy change. Test a multi-request application workflow, not only its initial landing page. Keep any alternate access plan subject to the same authorization requirement instead of using anonymous access as a diagnostic shortcut.\n\n## Verification\n\nIn a nonproduction deployment, test representative users across fresh sessions, repeated requests, and relevant browsers. Inspect the authentication exchange and origin behavior without collecting credentials. Confirm the selected design supports the intended login mechanism before production cutover, and record prompt loops as observations rather than assuming a bad user password.\n\n## Official reference\n\n[Cloudflare — Proxying limitations](https://developers.cloudflare.com/dns/proxy-status/limitations/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/do-not-mix-proxied-and-dns-only-addresses-on-one-cloudflare-hostname-expecting-split-behavior/", "slug": "do-not-mix-proxied-and-dns-only-addresses-on-one-cloudflare-hostname-expecting-split-behavior", "url": "https://update.dsesecurity.com/updates/do-not-mix-proxied-and-dns-only-addresses-on-one-cloudflare-hostname-expecting-split-behavior/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/do-not-mix-proxied-and-dns-only-addresses-on-one-cloudflare-hostname-expecting-split-behavior.md", "json": "https://update.dsesecurity.com/api/v1/posts/do-not-mix-proxied-and-dns-only-addresses-on-one-cloudflare-hostname-expecting-split-behavior/" }, "title": "Do not mix proxied and DNS-only addresses on one Cloudflare hostname expecting split behavior", "summary": "A proxied member changes how Cloudflare treats the address set for that name.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:50+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 259, "potentially_affected": "This concerns Cloudflare DNS proxy status for a shared hostname.", "dse_recommendation": "DSE recommends defining the intended traffic path at the hostname level before adding a second address.", "primary_source": { "name": "Cloudflare — Proxy status", "url": "https://developers.cloudflare.com/dns/proxy-status/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A proxied member changes how Cloudflare treats the address set for that name.
\nCloudflare states that when a name has several A or AAAA records and at least one is proxied, all A/AAAA records on that name are treated as proxied. A proxied answer uses Cloudflare addresses rather than directly exposing each configured origin. DNS-only answers instead return the actual origin addresses and do not route the resulting HTTP traffic through Cloudflare’s proxy.
\nSource: Cloudflare — Proxy status.
\nThis concerns Cloudflare DNS proxy status for a shared hostname.
\nDSE recommends defining the intended traffic path at the hostname level before adding a second address. Use separate names or an appropriate supported traffic-management design when the services need genuinely different proxy behavior. Review certificates, origin reachability, and application controls for the selected path. Do not label one row DNS-only in an inventory and assume that row will produce direct access while another row for the same name is proxied. Review every A and AAAA row for the name together, with the intended application path written once for the set. Ask the service owner to identify any required direct endpoint separately. Test both address families where configured before accepting the hostname-level proxy decision.
\nQuery the hostname through authoritative and representative recursive resolvers and inspect the returned addresses. Request the intended application and correlate the actual origin path with its logs. Confirm the entire record set behaves as designed before treating a second address as a distinct direct-access endpoint.
\nCloudflare — Proxy status. Reviewed October 20, 2026.
", "content_text": "A proxied member changes how Cloudflare treats the address set for that name.\nSource facts\nCloudflare states that when a name has several A or AAAA records and at least one is proxied, all A/AAAA records on that name are treated as proxied. A proxied answer uses Cloudflare addresses rather than directly exposing each configured origin. DNS-only answers instead return the actual origin addresses and do not route the resulting HTTP traffic through Cloudflare’s proxy.\nSource: Cloudflare — Proxy status.\nApplicability\nThis concerns Cloudflare DNS proxy status for a shared hostname.\nDSE recommendation\nDSE recommends defining the intended traffic path at the hostname level before adding a second address. Use separate names or an appropriate supported traffic-management design when the services need genuinely different proxy behavior. Review certificates, origin reachability, and application controls for the selected path. Do not label one row DNS-only in an inventory and assume that row will produce direct access while another row for the same name is proxied. Review every A and AAAA row for the name together, with the intended application path written once for the set. Ask the service owner to identify any required direct endpoint separately. Test both address families where configured before accepting the hostname-level proxy decision.\nVerification\nQuery the hostname through authoritative and representative recursive resolvers and inspect the returned addresses. Request the intended application and correlate the actual origin path with its logs. Confirm the entire record set behaves as designed before treating a second address as a distinct direct-access endpoint.\nOfficial reference\nCloudflare — Proxy status. Reviewed October 20, 2026.", "content_markdown": "A proxied member changes how Cloudflare treats the address set for that name.\n\n## Source facts\n\nCloudflare states that when a name has several A or AAAA records and at least one is proxied, all A/AAAA records on that name are treated as proxied. A proxied answer uses Cloudflare addresses rather than directly exposing each configured origin. DNS-only answers instead return the actual origin addresses and do not route the resulting HTTP traffic through Cloudflare’s proxy.\n\nSource: [Cloudflare — Proxy status](https://developers.cloudflare.com/dns/proxy-status/).\n\n## Applicability\n\nThis concerns Cloudflare DNS proxy status for a shared hostname.\n\n## DSE recommendation\n\nDSE recommends defining the intended traffic path at the hostname level before adding a second address. Use separate names or an appropriate supported traffic-management design when the services need genuinely different proxy behavior. Review certificates, origin reachability, and application controls for the selected path. Do not label one row DNS-only in an inventory and assume that row will produce direct access while another row for the same name is proxied. Review every A and AAAA row for the name together, with the intended application path written once for the set. Ask the service owner to identify any required direct endpoint separately. Test both address families where configured before accepting the hostname-level proxy decision.\n\n## Verification\n\nQuery the hostname through authoritative and representative recursive resolvers and inspect the returned addresses. Request the intended application and correlate the actual origin path with its logs. Confirm the entire record set behaves as designed before treating a second address as a distinct direct-access endpoint.\n\n## Official reference\n\n[Cloudflare — Proxy status](https://developers.cloudflare.com/dns/proxy-status/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/exclude-order-sensitive-application-urls-from-cloudflare-query-string-sort/", "slug": "exclude-order-sensitive-application-urls-from-cloudflare-query-string-sort", "url": "https://update.dsesecurity.com/updates/exclude-order-sensitive-application-urls-from-cloudflare-query-string-sort/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/exclude-order-sensitive-application-urls-from-cloudflare-query-string-sort.md", "json": "https://update.dsesecurity.com/api/v1/posts/exclude-order-sensitive-application-urls-from-cloudflare-query-string-sort/" }, "title": "Exclude order-sensitive application URLs from Cloudflare Query String Sort", "summary": "Repeated parameters can carry meaning in their original sequence.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:49+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 244, "potentially_affected": "This concerns Cloudflare query sorting.", "dse_recommendation": "DSE recommends identifying routes whose parameter order affects signatures, script dependencies, or application processing before enabling sorting broadly.", "primary_source": { "name": "Cloudflare — Query String Sort", "url": "https://developers.cloudflare.com/cache/advanced-configuration/query-string-sort/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Repeated parameters can carry meaning in their original sequence.
\nCloudflare documents Query String Sort as normalizing query ordering for cache lookup, including sorting repeated parameter names by value. Applications requiring exact order can behave unexpectedly. Its WordPress example concerns ordered script parameters, while the guide notes newer WordPress versions may include a relevant fix; the behavior must therefore be checked against the installed application.
\nSource: Cloudflare — Query String Sort.
\nThis concerns Cloudflare query sorting.
\nDSE recommends identifying routes whose parameter order affects signatures, script dependencies, or application processing before enabling sorting broadly. Apply the feature only to URL classes where equivalence is established, using a scoped rule when appropriate. Keep administration and authenticated workflows in the acceptance set. Do not interpret improved hit rate as sufficient justification if the origin receives a semantically different request. Ask application owners for one order-sensitive example rather than assuming all query permutations are equivalent. Preserve both the incoming sequence and the origin-observed sequence in the pilot. Make an unexplained content or action difference a reason to exclude that route from sorting.
\nIn a controlled test, compare the original and reordered forms of representative queries, including duplicate parameter names. Inspect the origin request and returned content or application action. Exercise affected administrative functions and signed URLs where present, then retain the scoped exclusions and observed results instead of relying on a historical WordPress example alone.
\nCloudflare — Query String Sort. Reviewed October 20, 2026.
", "content_text": "Repeated parameters can carry meaning in their original sequence.\nSource facts\nCloudflare documents Query String Sort as normalizing query ordering for cache lookup, including sorting repeated parameter names by value. Applications requiring exact order can behave unexpectedly. Its WordPress example concerns ordered script parameters, while the guide notes newer WordPress versions may include a relevant fix; the behavior must therefore be checked against the installed application.\nSource: Cloudflare — Query String Sort.\nApplicability\nThis concerns Cloudflare query sorting.\nDSE recommendation\nDSE recommends identifying routes whose parameter order affects signatures, script dependencies, or application processing before enabling sorting broadly. Apply the feature only to URL classes where equivalence is established, using a scoped rule when appropriate. Keep administration and authenticated workflows in the acceptance set. Do not interpret improved hit rate as sufficient justification if the origin receives a semantically different request. Ask application owners for one order-sensitive example rather than assuming all query permutations are equivalent. Preserve both the incoming sequence and the origin-observed sequence in the pilot. Make an unexplained content or action difference a reason to exclude that route from sorting.\nVerification\nIn a controlled test, compare the original and reordered forms of representative queries, including duplicate parameter names. Inspect the origin request and returned content or application action. Exercise affected administrative functions and signed URLs where present, then retain the scoped exclusions and observed results instead of relying on a historical WordPress example alone.\nOfficial reference\nCloudflare — Query String Sort. Reviewed October 20, 2026.", "content_markdown": "Repeated parameters can carry meaning in their original sequence.\n\n## Source facts\n\nCloudflare documents Query String Sort as normalizing query ordering for cache lookup, including sorting repeated parameter names by value. Applications requiring exact order can behave unexpectedly. Its WordPress example concerns ordered script parameters, while the guide notes newer WordPress versions may include a relevant fix; the behavior must therefore be checked against the installed application.\n\nSource: [Cloudflare — Query String Sort](https://developers.cloudflare.com/cache/advanced-configuration/query-string-sort/).\n\n## Applicability\n\nThis concerns Cloudflare query sorting.\n\n## DSE recommendation\n\nDSE recommends identifying routes whose parameter order affects signatures, script dependencies, or application processing before enabling sorting broadly. Apply the feature only to URL classes where equivalence is established, using a scoped rule when appropriate. Keep administration and authenticated workflows in the acceptance set. Do not interpret improved hit rate as sufficient justification if the origin receives a semantically different request. Ask application owners for one order-sensitive example rather than assuming all query permutations are equivalent. Preserve both the incoming sequence and the origin-observed sequence in the pilot. Make an unexplained content or action difference a reason to exclude that route from sorting.\n\n## Verification\n\nIn a controlled test, compare the original and reordered forms of representative queries, including duplicate parameter names. Inspect the origin request and returned content or application action. Exercise affected administrative functions and signed URLs where present, then retain the scoped exclusions and observed results instead of relying on a historical WordPress example alone.\n\n## Official reference\n\n[Cloudflare — Query String Sort](https://developers.cloudflare.com/cache/advanced-configuration/query-string-sort/). Reviewed October 20, 2026." }, { "id": "https://update.dsesecurity.com/updates/check-compression-transformations-before-requiring-a-strong-cloudflare-etag/", "slug": "check-compression-transformations-before-requiring-a-strong-cloudflare-etag", "url": "https://update.dsesecurity.com/updates/check-compression-transformations-before-requiring-a-strong-cloudflare-etag/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/check-compression-transformations-before-requiring-a-strong-cloudflare-etag.md", "json": "https://update.dsesecurity.com/api/v1/posts/check-compression-transformations-before-requiring-a-strong-cloudflare-etag/" }, "title": "Check compression transformations before requiring a strong Cloudflare ETag", "summary": "A strong origin validator can become weak when the delivered representation changes.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:16:48+00:00", "modified_at": "2026-10-20T18:34:36+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 246, "potentially_affected": "This concerns Cloudflare handling of origin ETags.", "dse_recommendation": "DSE recommends deciding whether the application needs byte-level identity or semantic revalidation before changing validator settings.", "primary_source": { "name": "Cloudflare — Using ETag Headers with Cloudflare", "url": "https://developers.cloudflare.com/cache/reference/etag-headers/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A strong origin validator can become weak when the delivered representation changes.
\nCloudflare distinguishes strong ETags, which identify byte-equivalent representations, from weak ETags, which indicate semantic equivalence. Its documentation shows compression and visitor Accept-Encoding combinations where strong tags are weakened. Enabling Respect Strong ETags also disables specified transformation features, so that choice has effects beyond the response validator itself.
\nSource: Cloudflare — Using ETag Headers with Cloudflare.
\nThis concerns Cloudflare handling of origin ETags.
\nDSE recommends deciding whether the application needs byte-level identity or semantic revalidation before changing validator settings. Inventory response transformations and compression at origin and edge. Avoid forcing a strong label onto content whose bytes were changed in transit. Review the documented feature changes when enabling Respect Strong ETags and coordinate them with the website owner rather than treating the setting as an isolated cache optimization. Have the website owner approve the transformation features affected by the setting before deployment. Keep a byte comparison for one encoded and one unencoded path beside the validator result. Reopen the decision when compression policy changes rather than treating a previously observed strong tag as permanent.
\nFor a controlled resource, compare ETag, Content-Encoding, and actual bytes through representative accepted encodings. Exercise a conditional request and verify the intended 304 or replacement behavior. Record both the configured transformation policy and observed validator strength, and test any disabled website features before adopting the setting broadly.
\nCloudflare — Using ETag Headers with Cloudflare. Reviewed October 20, 2026.
", "content_text": "A strong origin validator can become weak when the delivered representation changes.\nSource facts\nCloudflare distinguishes strong ETags, which identify byte-equivalent representations, from weak ETags, which indicate semantic equivalence. Its documentation shows compression and visitor Accept-Encoding combinations where strong tags are weakened. Enabling Respect Strong ETags also disables specified transformation features, so that choice has effects beyond the response validator itself.\nSource: Cloudflare — Using ETag Headers with Cloudflare.\nApplicability\nThis concerns Cloudflare handling of origin ETags.\nDSE recommendation\nDSE recommends deciding whether the application needs byte-level identity or semantic revalidation before changing validator settings. Inventory response transformations and compression at origin and edge. Avoid forcing a strong label onto content whose bytes were changed in transit. Review the documented feature changes when enabling Respect Strong ETags and coordinate them with the website owner rather than treating the setting as an isolated cache optimization. Have the website owner approve the transformation features affected by the setting before deployment. Keep a byte comparison for one encoded and one unencoded path beside the validator result. Reopen the decision when compression policy changes rather than treating a previously observed strong tag as permanent.\nVerification\nFor a controlled resource, compare ETag, Content-Encoding, and actual bytes through representative accepted encodings. Exercise a conditional request and verify the intended 304 or replacement behavior. Record both the configured transformation policy and observed validator strength, and test any disabled website features before adopting the setting broadly.\nOfficial reference\nCloudflare — Using ETag Headers with Cloudflare. Reviewed October 20, 2026.", "content_markdown": "A strong origin validator can become weak when the delivered representation changes.\n\n## Source facts\n\nCloudflare distinguishes strong ETags, which identify byte-equivalent representations, from weak ETags, which indicate semantic equivalence. Its documentation shows compression and visitor Accept-Encoding combinations where strong tags are weakened. Enabling Respect Strong ETags also disables specified transformation features, so that choice has effects beyond the response validator itself.\n\nSource: [Cloudflare — Using ETag Headers with Cloudflare](https://developers.cloudflare.com/cache/reference/etag-headers/).\n\n## Applicability\n\nThis concerns Cloudflare handling of origin ETags.\n\n## DSE recommendation\n\nDSE recommends deciding whether the application needs byte-level identity or semantic revalidation before changing validator settings. Inventory response transformations and compression at origin and edge. Avoid forcing a strong label onto content whose bytes were changed in transit. Review the documented feature changes when enabling Respect Strong ETags and coordinate them with the website owner rather than treating the setting as an isolated cache optimization. Have the website owner approve the transformation features affected by the setting before deployment. Keep a byte comparison for one encoded and one unencoded path beside the validator result. Reopen the decision when compression policy changes rather than treating a previously observed strong tag as permanent.\n\n## Verification\n\nFor a controlled resource, compare ETag, Content-Encoding, and actual bytes through representative accepted encodings. Exercise a conditional request and verify the intended 304 or replacement behavior. Record both the configured transformation policy and observed validator strength, and test any disabled website features before adopting the setting broadly.\n\n## Official reference\n\n[Cloudflare — Using ETag Headers with Cloudflare](https://developers.cloudflare.com/cache/reference/etag-headers/). Reviewed October 20, 2026." } ] }