La resolution DNS hybride entre AWS et un reseau on-premise est un sujet que je rencontre regulierement chez mes clients. La plupart du temps, le besoin est simple : les applications dans le VPC doivent resoudre les noms internes de l’entreprise (ad.monentreprise.local, erp.interne.fr), et les serveurs on-premise doivent acceder aux services AWS via des noms DNS prives. AWS Route 53 Resolver est la reponse native a ce besoin. Voici comment je le mets en place.

Le probleme concret du DNS hybride cloud/on-prem

Quand vous connectez un VPC AWS a votre reseau d’entreprise via VPN site-to-site ou Direct Connect, le reseau IP fonctionne. Vos serveurs se pingent. Mais les noms DNS, eux, ne se resolvent pas entre les deux mondes.

Pourquoi ? Parce que le resolveur DNS du VPC (le .2 resolver, soit 10.0.0.2 pour un VPC en 10.0.0.0/16) ne connait que les zones Route 53 privees. Il ne sait rien de votre Active Directory, de votre BIND interne ou de vos zones .local.

Inversement, votre DNS on-premise ne sait pas resoudre mon-service.vpc.internal cote AWS.

Resultat : vos applications tombent en timeout sur des lookups DNS, et vos equipes perdent du temps a mettre des IP en dur dans les fichiers /etc/hosts. Ce n’est pas viable en production. Si vous gerez une infrastructure hybride et que ce type de problematique vous bloque, un audit de votre architecture reseau permet souvent de clarifier la cible.

Architecture Route 53 Resolver : comment ca marche

Route 53 Resolver fonctionne avec deux types d’endpoints :

Le flux est le suivant :

1. Une instance EC2 dans le VPC fait un lookup sur erp.monentreprise.local
2. Le resolver VPC consulte les forwarding rules
3. La requete est envoyee via l’outbound endpoint vers le DNS on-premise
4. La reponse revient par le meme chemin

Dans l’autre sens, le DNS on-premise forward les zones AWS (ex: vpc.internal) vers l’inbound endpoint.

Prerequis et preparation

Configuration Terraform complete

Voici la configuration Terraform que j’utilise pour deployer les endpoints Route 53 Resolver et les regles de forwarding.

Security group pour les endpoints Resolver

resource "aws_security_group" "resolver" {
  name_prefix = "dns-resolver-"
  vpc_id      = var.vpc_id
  description = "Allow DNS traffic for Route 53 Resolver endpoints"

  ingress {
    from_port   = 53
    to_port     = 53
    protocol    = "tcp"
    cidr_blocks = [var.onprem_cidr]
    description = "DNS TCP from on-premise"
  }

  ingress {
    from_port   = 53
    to_port     = 53
    protocol    = "udp"
    cidr_blocks = [var.onprem_cidr]
    description = "DNS UDP from on-premise"
  }

  egress {
    from_port   = 53
    to_port     = 53
    protocol    = "tcp"
    cidr_blocks = [var.onprem_cidr]
    description = "DNS TCP to on-premise"
  }

  egress {
    from_port   = 53
    to_port     = 53
    protocol    = "udp"
    cidr_blocks = [var.onprem_cidr]
    description = "DNS UDP to on-premise"
  }

  tags = {
    Name = "${var.project_name}-dns-resolver"
  }
}

Inbound Endpoint (on-premise vers AWS)

resource "aws_route53_resolver_endpoint" "inbound" {
  name      = "${var.project_name}-inbound"
  direction = "INBOUND"

  security_group_ids = [aws_security_group.resolver.id]

  ip_address {
    subnet_id = var.private_subnet_ids[0]
  }

  ip_address {
    subnet_id = var.private_subnet_ids[1]
  }

  tags = {
    Name = "${var.project_name}-resolver-inbound"
  }
}

Outbound Endpoint (AWS vers on-premise)

resource "aws_route53_resolver_endpoint" "outbound" {
  name      = "${var.project_name}-outbound"
  direction = "OUTBOUND"

  security_group_ids = [aws_security_group.resolver.id]

  ip_address {
    subnet_id = var.private_subnet_ids[0]
  }

  ip_address {
    subnet_id = var.private_subnet_ids[1]
  }

  tags = {
    Name = "${var.project_name}-resolver-outbound"
  }
}

Forwarding Rule vers le DNS on-premise

resource "aws_route53_resolver_rule" "forward_onprem" {
  domain_name          = var.onprem_domain
  name                 = "${var.project_name}-forward-onprem"
  rule_type            = "FORWARD"
  resolver_endpoint_id = aws_route53_resolver_endpoint.outbound.id

  target_ip {
    ip   = var.onprem_dns_servers[0]
    port = 53
  }

  target_ip {
    ip   = var.onprem_dns_servers[1]
    port = 53
  }

  tags = {
    Name = "${var.project_name}-forward-to-onprem"
  }
}

resource "aws_route53_resolver_rule_association" "forward_onprem" {
  resolver_rule_id = aws_route53_resolver_rule.forward_onprem.id
  vpc_id           = var.vpc_id
}

