Appearance
DNSSEC Feasibility — ciriusgroup.com and ciriusdde.com
Purpose
Evaluate whether to enable DNSSEC (Domain Name System Security Extensions) on the two Cirius Group customer-visible domains: ciriusgroup.com and ciriusdde.com. This document is decision input for Rory — it does not implement anything.
The short version: DNSSEC is desirable in principle but not currently implementable for either domain because Azure DNS (which hosts both zones) does not natively sign zones as of the last confirmed check. The document below covers the full analysis, what would need to change, and the recommendation.
What DNSSEC Does
DNSSEC cryptographically signs DNS records so that a resolving client can prove:
- The record came from the legitimate zone owner (authenticity)
- The record has not been tampered with in transit (integrity)
- A "no such record" response is authoritative and not a suppression (NXDOMAIN authentication via NSEC/NSEC3)
It does not:
- Encrypt DNS traffic (that is DoH/DoT)
- Protect the last mile between the resolver and the client
- Prevent DNS-based data exfiltration (that is Palo Alto DNS Security's job, which we already have)
The threat DNSSEC addresses is cache poisoning / spoofing of authoritative responses. Realistic for a customer-facing domain; moderate concern for an internal one.
Current DNS Architecture
ciriusgroup.com
- Registrar: U2 Web Services
- Authoritative nameservers: Azure DNS public zone, Cirius PROD subscription (tenant
d477c9f8) - Zone hosting:
azurerm_dns_zoneinazure-infra/dns/ - Consumers: customer marketing site,
secops.bedrockcybersecurity.org,mail.ciriusgroup.com, Autodiscover, and assorted SaaS CNAMEs
ciriusdde.com
- Registrar: U2 Web Services
- Authoritative nameservers: Azure DNS public zone, Cirius DDE subscription (tenant
ff1c5d68) - Zone hosting:
azurerm_dns_zoneinazure-dde-infra/dns/ - Consumers: Medicare billing published app hostname,
breakglass.ciriusdde.com(rare), DDE AVD DNS entries
Both zones are managed exclusively via Terraform. No portal edits. Record changes go through PR review.
Registrar Support — U2 Web Services
DNSSEC at the registrar is the step where the Delegation Signer (DS) record is published at the parent (.com) zone. Without a published DS, the cryptographic chain is broken and DNSSEC validation returns insecure rather than secure.
U2 Web DNSSEC support status is not publicly documented and must be confirmed directly with U2 Web before any implementation work begins. The questions for U2 Web are:
- Does your registrar control panel allow publication of DS records for
.comdelegations? - What is the interface — web portal, support ticket, API?
- What key algorithms do you accept? (minimum target: RSASHA256 / algorithm 8, preferred: ECDSAP256SHA256 / algorithm 13)
- What is your turnaround time for DS publication and rotation?
- Do you support multiple DS records for key rollover without dropping validation?
Until those answers are in writing, the U2-side feasibility is unknown. Moving forward assumes the answer is "yes, with some manual ticket process" — a reasonable baseline. If U2 cannot publish DS records at all, DNSSEC is not possible without migrating registrar, which is out of scope for this story.
Azure DNS Support — The Blocking Constraint
Current state
Azure DNS (public zones, azurerm_dns_zone) provides authoritative DNS hosting. Azure DNS does not natively support DNSSEC zone signing as of the last publicly documented position (Microsoft documentation and Azure roadmap, confirmed through 2024).
Specifically:
- Azure DNS does not generate Zone Signing Keys (ZSK) or Key Signing Keys (KSK) for its zones
- Azure DNS does not serve RRSIG, NSEC, NSEC3, or DNSKEY records for customer-managed zones
- There is no
azurerm_dns_zoneproperty to enable signing - There is no Azure DNS portal or CLI command to enable DNSSEC
This is a platform limitation, not a configuration gap. We cannot terraform apply our way to a signed zone on Azure DNS.
Status check
Before finalizing the recommendation below, a final check should be made against current Microsoft documentation:
- [ ] Microsoft Learn — "Azure DNS" — search for "DNSSEC" in feature support
- [ ] Azure Updates / roadmap — filter DNS category
- [ ] If Microsoft has announced DNSSEC support since the last review, this document's blocker clause is obsolete and the recommendation flips to "enable"
If Microsoft has shipped DNSSEC for Azure DNS, supersede this document with a new DNS-00X story to implement.
Options If We Want DNSSEC Today
Given Azure DNS cannot sign, there are three paths:
Option 1 — Wait for Azure DNS native DNSSEC
Pros. Zero effort. Integrates with existing Terraform. Preserves zone-in- tenant model.
Cons. Microsoft ETA unknown. Could be a year, could be never. Leaves the domains unsigned in the interim.
When this is right. If DNSSEC is desirable but not required, and we trust Microsoft's eventual delivery.
Option 2 — Migrate zones to a DNSSEC-capable provider
Move both zones to a hosted DNS provider that signs: Cloudflare DNS (signs automatically), AWS Route 53 (supports KMS-backed signing), or a dedicated DNSSEC-capable provider.
Pros. Signed zones possible in days. Well-understood operational model.
Cons. Introduces a second authoritative DNS provider for Cirius to administer (or replaces Azure DNS entirely). Breaks the "Terraform all the things in Azure" pattern. Adds another vendor dependency for a customer- critical surface. Migration of ciriusdde.com is particularly sensitive because it is the customer-facing Medicare billing published app hostname.
When this is right. If DNSSEC becomes a compliance requirement or there is a specific threat demanding signing within a short window.
Option 3 — Hybrid: delegate selected subdomains
Keep the apex at Azure DNS, delegate a subdomain (e.g., secure.ciriusgroup.com) to a DNSSEC-signing provider for only the handful of records that need it.
Pros. Limits migration scope. Preserves Azure DNS for most records.
Cons. Does not help the apex — ciriusgroup.com and ciriusdde.com themselves remain unsigned. The apex is the record most commonly attacked via cache poisoning for phishing. Real benefit is marginal.
When this is right. Rarely. Mostly useful when one high-value service (e.g., a banking API) is hosted on a subdomain and the customer experience for it is especially sensitive.
Recommended Signing Algorithm (If We Implement)
When Azure DNS ships DNSSEC, or if we migrate to a signing provider, use:
- Algorithm 13 — ECDSAP256SHA256 for both ZSK and KSK
- NSEC3 with opt-out disabled (small zones; no need for opt-out)
- Key rollover: ZSK every 90 days, KSK every 365 days, with pre-publication at least one TTL ahead and post-removal hold of one TTL
Rationale:
- Algorithm 13 is smaller, faster, and widely supported. RSASHA256 (algo 8) is an acceptable fallback if U2 Web or the signing provider does not accept algorithm 13.
- ECDSA keys keep DNSKEY responses small (important — large DNSKEY responses are a known reflection amplification vector and trigger TCP fallbacks).
- NSEC3 without opt-out provides authenticated denial without the zone enumeration concerns of raw NSEC.
Key material, if we operate our own signing (Option 2 path with self-managed keys), lives in Key Vault (Azure) with HSM-backed keys. Rotation is scripted and runs in CI.
Risks
Risks of enabling DNSSEC
- Broken zone if rollover is mishandled — a bad key rotation takes the domain offline for everyone validating. This is the cardinal DNSSEC operational risk and the reason mid-size environments often defer.
- Operational complexity — key material, rollover timing, DS-at-registrar coordination. More moving parts than unsigned DNS.
- TLSA / DANE expectations — once a zone is signed, some clients expect TLSA records to be available for mail and HTTPS. We would need to decide whether to publish them.
- Response size — signed responses are larger and push more queries to TCP; most modern resolvers handle this fine but old enterprise resolvers sometimes do not.
Risks of not enabling DNSSEC
- Cache poisoning / response spoofing against customer resolvers — low probability, serious impact on a Medicare billing hostname
- Some compliance frameworks list DNSSEC as a recommended control; absence is not a finding today, could be in a future HITRUST revision
- A regulator or customer audit may ask specifically — having this document is the risk mitigation for that question
Recommendation
Defer DNSSEC implementation. Re-evaluate quarterly.
Reasoning:
- Azure DNS is the hosting decision that matters most, and it does not sign zones today. Implementing DNSSEC therefore requires a second authoritative DNS provider, which is a bigger change than the threat warrants given our existing control layering (DNS Security on Palo Alto, HTTPS with HSTS on customer-facing hostnames, 6-year DNS query logging to LAW).
- U2 Web Services' DNSSEC support at the registrar side is unconfirmed. Ask in writing but do not block on it — the Azure DNS constraint is the gating issue.
- Both zones are low-churn (single-digit records each) and fully Terraform- managed, so if Azure DNS ships signing support the operational cost of enabling it is modest.
- Nothing prevents us from tracking the dependency: if Microsoft ships DNSSEC for Azure DNS, open a new story to enable it; if a compliance driver appears (HITRUST revision, customer contract, etc.), re-open this decision with the compliance driver as the forcing function.
Tracking work
- [ ] Add "Azure DNS DNSSEC support" to the quarterly Azure roadmap review
- [ ] Confirm U2 Web Services DS publication workflow in writing (one-time, record the answer in an appendix to this document)
- [ ] If Azure DNS ships DNSSEC, open a follow-up story DNS-00X to enable for both zones using algorithm 13 per this document's recommendation
Related Documents
- palo-alto-overview.md — DNS Security active and blocking for exfiltration and C2 (compensating control)
- Azure DNS zone Terraform —
azure-infra/dns/,azure-dde-infra/dns/
Change History
| Date | Change | Author |
|---|---|---|
| April 2026 | Initial feasibility — Azure DNS does not sign, recommendation defer | Kobe |