O Que É DNS? A Agenda de Endereços da Internet
O DNS, o Domain Name System, é a agenda de endereços da internet que transforma um hostname como api.example.com no endereço IP ao qual um cliente de fato se conecta.
Os computadores roteiam tráfego usando endereços IP numéricos, mas as pessoas e os arquivos de configuração usam nomes. O DNS faz a ponte entre os dois resolvendo nomes em endereços sob demanda. Todo pipeline que busca uma dependência, faz o pull de uma imagem ou chama uma API primeiro faz uma consulta DNS, o que torna o DNS uma fonte discreta mas frequente de instabilidade em CI.
Como funciona uma consulta
Um cliente pede a um resolver o endereço de um hostname. O resolver percorre a hierarquia do DNS, da raiz ao top-level domain e até o name server autoritativo, e então retorna a resposta. Os resultados ficam em cache por um time-to-live para que consultas repetidas sejam rápidas.
Tipos de registro comuns
- Registros A e AAAA mapeiam um nome para um endereço IPv4 ou IPv6.
- Registros CNAME criam um alias de um nome para outro.
- Registros MX apontam para servidores de e-mail.
- Registros TXT guardam dados de verificação e de política.
Cache e TTL
Cada registro carrega um TTL que informa aos resolvers por quanto tempo mantê-lo em cache. TTLs curtos fazem as mudanças se propagarem rapidamente, mas aumentam o volume de consultas; TTLs longos são eficientes, mas lentos para atualizar.
DNS em CI/CD
Se a resolução DNS falha, um job não consegue nem abrir uma conexão: ele dá erro antes de qualquer requisição HTTP ser enviada. Trocar o alvo de um deploy para um novo host frequentemente exige uma mudança de DNS, e o pipeline pode falhar até que essa mudança se propague.
Por que erros de DNS parecem instáveis
Os resolvers ocasionalmente dão timeout ou retornam respostas desatualizadas, especialmente logo após uma mudança de registro. Um job que falhou com "could not resolve host" pode passar na próxima execução sem nenhuma mudança de código, o que é a assinatura clássica de uma instabilidade transitória de DNS.
Lidando com isso nos runners
Runners confiáveis usam resolvers estáveis e timeouts razoáveis. Na Latchkey, falhas intermitentes de resolução para endpoints comuns são repetidas automaticamente, então uma única consulta instável não afunda um build que, de resto, está saudável.
Principais conclusões
- O DNS resolve nomes legíveis por humanos nos endereços IP aos quais os clientes se conectam.
- Os registros são armazenados em cache por um TTL, então as mudanças levam tempo para se propagar.
- Uma consulta que falha bloqueia um job antes de qualquer requisição HTTP, e é frequentemente transitória.