Variables

variable "vpc_id" {
  description = "ID du VPC"
  type        = string
}

variable "private_subnet_ids" {
  description = "IDs des subnets prives (min 2, AZ differentes)"
  type        = list(string)
}

variable "onprem_cidr" {
  description = "CIDR du reseau on-premise"
  type        = string
}

variable "onprem_domain" {
  description = "Domaine DNS on-premise (ex: monentreprise.local)"
  type        = string
}

variable "onprem_dns_servers" {
  description = "IPs des serveurs DNS on-premise"
  type        = list(string)
}

variable "project_name" {
  description = "Prefixe pour le nommage des ressources"
  type        = string
  default     = "hybrid-dns"
}

Outputs utiles

output "inbound_endpoint_ips" {
  description = "IPs de l'inbound endpoint (a configurer dans le DNS on-premise)"
  value       = aws_route53_resolver_endpoint.inbound.ip_address[*].ip
}

output "outbound_endpoint_id" {
  description = "ID de l'outbound endpoint"
  value       = aws_route53_resolver_endpoint.outbound.id
}

Exemple de tfvars

vpc_id             = "vpc-0abc123def456789"
private_subnet_ids = ["subnet-aaa111", "subnet-bbb222"]
onprem_cidr        = "192.168.0.0/16"
onprem_domain      = "monentreprise.local"
onprem_dns_servers = ["192.168.1.10", "192.168.1.11"]
project_name       = "prod-hybrid"

Apres terraform apply, notez les IPs de l’inbound endpoint dans l’output. Vous en aurez besoin pour configurer le forwarding cote on-premise.

Configurer le DNS on-premise (BIND / Active Directory)

Avec BIND

Ajoutez une zone de forwarding dans named.conf.local pour router les requetes des zones AWS vers l’inbound endpoint :

zone "vpc.internal" {
    type forward;
    forward only;
    forwarders {
        10.0.1.45;   # IP inbound endpoint AZ-a
        10.0.2.67;   # IP inbound endpoint AZ-b
    };
};

zone "eu-west-3.compute.internal" {
    type forward;
    forward only;
    forwarders {
        10.0.1.45;
        10.0.2.67;
    };
};

Puis rechargez BIND :

sudo systemctl reload named

Avec Active Directory DNS

Dans la console DNS Manager de Windows Server :

1. Clic droit sur « Conditional Forwarders » puis « New Conditional Forwarder »
2. Domaine DNS : vpc.internal
3. Ajouter les IPs de l’inbound endpoint Route 53
4. Cocher « Store this conditional forwarder in Active Directory » si vous avez plusieurs DC
5. Repeter pour chaque zone AWS a resoudre

Tests et validation de la resolution hybride

Depuis une instance EC2 (resolution vers on-premise)

# Test de resolution d'un nom on-premise depuis le VPC
dig erp.monentreprise.local

# Verifier que la reponse vient bien du resolver VPC
dig erp.monentreprise.local +trace

# Test avec nslookup
nslookup ad.monentreprise.local

Depuis un serveur on-premise (resolution vers AWS)

# Test de resolution d'un nom AWS prive depuis on-premise
dig mon-service.vpc.internal @192.168.1.10

# Verifier la latence
dig mon-service.vpc.internal +stats | grep "Query time"

Erreurs courantes et depannage

Checklist mise en production

Si vous cherchez un accompagnement pour l’infogerance de votre infrastructure hybride, je peux vous aider a mettre en place cette architecture et la maintenir dans la duree.

Combien coute Route 53 Resolver ?

Le pricing de Route 53 Resolver est base sur deux elements :

• Endpoints : environ 0.125 USD/heure par ENI (soit ~90 USD/mois pour un endpoint a 2 ENI)
• Requetes DNS : pas de cout additionnel par requete pour les resolver endpoints

Pour une configuration standard (1 inbound + 1 outbound, 2 ENI chacun), comptez environ 180 USD/mois. C’est un cout fixe, previsible, et independant du volume de requetes. Comparez avec le temps ingenieur perdu a maintenir des fichiers /etc/hosts en dur sur 50 serveurs.

Aller plus loin : multi-VPC et RAM

Si vous avez plusieurs VPC (environnements dev/staging/prod), vous n’avez pas besoin de deployer des endpoints dans chaque VPC. Utilisez AWS Resource Access Manager (RAM) pour partager les forwarding rules :

resource "aws_ram_resource_share" "dns_rules" {
  name                      = "shared-dns-rules"
  allow_external_principals = false
}

resource "aws_ram_resource_association" "forward_rule" {
  resource_arn       = aws_route53_resolver_rule.forward_onprem.arn
  resource_share_arn = aws_ram_resource_share.dns_rules.arn
}

resource "aws_ram_principal_association" "other_account" {
  principal          = var.target_account_id
  resource_share_arn = aws_ram_resource_share.dns_rules.arn
}

Les autres VPC/comptes peuvent ensuite associer la regle partagee a leur propre VPC.

FAQ