02 Dec End-to-End Dev/Test/Prod Pipeline for DNS Changes in Azure

Intro

DNS is one of those foundational services that often receives little attention—until something breaks.

A single DNS modification can impact application routing, API connectivity, Private Endpoint resolution, hybrid connectivity, or customer-facing services. Unlike many application changes, DNS mistakes propagate quickly and may affect broad portions of an environment.

As organizations scale their Azure deployments, manual DNS modifications become increasingly risky:

• Records modified directly in production
• Inconsistent entries between environments
• Missing rollback processes
• Configuration drift
• No audit trail

This article demonstrates how organizations can implement a complete Dev → Test → Production pipeline for Azure DNS changes using Infrastructure-as-Code and PowerShell automation.

We’ll cover:

✔ Environment isolation for DNS management
✔ PowerShell-driven CI/CD workflows
✔ DNS record creation and updates
✔ Rollback strategies
✔ Version-controlled DNS infrastructure
✔ Automated validation before production deployment

Modern application deployment pipelines rarely push directly into production.

Applications typically progress through:

Development → Testing → Production

DNS changes should follow the same process.

Instead of editing records directly in a production DNS zone:

myapp.company.com

organizations can create isolated environments:

This approach enables validation of DNS behavior before exposing changes to production workloads.

Problem

Traditional DNS operations frequently resemble the following process:

Engineer
    ↓
Portal Changes
    ↓
Production DNS Zone
    ↓
Immediate Impact

Challenges include:

❌ Manual changes without peer review

❌ No version history

❌ Difficult rollback procedures

❌ Configuration inconsistencies

❌ High production risk

Example:

A CNAME record update:

Before:

api.company.com → app-v1.azurewebsites.net

After:

api.company.com → app-v2.azurewebsites.net

If application validation fails after deployment, users may immediately experience service disruption.

PowerShell-Based DNS Deployment

Infrastructure-as-Code Example

Store DNS records in source control:

dns-records.json

{
    "records": [
        {
            "name":"api",
            "type":"CNAME",
            "ttl":300,
            "value":"app-v2.azurewebsites.net"
        },
        {
            "name":"web",
            "type":"A",
            "ttl":300,
            "value":"20.80.150.10"
        }
    ]
}

Benefits:

• Version history
• Pull requests
• Change tracking
• Peer reviews
• Rollback capability

Load DNS configuration

$dnsConfig = Get-Content `
".\dns-records.json" `
| ConvertFrom-Json

Create or update records

foreach ($record in $dnsConfig.records)
{
    if($record.type -eq "CNAME")
    {
        Set-AzDnsRecordSet `
        -Name $record.name `
        -RecordType CNAME `
        -ZoneName $ZoneName `
        -ResourceGroupName $RG `
        -Ttl $record.ttl `
        -DnsRecords (New-AzDnsRecordConfig `
            -Cname $record.value)
    }

    if($record.type -eq "A")
    {
        Set-AzDnsRecordSet `
        -Name $record.name `
        -RecordType A `
        -ZoneName $ZoneName `
        -ResourceGroupName $RG `
        -Ttl $record.ttl `
        -DnsRecords (New-AzDnsRecordConfig `
            -IPv4Address $record.value)
    }
}

CI/CD Pipeline Example

trigger:
- main

stages:

- stage: Dev
  jobs:
  - job: DeployDev
    steps:
      - task: AzurePowerShell@5
        inputs:
          scriptPath: deploy-dns.ps1

- stage: Test
  dependsOn: Dev

- stage: Production
  dependsOn: Test

Pipeline flow:

Code Commit
      ↓
Validation
      ↓
Deploy Dev
      ↓
DNS Testing
      ↓
Approval Gate
      ↓
Deploy Production

Automated Validation Before Promotion

DNS deployments should validate resolution before progressing.

PowerShell example:

$result = Resolve-DnsName `
api.dev.company.com

if($result.IPAddress)
{
    Write-Host "DNS validation successful"
}
else
{
    throw "DNS validation failed"
}

Possible validation checks:

• Record existence
• Correct IP resolution
• Endpoint health
• SSL certificate validation
• Application connectivity

Rollback Strategy

DNS changes should always include recovery procedures.

One approach:

Export current DNS state before deployment.

Get-AzDnsRecordSet `
-ZoneName $ZoneName `
-ResourceGroupName $RG |
ConvertTo-Json |
Out-File backup.json

If deployment fails:

$backup = Get-Content `
backup.json |
ConvertFrom-Json

# Restore records

Alternative approaches include:

• Git-based version rollback
• Blue/Green DNS cutovers
• Weighted routing
• Traffic Manager failback

Wrapping it all up

DNS changes can have broad consequences across applications and services, making them ideal candidates for disciplined deployment pipelines.

By introducing Dev/Test/Production environments and automating deployments with PowerShell and Infrastructure-as-Code, organizations gain:

• Reduced operational risk
• Consistent deployments
• Faster recovery
• Full change visibility
• Repeatable automation

As cloud environments continue growing in complexity, DNS should evolve from manual administration to a fully managed component of the software delivery lifecycle.

Reliable infrastructure begins with reliable name resolution.