How Infrastructure as Code Simplifies Compliance for Domain and DNS Management

In a previous post, I described how we adopted Infrastructure as Code to manage our domains and DNS at DNSimple using our own Terraform provider. While operational benefits like centralization and automation were expected, one of the most significant impacts was on compliance and governance.

If you're pursuing ISO 27001, SOC 2, or similar certifications, you need to demonstrate rigorous control over your infrastructure. Domain and DNS management is no exception. In fact, because domains are critical assets that control your online presence, they often receive special scrutiny during audits.

This is where Infrastructure as Code for domain and DNS management becomes transformative. It represents the ultimate example of domain management automation.

The compliance challenge

Compliance frameworks require you to answer several fundamental questions about your infrastructure:

• Who has access to make changes?
• What changes were made?
• Were changes reviewed before implementation?
• Can you prove the state of your infrastructure at any point in time?

For DNS and domain management, these requirements are particularly challenging with traditional approaches.

Manual web interface changes leave minimal audit trails. You might have activity logs showing "user X changed zone Y," but you don't have context. What was the change? Why was it made? Who approved it? These questions are difficult to answer retrospectively, even with a proper activity log.

API scripts are better, but often scattered across repositories or developer workstations. There's no central inventory of what's deployed. Scripts might be version controlled individually, but there's no single source of truth for your infrastructure state.

Infrastructure as Code solves these problems systematically.

Access control

In the traditional model, anyone who needs to manage DNS needs admin access to your DNS provider. This violates the principle of least privilege, a core requirement in most security frameworks.

Consider a typical scenario: a developer needs to add a DNS record for a new service. With traditional access control, you have two options:

1. Grant them admin access to your DNS provider (over-privileging)
2. Have them request the change from someone with admin access (bottleneck)

Neither option is ideal. The first creates security risk. The second slows down operations and doesn't scale.

With Infrastructure as Code, access control has two layers:

1. Code repository access determines who can propose changes (anyone on the team can open a PR)
2. PR review requirements determine who can approve changes (restricted to platform team)

The actual credentials for DNSimple are stored securely as secrets. They're never exposed to individual developers. No one needs admin access to DNSimple to propose or implement DNS changes.

This model implements true least privilege:

• Developers can propose any change they need (no bottleneck)
• Changes can't be applied without approval (no over-privileging)
• Credentials are isolated from users (no credential exposure)

For compliance audits, you can demonstrate that:

• Admin credentials are stored in secure credential management systems
• No individual users have direct access to make unauthorized changes
• All changes require approval from authorized personnel

Change management

Every infrastructure change needs documentation. During a compliance audit, you need to prove that changes followed proper change management procedures.

With Infrastructure as Code, every change has a complete paper trail:

• The pull request documents what changed and why
• The review shows who approved it
• The commit records when it was applied
• Terraform's state tracks the exact configuration

This creates an immutable audit log. For compliance purposes, you can prove:

• Changes were proposed through documented processes
• Changes were reviewed by authorized personnel
• Changes were tested (via terraform plan) before implementation
• The system state matches documentation at any point in time

Here's what this looks like in practice:

Pull Request #142: Add CAA records for dnsimple.com
Author: developer-1
Reviewers: platform-team-lead
Status: Merged
Date: 2024-03-15

Terraform Plan Output:
  + dnsimple_zone_record.caa_letsencrypt (to create)
  + dnsimple_zone_record.caa_sectigo (to create)

Review Comments:
- platform-team-lead: "Approved. CAA records align with our
  certificate issuance policy documented in SEC-001."

Merged by: platform-team-lead
Applied by: CI/CD (automated)

This single pull request provides everything an auditor needs:

• What changed (CAA records added)
• Who proposed it (developer-1)
• Who approved it (platform-team-lead)
• When it was applied (2024-03-15)
• Why it was made (certificate issuance policy)
• Verification that it was tested before implementation (terraform plan output)

Compare this to manual change management where you might need to dig through:

• Email threads requesting the change
• Ticket systems tracking approvals
• Application logs showing when the change was made
• Screenshots or manual documentation of the old and new state

