APRENDER. PRATICAR. EVOLUIR.1. Desenhar a autoridade antes dos endpoints
Uma aplicação financeira fictícia mudou para AWS, mas o servidor files.corp.bank.test continua no centro de dados. O desenho deve dizer quem responde por corp.bank.test e quem responde por aws.bank.test. Não basta escrever “DNS híbrido” num diagrama. Para cada namespace, regista origem dos consumidores, autoridade, direção de encaminhamento, VPCs abrangidas e responsável. O objetivo do exercício é fazer a consulta terminar na autoridade certa sem perder a separação entre ambientes. Um IP de aplicação e um IP de servidor DNS têm funções diferentes; apontar o encaminhamento condicional para o primeiro não torna a aplicação autoritativa.
2. Escolher o sentido e a associação
Para clientes locais consultarem uma private hosted zone associada à VPC de resolução, desenha entrada por inbound endpoint e conectividade privada até aos seus IPs. Para clientes AWS consultarem a autoridade local de corp.bank.test, desenha uma regra outbound com targets DNS locais. A regra precisa de estar associada às VPCs consumidoras. Se funciona em Apps-A e não em Apps-B, verifica a associação de B antes de duplicar endpoints. Uma associação seleciona o encaminhamento aplicável; não cria rotas VPN, permissões ou um servidor disponível. Distingue estes passos no diagnóstico para não corrigir registos quando falta apenas uma associação.
3. Percorrer um ciclo sem gerar tráfego
Usa o quadro abaixo como exercício de mesa. A consulta files.corp.bank.test sai do contexto VPC pela regra corp.bank.test. O DNS local encaminha esse mesmo sufixo de volta ao inbound da mesma VPC, onde encontra novamente a regra. A sequência repete-se sem chegar à autoridade local. Marca cada par contexto/namespace visitado; quando um par reaparece, encontraste um ciclo no modelo. Corrige o encaminhamento local para a autoridade apropriada e repete o percurso. Aumentar timeouts ou mudar UDP para TCP mantém a dependência circular. Este modelo não representa cache, delegação, DNSSEC nem todas as regras de precedência do serviço.
4. Diagnosticar transporte e origem efetiva
No encaminhamento outbound, o DNS local observa os IPs de origem do endpoint, não necessariamente o IP original da aplicação. Uma ACL que permite apenas o CIDR da aplicação pode bloquear essas consultas. Confirma os IPs efetivos, os destinos autorizados e o caminho de retorno antes de alargar regras. Nos exercícios desta aula, DNS convencional usa UDP e TCP na porta 53. Uma consulta curta bem-sucedida por UDP não prova a via TCP que outras respostas podem exigir. Ensaios reais precisam de autorização, destino conhecido e registo do resultado. O quadro local apenas identifica o controlo a rever; não abre portas nem envia consultas.
5. Demonstrar redundância utilizável
Dois IPs em AZs diferentes não bastam quando a origem só consegue alcançar um. Para um inbound endpoint, verifica que as origens autorizadas chegam a ambos os IPs e que o encaminhador local consegue usar a alternativa. Para outbound, a AWS descreve seleção aleatória entre os targets DNS; a posição na lista não cria uma relação fixa de primário e secundário. No caso do batch, 10.30.1.10 responde e 10.30.2.10 está bloqueado. Corrige esse caminho e ensaia os dois. Não deduzas uma taxa de 50% de falhas apenas por haver dois targets: retries, tempos e comportamento observado precisam de medição.
6. Preparar o handover com evidência delimitada
Entrega a RUN um mapa de namespaces, associações, endpoints, caminhos, responsáveis e testes positivos e negativos. Inclui o que fazer quando só um target responde e quem pode aprovar uma exceção temporária de redundância. Na oficina, explica a causa do ciclo, a configuração a rever e o resultado esperado após a correção. Na operação, recolhe evidência a partir da origem real e confirma resolução e função da aplicação. Um nome resolvido não prova que o batch concluiu. O resumo para o gestor técnico deve separar modelo revisto, conectividade ensaiada e resultado funcional observado, mantendo pendentes identificados em vez de os converter em garantias.
namespace: corp.bank.test
VPC -> OUTBOUND -> ONPREM -> INBOUND -> VPC [cycle]
VPC -> OUTBOUND -> ONPREM -> AUTHORITY [terminates]O modelo VPC→OUTBOUND→ONPREM→INBOUND→VPC repete um contexto; com ONPREM→AUTHORITY termina. Não executa AWS.
Armadilhas comuns
Ordem de targets como prioridade; associação como conectividade; duas interfaces como failover provado; resolução como batch concluído.
Tópicos relacionados: Transit Gateway e retorno · Diagnóstico com evidência
Identifica autoridade, direção, associação, origem efetiva e caminho antes de alterar o DNS.
Referência: VPC Resolver outbound forwarding · ANS-C01