When you need it
DNS changes happen by hand in a web console. Nobody can say who changed a record or why, one typo can take down email or a website, and moving to another provider feels too risky to start.
What sets the quote
- Up to 100 zones and 5,000 records.
- One source and one target provider (such as Route 53, Azure DNS, Cloud DNS or Cloudflare), or your current provider in place.
- In place, zones are imported into Terraform with zero record changes, proven in the provider's audit log (CloudTrail for Route 53, the Activity log for Azure DNS, Cloud Audit Logs for Cloud DNS).
- Tooling is Terraform, octoDNS or DNSControl, whichever suits your team.
- More zones or records are quoted after sizing.
What changes
- Every DNS change is a reviewed pull request, applied by a pipeline and traceable to a person and a reason.
- Drift detection reports any change made outside the code, so your team can undo it or bring it into the code.
- An in-place import changes nothing, and the audit log proves it.
- A provider move happens zone by zone, after a record-by-record comparison, with a rollback plan for each delegation change.
What you get
- Git repository with every zone and record in Terraform, octoDNS or DNSControl
- Import report per zone with record counts, differences found and audit-log evidence of zero changes
- Pull request workflow that shows planned changes, requires approval and applies from the pipeline
- Scheduled drift detection with alerts to your team
- For a provider move, a cutover runbook covering TTL lowering, record comparison, delegation change and rollback
- Pipeline access to the DNS provider through OIDC where supported, or a narrowly scoped API token
- Runbook for common changes and a handover session
The in-place method has been applied to an estate of hundreds of zones. It is a safe first step before any clean-up or provider move, because nothing changes until your team approves a pull request.
Not included
- Registrar or TLD transfers
- DNSSEC re-keying, for example when signed zones move between providers
- Cleaning up stale records during the import; they are listed for your team to review afterwards
- DNS provider fees
What we need from you
- Read-only access for the inventory: AmazonRoute53ReadOnlyAccess in AWS, Reader on the DNS zones in Azure, DNS Reader in Google Cloud, or a Cloudflare API token with Zone Read and DNS Read.
- For the pipeline, a role that can change records: Route 53 permissions scoped to your hosted zones, DNS Zone Contributor in Azure, DNS Administrator in Google Cloud, or a Cloudflare API token with DNS Edit.
- A repository and CI on your Git platform, such as GitHub Actions, GitLab CI or Azure Pipelines.
- A named approver for DNS changes, and registrar access only if name servers change.
How it works
Free 30-minute call, then your zone and record counts and a written fixed quote.
Export every zone, import it into code, and confirm zero changes in the plan and in the audit log.
Switch on the pull request workflow and drift detection; for a provider move, sync the target and change delegation zone by zone.
Hand over the repository and runbooks in a working session with your team.
At a glance
- Duration
- 2–3 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and a cloud engineer
Related services
PKI review
A one-week review of your PKI and certificates, covering the CA hierarchy, certificate inventory, TLS settings and revocation, rated red, amber or green, with an expiry risk list and a roadmap.
Domain and external attack surface check
A one-week, non-intrusive check of your domains, DNS, email authentication and internet-facing endpoints, with every finding tied to evidence and a fix. It is not a penetration test.
Microsoft 365 security baseline
Conditional Access, phishing-resistant MFA and just-in-time admin rights for Microsoft 365, plus Intune policies, Defender for Endpoint and disk encryption for Windows and macOS, designed and rolled out in 1–3 weeks.