With IaC, all of this is captured automatically as a natural byproduct of the workflow.

Configuration standards

Compliance often requires enforcing configuration standards. For example:

• All domains must have DNSSEC enabled
• Transfer locks must be enabled on production domains
• Specific security records (CAA, DMARC) must be present

With manual processes, enforcing these standards requires either:

1. Manual review of every change (doesn't scale)
2. Periodic audits to check compliance (detects issues after they occur)
3. Documentation that people must remember to follow (unreliable)

With Infrastructure as Code, you can encode these requirements and enforce them automatically.

Policy as code

Tools like Terraform Sentinel or Open Policy Agent (OPA) can enforce rules automatically. A policy might require:

# Pseudo-code policy
rule "require_dnssec_on_production_domains" {
  condition = all_registered_domains satisfy {
    domain.dnssec_enabled == true
  }
}

This policy runs automatically on every terraform plan. If someone tries to register a domain without DNSSEC enabled, the plan fails before it ever reaches the apply stage.

For compliance, this means:

• Standards are encoded as executable code, not just documentation
• Violations are prevented, not just detected
• Policy enforcement is automatic and consistent

Pull request templates

You can include compliance checklists in your PR templates:

## Pre-deployment Checklist

For new domain registrations:
- [ ] DNSSEC enabled
- [ ] Transfer lock enabled
- [ ] Auto-renewal configured appropriately
- [ ] Contact information current and accurate
- [ ] Change has business justification in ticket/RFC

For DNS changes:
- [ ] CAA records configured for applicable zones
- [ ] DMARC policy present for email-sending domains
- [ ] Changes reviewed for security implications

These checklists become part of the permanent record in the pull request.

Automated testing

You can validate configuration before it's applied:

# In CI/CD pipeline
terraform plan
terraform validate
./scripts/validate-compliance.sh
./scripts/check-security-records.sh

These validation scripts can check for:

• Required DNS records are present
• Domain settings match security policy
• No prohibited configurations (like open mail relays)
• TTL values are within acceptable ranges

If validation fails, the CI/CD pipeline fails, and the change can't be merged.

Asset inventory

Compliance frameworks require maintaining an accurate inventory of infrastructure assets. This seems straightforward, but for many organizations, it's surprisingly difficult.

Domain names are often:

• Registered with multiple registrars
• Managed by different teams
• Purchased by individuals and later transferred to the company
• Forgotten about until they expire
• Documented in spreadsheets that become outdated

For organizations with hundreds of domains, maintaining an accurate inventory is a persistent challenge.

The Infrastructure as Code repository is that inventory. It's version controlled, it's always current (enforced by drift detection), and it's auditable.

Every domain is defined in code:

resource "dnsimple_registered_domain" "example_com" {
  provider              = dnsimple.domains
  name                  = "example.com"
  contact_id            = 1234
  auto_renew_enabled    = true
  transfer_lock_enabled = true
  dnssec_enabled        = true
}

Want to know what domains your organization owns? Query the Terraform configuration:

grep "resource \"dnsimple_registered_domain\"" workspace/*.tf | wc -l

Need to know which domains have DNSSEC enabled?

grep -A 5 "dnsimple_registered_domain" workspace/*.tf | \
  grep "dnssec_enabled = true" | wc -l

During a SOC 2 audit, when the auditor asks "how do you track your domain portfolio?", the answer is simple: "Here's the Git repository. Every domain we own is defined here."

This is dramatically simpler than maintaining separate asset inventories that require manual updates.

Segregation of duties

Many compliance frameworks require segregation of duties: the person who proposes a change shouldn't be the person who approves it.

In traditional systems, enforcing this requires manual process controls:

• Documented procedures that people must follow
• Periodic reviews to ensure procedures are followed
• Reliance on people remembering the rules

These manual controls are error-prone and don't scale well.

Branch protection and PR review requirements enforce segregation of duties automatically:

# Branch protection rules
main:
  required_reviews: 1
  dismiss_stale_reviews: true
  require_code_owner_reviews: true
  required_approving_review_count: 1

With these rules in place:

• No one can merge their own pull request (segregation enforced)
• Reviews are required from code owners (authorized approvers only)
• Stale reviews are dismissed if code changes (no approval bypassing)

The platform team owns the workspace directory via a CODEOWNERS file:

workspace/ @dnsimple/platform-team

Any change to domain or DNS configuration requires approval from the platform team. Even if a platform team member proposes a change, a different team member must review it.

This creates natural segregation of duties without manual process enforcement. The system prevents violations automatically.

For compliance audits, you can demonstrate:

• Segregation of duties is technically enforced, not just procedural
• The enforcement is consistent across all changes
• There are no exceptions or bypasses
• The system maintains a complete audit trail of who approved what

Point-in-time state verification

One of the most powerful compliance features of Infrastructure as Code is the ability to prove your infrastructure state at any point in time.

Traditional systems might have:

• Activity logs showing changes were made
• Backup snapshots of configuration at specific times
• Manual documentation of historical state

But reconstructing the exact state of your infrastructure at a specific date is difficult.

With IaC in Git, this is trivial:

# What did our DNS look like on January 1, 2024?
git checkout $(git rev-list -n 1 --before="2024-01-01" main)
terraform show

This gives you the exact configuration at that point in time.

During compliance audits, this capability is invaluable. An auditor might ask:

• "Did you have DNSSEC enabled on dnsimple.com on the date of the security incident?"
• "What CAA records were in place when the certificate was issued?"
• "Which domains had transfer locks enabled during Q4 2023?"

With IaC in version control, you can answer these questions definitively, with proof.

Compliance reporting

Because your infrastructure is defined as code, you can generate compliance reports automatically.

Want a report of all domains without DNSSEC enabled?

./scripts/report-dnssec-status.sh

Need to track when specific security controls were implemented?

git log --all --grep="DNSSEC" --oneline
git log --all --grep="CAA" --oneline

These reports are:

• Always current (based on live configuration)
• Reproducible (same query always gives same answer)
• Auditable (the scripts themselves are version controlled)

Compare this to manually maintaining compliance spreadsheets that require periodic updates and can become outdated.

Internal security audit

Our teams periodically audits infrastructure to ensure compliance with security policies.

For DNS and domain management, they can:

1. Clone the repository
2. Run automated checks against the configuration
3. Generate reports of any policy violations

No manual review required. The security team can verify compliance independently without requesting access to production systems.

Conclusion

Infrastructure as Code isn't just about automation and efficiency. For organizations pursuing compliance certifications, it fundamentally transforms how you demonstrate control over your infrastructure.

The benefits for compliance are:

• Access control - Least privilege implemented technically, not procedurally
• Change management - Complete audit trail as a natural byproduct of workflow
• Configuration standards - Policies enforced automatically in code
• Asset inventory - Always current, version controlled, auditable
• Segregation of duties - Technically enforced through code change protections
• Point-in-time verification - Prove infrastructure state at any historical date
• Automated reporting - Generate compliance reports from live configuration

If you're managing domains and DNS while pursuing compliance certifications, Infrastructure as Code isn't optional, it's essential. The DNSimple Terraform provider makes this possible with full domain lifecycle management, giving you the tools to manage domains and DNS with the same rigor you apply to other critical infrastructure.

This approach works equally well with any code repository provider. Whether you use GitHub with GitHub Actions or GitLab with GitLab CI, the fundamental principles remain the same: version-controlled infrastructure, automated workflows, and enforced review processes. Choose the platform that best fits your organization's needs—the compliance benefits are consistent across all modern repository providers.

The solution presented in this post aligns with our broader commitment to domain management automation and helps our customers build compliant, auditable infrastructure.

Ready to simplify your compliance process? Give DNSimple a try free for 30 days, and see how Infrastructure as Code can transform your domain and DNS management. And as always, if you have any questions about compliance requirements or implementation, get in touch — we'd love to help.

Happy automating!

Share on Twitter and Facebook

Simone Carletti

Italian software developer, a PADI scuba instructor and a former professional sommelier. I make awesome code and troll Anthony for fun and profit.