Configurando Route 53 com boas práticas de segurança e DNS
Como estruturar zonas, registros e proteção de e-mail no Route 53 para reduzir exposição, sequestro de subdomínio e falhas de entrega.
O Route 53 é o serviço de DNS gerenciado da AWS e, por ser a porta de entrada de praticamente todo o tráfego, qualquer erro de configuração tem impacto direto em disponibilidade, entrega de e-mail e segurança. DNS mal configurado raramente aparece em um scanner tradicional, mas é uma das causas mais comuns de incidentes silenciosos: um registro apontando para um recurso que não existe mais, um subdomínio órfão que pode ser sequestrado ou um SPF que deixa qualquer servidor enviar e-mail em nome do domínio.
Este guia trata da configuração defensiva do Route 53: como organizar zonas hospedadas, definir registros com critério, proteger o domínio de e-mail com SPF, DKIM e DMARC, e quando faz sentido habilitar DNSSEC. O foco não é apenas funcionar, mas reduzir a superfície de risco e manter a configuração auditável ao longo do tempo.
Zonas hospedadas: pública e privada
Uma zona hospedada pública responde consultas na internet; uma zona privada responde apenas dentro das VPCs associadas. Misturar os dois papéis é um erro comum: nomes internos acabam expostos publicamente ou registros públicos deixam de resolver dentro da rede. Separe claramente o que é interno do que é externo e associe a zona privada somente às VPCs que realmente precisam dela.
Para nomes internos, evite reaproveitar o domínio público. Um subdomínio dedicado para uso interno reduz a chance de vazar topologia e nomes de serviços sensíveis em consultas DNS, que muitas vezes são registradas em logs de terceiros.
TTL e propagação
TTL alto melhora cache e reduz custo de consultas, mas atrasa mudanças e failover. Antes de uma migração planejada, reduza o TTL com antecedência (por exemplo, para 60 segundos) para que a troca seja rápida, e só então execute a mudança. Depois de estabilizar, volte o TTL para um valor maior.
Proteção de e-mail: SPF, DKIM e DMARC
A maioria dos abusos de domínio começa por e-mail forjado. Três registros trabalham juntos: SPF declara quais servidores podem enviar em nome do domínio, DKIM assina as mensagens e DMARC define a política de tratamento quando SPF ou DKIM falham, além de habilitar relatórios.
TXT @ "v=spf1 include:_spf.seu-provedor.com -all"
TXT _dmarc "v=DMARC1; p=quarantine; rua=mailto:dmarc@seu-dominio; fo=1"
TXT selector._domainkey "v=DKIM1; k=rsa; p=CHAVE_PUBLICA_DKIM"Comece o DMARC em p=none apenas para coletar relatórios, analise as fontes legítimas e só então avance para quarantine e reject. Subir direto para reject sem observar os relatórios costuma bloquear e-mails legítimos de sistemas esquecidos, como faturamento e ferramentas internas.
DNSSEC e subdomínios órfãos
O DNSSEC assina as respostas DNS e protege contra envenenamento de cache e respostas forjadas. No Route 53 ele é configurável por zona e exige a publicação do registro DS no registrador do domínio. É um controle valioso, mas exige rotina de gestão de chaves: uma falha de KSK pode tornar o domínio inacessível, então trate a habilitação como uma mudança crítica e monitorada.
O risco mais subestimado são os subdomínios órfãos. Quando um registro CNAME aponta para um recurso que foi removido (um bucket, uma distribuição ou um serviço de terceiros), um atacante pode registrar aquele recurso e assumir o subdomínio. Revise periodicamente os registros e remova apontamentos para recursos que não existem mais.
Checklist prático
- Separar claramente zonas públicas e privadas e associar a zona privada só às VPCs necessárias
- Reduzir TTL antes de migrações planejadas e restaurar depois
- Publicar SPF com encerramento -all e revisar os includes
- Configurar DKIM com seletor próprio e rotação de chave planejada
- Iniciar DMARC em p=none, analisar relatórios e evoluir para quarantine ou reject
- Avaliar DNSSEC para domínios críticos, com rotina de gestão de chaves
- Remover registros que apontam para recursos inexistentes (subdomínios órfãos)
- Restringir quem pode alterar registros via IAM e registrar mudanças no CloudTrail
- Usar health checks para failover de registros críticos
- Documentar a finalidade de cada registro relevante
Boas práticas
- Trate alterações de DNS como mudanças críticas, com revisão e registro
- Prefira alias records para recursos AWS em vez de CNAME na raiz
- Centralize a gestão de domínios e padronize a nomenclatura de registros
- Monitore expiração de domínio e de certificados associados
- Limite permissões de route53:ChangeResourceRecordSets ao mínimo necessário
- Mantenha um inventário dos subdomínios e dos recursos para onde apontam
Erros comuns
SPF com ~all permissivo ou múltiplos registros SPF
Facilita spoofing do domínio e pode invalidar a avaliação de SPF, prejudicando entrega e reputação.
CNAME apontando para recurso já removido
Permite sequestro de subdomínio, usado para phishing convincente com o seu domínio.
TTL muito alto durante migração
Mudanças e failover demoram a propagar, prolongando indisponibilidade.
Nomes internos em zona pública
Expõe topologia e nomes de serviços sensíveis em consultas e logs públicos.
DNSSEC habilitado sem rotina de chaves
Uma falha de KSK pode tornar o domínio inteiro irresolvível.
Quando procurar apoio especializado
Se o seu ambiente tem muitos domínios, integrações de e-mail complexas ou histórico de subdomínios herdados de projetos antigos, vale uma revisão estruturada. A GUARDIASEC avalia configuração de DNS, exposição e proteção de borda dentro do serviço de Segurança AWS e Cloud Security, priorizando o que reduz risco real.
Perguntas frequentes
O Route 53 protege contra ataques de DNS por si só?
O Route 53 é resiliente e altamente disponível, mas a proteção depende da configuração. Registros corretos, SPF, DKIM, DMARC e, quando aplicável, DNSSEC são o que reduzem spoofing, sequestro de subdomínio e respostas forjadas. O serviço entrega a infraestrutura; a postura de segurança vem da configuração.
Preciso de DNSSEC em todos os domínios?
Não. DNSSEC agrega proteção contra respostas forjadas, mas exige gestão de chaves e aumenta o risco operacional se mal administrado. Faz mais sentido em domínios críticos e de alto valor. Para muitos cenários, SPF, DKIM e DMARC bem configurados já entregam o maior ganho de segurança de e-mail.
Como descubro subdomínios órfãos?
Liste os registros da zona e cruze cada apontamento com os recursos realmente existentes, em especial CNAMEs para buckets, distribuições e serviços de terceiros. Apontamentos para recursos removidos devem ser excluídos. Uma revisão periódica desse inventário evita o sequestro de subdomínio.
Qual a diferença entre alias e CNAME no Route 53?
O alias é um tipo de registro específico da AWS que aponta para recursos como CloudFront, ALB e S3, funciona na raiz do domínio e não gera consulta adicional cobrada. O CNAME não pode ser usado na raiz e adiciona um salto de resolução. Para recursos AWS, prefira alias.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.