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 de ponta a ponta: como organizar zonas hospedadas, definir registros com critério, restringir quais autoridades podem emitir certificados para o seu domínio, proteger o e-mail com SPF, DKIM e DMARC, decidir quando habilitar DNSSEC e fechar o controle de acesso e a auditoria das mudanças. 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 acabam registradas em logs de terceiros. Quando o mesmo nome precisa resolver por dentro e por fora com respostas diferentes, o padrão é o split-horizon: uma zona privada e uma pública com o mesmo domínio, cada uma com os registros do seu contexto.
Em ambientes com várias contas, uma zona privada pode ser associada a VPCs de outras contas por meio do Resource Access Manager, o que centraliza a resolução interna sem duplicar zonas. Mantenha essa associação restrita às contas que de fato precisam resolver aqueles nomes, para não ampliar o alcance da zona interna sem necessidade.
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. Planeje essa redução com pelo menos o TTL antigo de antecedência, porque resolvedores em cache ainda respondem com o valor anterior até ele expirar.
Registros essenciais e o registro CAA
Boa parte da segurança de DNS está em escolher o tipo de registro certo. Para apontar a raiz do domínio a um recurso da AWS, como CloudFront, ALB ou um bucket de site estático, use um registro alias em vez de CNAME: o alias funciona no ápice da zona, resolve para o recurso sem um salto extra de consulta e acompanha mudanças de endereço do serviço. O CNAME não pode existir na raiz e adiciona uma etapa de resolução.
O registro CAA é um controle de segurança subutilizado. Ele declara quais autoridades certificadoras estão autorizadas a emitir certificados para o domínio. Sem CAA, qualquer CA pública pode emitir um certificado válido para o seu nome, o que amplia o risco de emissão indevida. Com CAA, você restringe a emissão às autoridades que realmente usa, como a da AWS para o ACM, e ainda pode receber notificação de tentativas fora da política.
CAA @ 0 issue "amazon.com"
CAA @ 0 issuewild "amazon.com"
CAA @ 0 iodef "mailto:seguranca@seu-dominio"Ajuste a autoridade conforme quem emite os seus certificados e inclua todas as CAs legítimas antes de publicar, para não bloquear uma renovação. O campo iodef indica um endereço para onde a CA envia relatório de tentativas que violam a política, o que dá visibilidade sobre pedidos de emissão inesperados.
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.
Alinhamento, relatórios e domínios parkados
O DMARC só considera uma mensagem autenticada quando há alinhamento: o domínio que aparece no campo De precisa combinar com o domínio validado por SPF ou por DKIM. É por isso que apenas publicar SPF não basta; sem alinhamento, o remetente ainda pode ser falsificado. Os relatórios agregados chegam ao endereço em rua e mostram quais fontes enviam em nome do domínio, o que revela tanto serviços legítimos esquecidos quanto tentativas de abuso.
Domínios e subdomínios que não enviam e-mail também precisam de proteção. Publique neles um SPF que recusa qualquer origem e um DMARC em reject, para que ninguém consiga forjar mensagens a partir de um domínio parkado. Esse é um dos ajustes de maior retorno e menor esforço na proteção de marca.
DNSSEC: quando habilitar
O DNSSEC assina as respostas DNS e protege contra envenenamento de cache e respostas forjadas. No Route 53 ele é configurável por zona, usa uma chave de assinatura de chave guardada no KMS e exige publicar o registro DS no registrador do domínio para completar a cadeia de confiança. É um controle valioso, mas exige rotina de gestão de chaves: uma falha na KSK ou um DS desatualizado pode tornar o domínio inteiro irresolvível para resolvedores que validam.
Nem todo TLD suporta DNSSEC, e a proteção só age para resolvedores que validam assinaturas. Por isso ele faz mais sentido em domínios críticos e de alto valor, habilitado como mudança planejada e monitorada, com alerta para expiração de assinatura. Para muitos cenários, SPF, DKIM, DMARC e CAA bem configurados entregam um ganho maior com risco operacional menor.
Subdomínios órfãos e takeover
O risco mais subestimado do DNS são os subdomínios órfãos. Quando um registro, em geral um CNAME, aponta para um recurso que foi removido, como um bucket, uma distribuição do CloudFront ou um serviço SaaS desprovisionado, o endereço de destino fica livre para ser reivindicado. Um atacante que registra aquele mesmo recurso passa a responder pelo seu subdomínio e o usa para phishing convincente, servido a partir de um nome que é de fato seu.
A defesa é inventário e disciplina de remoção. Ao desativar um recurso, remova antes o registro que aponta para ele, nessa ordem. Revise periodicamente a zona cruzando cada apontamento com os recursos que existem de verdade, com atenção especial aos CNAMEs para serviços de terceiros. Habilitar o log de consultas do Route 53 Resolver ajuda a enxergar quais nomes ainda são consultados, o que orienta tanto a limpeza quanto a investigação.
Controle de acesso, failover e auditoria
DNS é infraestrutura crítica, então quem pode alterá-lo deve ser um grupo restrito. Limite a permissão de alterar registros ao mínimo necessário, de preferência escopada por zona, e trate qualquer mudança como uma alteração revisada. Toda operação no Route 53 fica registrada no CloudTrail, o que permite reconstruir quem mudou o quê e quando, essencial em uma investigação de configuração suspeita.
Para disponibilidade, o Route 53 oferece health checks associados a políticas de roteamento. Com failover, o tráfego migra para um destino secundário quando o primário fica indisponível; com roteamento por latência ou por peso, você distribui a carga e prepara migrações graduais. Combinados com o log de consultas encaminhado para análise, esses recursos sustentam tanto a resiliência quanto a detecção de padrões anômalos de resolução.
Checklist prático
- Separar claramente zonas públicas e privadas e associar a zona privada só às VPCs necessárias
- Preferir registros alias a CNAME para recursos AWS, sobretudo na raiz do domínio
- Publicar registro CAA restringindo quais autoridades podem emitir certificados
- 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
- Proteger domínios parkados com SPF -all e DMARC em 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)
- Habilitar o log de consultas do Resolver para inventário e detecção
- 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.
Para que serve o registro CAA e devo publicá-lo?
O registro CAA define quais autoridades certificadoras podem emitir certificados para o seu domínio. Sem ele, qualquer CA pública pode emitir um certificado válido para o seu nome, o que aumenta o risco de emissão indevida. Vale publicar em praticamente todos os domínios: liste as autoridades que você realmente usa e adicione o campo iodef para receber aviso de tentativas fora da política. O cuidado é incluir todas as CAs legítimas antes de publicar, para não bloquear uma renovação.
Como faço failover de DNS no Route 53?
Você cria health checks que monitoram a saúde do destino e os associa a registros com política de roteamento de failover. Enquanto o destino primário responde saudável, o Route 53 entrega o endereço primário; quando o health check falha, ele passa a responder com o secundário. Reduzir o TTL desses registros faz a troca propagar mais rápido. Para distribuir carga ou preparar migrações, as políticas por latência e por peso complementam esse desenho.
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.