Notifications
Clear all
Topic starter
23/06/2026 7:02 pm
TL;DR: Dyn’s retirement of managed DNS forces customers to re-evaluate nameserver changes, API updates, account setup, and unsupported features such as DNSSEC and dynamic DNS, according to DigiCert. The real risk is not the migration itself but the identity and operational assumptions embedded in DNS stewardship, where service continuity depends on disciplined lifecycle control.
NHIMG editorial — based on content published by DigiCert: DYN / Oracle DNS service migration options
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern DNS migrations without losing control of delegated access?
A: Treat DNS migration as an identity and lifecycle exercise as much as a technical cutover.
Q: Why do DNS retirements create governance risk for IAM and platform teams?
A: DNS retirements expose the gap between operational ownership and access governance.
Q: What breaks when DNS features do not map cleanly to the replacement platform?
A: The immediate failure is usually operational, but the deeper issue is control drift.
Practitioner guidance
- Map every DNS-dependent identity and integration Catalogue humans, sub-users, service accounts, API clients, and scripts that can change zones or nameserver settings.
- Review unsupported features before migration Identify services such as DNSSEC, dynamic DNS, external nameservers, and notification workflows that may not exist in the destination platform, then document compensating controls or redesign options.
- Revalidate delegated credentials and API access Check whether API keys, sub-user permissions, and automation tokens still reflect current operational need, then revoke anything tied to the retired provider model.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- Service-by-service comparison of Dyn, Oracle, Constellix, and DNS Made Easy feature support
- Migration-specific notes on unsupported functions such as DNSSEC and dynamic DNS
- Provider pricing references for teams evaluating replacement options
- Account setup and nameserver transition steps that matter during cutover
👉 Read DigiCert's analysis of Dyn DNS migration options and service retirement →
Managed DNS migration: what governance gap are teams missing?
Explore further
25/06/2026 2:49 am
DNS migration is a lifecycle governance event, not a simple service swap. Once a provider retires a managed DNS offering, the organisation must re-establish ownership over delegation, account access, and service-specific controls. The failure mode is not downtime alone. It is unmanaged transition state, where old permissions linger, new access is incomplete, and operational accountability becomes fragmented. Practitioners should treat the change as a governed identity transition across the service boundary.
A few things that frame the scale:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who should own DNS migration decisions when service ownership changes?
A: Ownership should sit with the teams responsible for both service continuity and access governance, not infrastructure alone. DNS changes affect delegated administration, secrets, monitoring, and rollback. If accountability is split, the migration may succeed technically while leaving unresolved access and operational debt in place.
👉 Read our full editorial: DNS migration exposes the governance gap in provider transitions
