/managing-dns

name: managing-dns
description: Manage DNS records, TTL strategies, and DNS-as-code automation for infrastructure. Use when configuring domain resolution, automating DNS from Kubernetes with external-dns, setting up DNS-based load balancing, or troubleshooting propagation issues across cloud providers (Route53, Cloud DNS, Azure DNS, Cloudflare).

DNS Management

Configure and automate DNS records with proper TTL strategies, DNS-as-code patterns, and troubleshooting techniques.

Purpose

Guide DNS configuration for applications, infrastructure, and services with focus on:

• Record type selection (A, AAAA, CNAME, MX, TXT, SRV, CAA)
• TTL strategies for propagation and caching
• DNS-as-code automation (external-dns, OctoDNS, DNSControl)
• Cloud DNS services comparison and selection
• DNS-based load balancing patterns
• Troubleshooting tools and techniques

When to Use This Skill

Apply DNS management patterns when:

• Setting up DNS for new applications or services
• Automating DNS updates from Kubernetes workloads
• Configuring DNS-based failover or load balancing
• Troubleshooting DNS propagation or resolution issues
• Migrating DNS between providers
• Planning DNS changes with minimal downtime
• Implementing GeoDNS for global users

Record Type Selection

Quick Reference

**Address Resolution:**

• **A Record**: Map hostname to IPv4 address (example.com → 192.0.2.1)
• **AAAA Record**: Map hostname to IPv6 address (example.com → 2001:db8::1)
• **CNAME Record**: Alias to another domain (www.example.com → example.com)
• Cannot use at zone apex (@)
• Cannot coexist with other records at same name

**Email Configuration:**

• **MX Record**: Direct email to mail servers with priority
• **TXT Record**: Email authentication (SPF, DKIM, DMARC) and verification

**Service Discovery:**

• **SRV Record**: Specify service location (protocol, priority, weight, port, target)

**Delegation and Security:**

• **NS Record**: Delegate subdomain to different nameservers
• **CAA Record**: Restrict which Certificate Authorities can issue certificates

**Cloud-Specific:**

• **ALIAS Record**: Like CNAME but works at zone apex (Route53, Cloudflare)

Decision Tree

Need to point domain to:
├─ IPv4 Address? → A record
├─ IPv6 Address? → AAAA record
├─ Another Domain?
│  ├─ Zone apex (@) → ALIAS/ANAME or A record
│  └─ Subdomain → CNAME
├─ Mail Server? → MX record (with priority)
├─ Email Authentication? → TXT record (SPF/DKIM/DMARC)
├─ Service Discovery? → SRV record
├─ Domain Verification? → TXT record
├─ Certificate Control? → CAA record
└─ Subdomain Delegation? → NS record

For detailed record type examples and patterns, see `references/record-types.md`.

TTL Strategy

Standard TTL Values

**By Change Frequency:**

• **Stable records**: 3600-86400s (1-24 hours) - NS, stable A/AAAA
• **Normal operation**: 3600s (1 hour) - Standard websites, MX
• **Moderate changes**: 300-1800s (5-30 min) - Development, A/B testing
• **Failover scenarios**: 60-300s (1-5 min) - Critical records needing fast updates

**Key Principle:** Lower TTL = faster propagation but higher DNS query load

Pre-Change Process

When planning DNS changes:

T-48h: Lower TTL to 300s
T-24h: Verify TTL propagated globally
T-0h:  Make DNS change
T+1h:  Verify new records propagating
T+6h:  Confirm global propagation
T+24h: Raise TTL back to normal (3600s)

**Propagation Formula:** `Max Time = Old TTL + New TTL + Query Time`

Example: Changing a record with 3600s TTL takes up to 2 hours to fully propagate.

TTL by Use Case

| Use Case | TTL | Rationale | |----------|-----|-----------| | Production (stable) | 3600s | Balance speed and load | | Before planned change | 300s | Fast propagation | | Development/staging | 300-600s | Frequent changes | | DNS-based failover | 60-300s | Fast recovery | | Mail servers | 3600s | Rarely change | | NS records | 86400s | Very stable |

For detailed TTL scenarios and calculations, see `references/ttl-strategies.md`.

DNS-as-Code Tools

Tool Selection by Use Case

**Kubernetes DNS Automation → external-dns**

• Annotation-based configuration on Services/Ingresses
• Automatic sync to DNS providers (20+ supported)
• No manual DNS updates required
• See `examples/external-dns/`

**Multi-Provider DNS Management → OctoDNS or DNSControl**

• Version control for DNS records
• Sync configuration across multiple providers
• Preview changes before applying
• OctoDNS (Python/YAML) - See `examples/octodns/`
• DNSControl (JavaScript) - See `examples/dnscontrol/`

**Infrastructure-as-Code → Terraform**

• Manage DNS alongside cloud resources
• Provider-specific resources (aws_route53_record, etc.)
• See `examples/terraform/`

Tool Comparison

| Tool | Language | Best For | Kubernetes | Multi-Provider | |------|----------|----------|------------|----------------| | external-dns | Go | K8s automation | ★★★★★ | ★★★★ | | OctoDNS | Python/YAML | Version control | ★★★ | ★★★★★ | | DNSControl | JavaScript | Complex logic | ★★ | ★★★★★ | | Terraform | HCL | IaC integration | ★★★ | ★★★★ |

Quick Start: external-dns

# Kubernetes Service with DNS annotation
apiVersion: v1
kind: Service
metadata:
  name: app
  annotations:
    external-dns.alpha.kubernetes.io/hostname: app.example.com
    external-dns.alpha.kubernetes.io/ttl: "300"
spec:
  type: LoadBalancer
  ports:
    - port: 80

Deploy external-dns controller once, then all annotated Services/Ingresses automatically create DNS records.

For complete examples, see `examples/external-dns/` and `references/dns-as-code-comparison.md`.

Cloud DNS Provider Selection

Provider Characteristics

**AWS Route53**

• Best for AWS-heavy infrastructure
• Advanced routing policies (weighted, latency, geolocation, failover)
• Health checks with automatic failover
• ALIAS records for AWS resources (ELB, CloudFront, S3)
• Pricing: $0.50/month per zone + $0.40 per million queries

**Google Cloud DNS**

• Best for GCP-native appl