As I guide our team of Site Reliability Engineers through infrastructure modernization, we frequently encounter challenges that require balancing innovation with stability.

Recently, we tackled an important one: modernizing DNS management for our Red Hat OpenShift Service on AWS (ROSA) clusters while preserving our existing DNS infrastructure. The solution we developed bridges traditional DNS management with cloud-native practices, creating a streamlined workflow for our entire engineering team.

The Technical Challenge 🔍

When implementing ROSA clusters at scale, DNS management becomes a critical consideration. Working with our SRE team, we identified two key requirements:

1. Maintain compatibility with our existing external DNS infrastructure
2. Implement automated DNS management for our growing ROSA deployment

Here’s how we developed and implemented a solution that satisfied both requirements while simplifying our workflow.

The DNS Challenge 🤔

When deploying ROSA clusters, you need DNS records for both the API endpoint and application wildcard routes. While you could manually add these to your existing DNS provider, automating this process with AWS Route53 offers several advantages:

• Infrastructure as Code (IaC) automation
• Tight integration with AWS services
• Reduced latency for DNS resolution
• Automated DNS validation for ACM certificates
• Automated DNS clean up when resources are destroyed

The Solution: Delegated DNS Zones 🎯

Instead of moving our entire DNS infrastructure to AWS, we created a delegated zone specifically for our ROSA clusters. Here’s how it works:

1. Create a Route53 hosted zone for your subdomain
2. Set up the necessary records for ROSA
3. Add NS records in your primary DNS pointing to the Route53 nameservers

Implementation with Terraform 🛠️

# create the delegated zone
resource "aws_route53_zone" "this" {
  name = var.route53_zone_name
  tags = var.default_tags
}

# API endpoint record using Alias to the ROSA API LB
resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.this.zone_id
  name    = "api.${var.route53_zone_name}"
  type    = "A"

  alias {
    name                   = aws_lb.rosa_api.dns_name
    zone_id               = aws_lb.rosa_api.zone_id
    evaluate_target_health = true
  }
}

# Wildcard record for applications pointing to the ROSA router LB
resource "aws_route53_record" "apps_wildcard" {
  zone_id = aws_route53_zone.this.zone_id
  name    = "*.apps.${var.route53_zone_name}"
  type    = "A"

  alias {
    name                   = aws_lb.rosa_apps.dns_name
    zone_id               = aws_lb.rosa_apps.zone_id
    evaluate_target_health = true
  }
}

# Output nameservers for delegation
output "nameservers" {
  value = aws_route53_zone.this.name_servers
  description = "Nameservers for the delegated zone - add these to your primary DNS"
}

Why Alias Records? 💡

You might notice we’re using A records with aliases instead of CNAME records. Here’s why:

1. Cost: Alias records to AWS resources are free, while CNAME queries incur charges
2. Performance: Alias records are resolved by AWS’s internal DNS system
3. Zone Apex: Unlike CNAMEs, Alias records work at the zone apex
4. Health Checking: Built-in target health evaluation

Variables for Flexibility 🔧

variable "route53_zone_name" {
  type        = string
  description = "The name of the Route53 zone (e.g., rosa.example.com)"
}


variable "default_tags" {
  type        = map(string)
  description = "Default tags for AWS resources"
  default     = {}
}

Completing the Delegation ✅

After applying this configuration, you’ll receive nameserver outputs. Add these to your primary DNS provider as NS records:

rosa.example.com. IN NS ns-1234.awsdns-12.org.
rosa.example.com. IN NS ns-567.awsdns-34.com.
rosa.example.com. IN NS ns-890.awsdns-56.net.
rosa.example.com. IN NS ns-1011.awsdns-78.co.uk.

Best Practices and Tips 🌟

1. Use Tags: Always tag your Route53 resources for better organization
2. TTL Management: Alias records don’t use TTL, but if you add other record types, choose appropriate values
3. Health Checks: Enable evaluate_target_health for automatic failover support
4. Documentation: Store the nameserver delegation details in your infrastructure documentation
5. Monitoring: Set up Route53 health checks and CloudWatch alarms for critical DNS records

Security Considerations 🔒

• Use IAM roles with least privilege
• Enable Route53 query logging
• Implement DNSSEC if required
• Consider using private hosted zones for internal resources

Conclusion 🎉

Automating DNS management with Terraform and Route53 sets a strong foundation for your ROSA infrastructure. The combination of Infrastructure as Code and AWS-native services provides reliability, scalability, and maintainability. Remember: DNS is a critical component of your infrastructure. Take time to plan and implement it properly.

Have questions about DNS automation or ROSA? Drop a comment below or reach out on BlueSky @smig.tech!