Como funciona a resolução de DNS?

Question

IT Interview Practice · Accepted Answer

O **DNS** (Domain Name System) é a lista telefônica da internet: ele traduz um nome legível por humanos como `example.com` num endereço IP como `93.184.216.34`. A resolução é um lookup hierárquico, geralmente feito por você por um **recursive resolver** (do seu ISP ou um público como o 8.8.8.8) que percorre a árvore de name servers **authoritative** em seu nome:

```text
Browser ──▶ Recursive Resolver ──▶ Root (.)          "ask .com's servers"
                     │        ◀──
                     ├────────▶ TLD (.com)            "ask example.com's servers"
                     │        ◀──
                     └────────▶ Authoritative         "example.com = 93.184.216.34"
                                (example.com)   ◀──
Browser  ◀── 93.184.216.34
```

O resolver pergunta aos servidores **root** (que conhecem os servidores TLD), depois aos servidores **TLD** de `.com` (que sabem quem é authoritative para `example.com`), depois ao servidor **authoritative** (que guarda o registro real). Para evitar repetir isso toda vez, os resultados são **cacheados** em cada nível — navegador, SO e resolver — cada um respeitando o **TTL** (time-to-live) do registro. Um cache quente resolve em microssegundos; um lookup frio pode custar várias idas e voltas.

**Tipos de registro** comuns: `A` (name → IPv4), `AAAA` (name → IPv6), `CNAME` (alias para outro nome), `MX` (servidores de email), `TXT` (texto arbitrário, usado para SPF/verificação) e `NS` (delega uma zone). Você pode inspecionar a resolução diretamente:

```bash
dig example.com A       # mostra o registro A e qual servidor respondeu
```

## Por que isso importa

O DNS fica no caminho crítico de *toda* requisição que começa a partir de um nome, então um resolver lento ou mal configurado adiciona latência a tudo. Os entrevistadores gostam desta pergunta porque ela revela se você entende **hierarquia e caching** — as duas ideias que permitem a um sistema global e distribuído responder bilhões de queries rapidamente. É também uma fonte frequente de incidentes reais de produção ("é sempre o DNS"): registros expirados, TTLs errados ou atrasos de propagação após uma mudança, então saber como caching e TTL funcionam é diretamente prático.

Por que isso importa

Perguntas relacionadas