DNS e Resolucao de Nomes
Video da aula estara disponivel em breve
O que e DNS?
O DNS (Domain Name System) e o sistema que traduz nomes de dominio legíveis por humanos (como google.com) em enderecos IP legiveis por maquinas (como 142.250.218.14). E essencialmente a "lista telefonica" da Internet.
Sem DNS, voce teria que memorizar enderecos IP para acessar qualquer site. DNS e um dos servicos mais criticos da Internet — se o DNS falhar, a Internet efetivamente "para" para os usuarios.
Hierarquia DNS
Diagrama
. (root)
/ | \
/ | \
.com .org .br
/ \ |
google github .com.br
| | |
www docs neon
(neon.com.br? -> neon.tech)
Hierarquia de servidores DNS:
1. Root servers (13 clusters, ex: a.root-servers.net)
Sabem onde estao os TLD servers
2. TLD servers (Top-Level Domain: .com, .org, .br, .tech)
Sabem onde estao os servidores autoritativos
3. Authoritative servers (ex: ns1.google.com)
Tem os registros finais (A, AAAA, CNAME, MX...)Processo de resolucao
Diagrama
Voce digita: neon.tech
1. Browser: "Qual e o IP de neon.tech?"
--> Verifica cache local do browser
--> Verifica cache do SO (/etc/hosts, DNS cache)
2. Se nao encontrou: pergunta ao DNS Resolver (ISP ou 8.8.8.8)
Resolver: "Nao sei. Vou perguntar."
3. Resolver --> Root Server: "Quem cuida de .tech?"
Root: "Pergunte ao TLD server de .tech: ns1.nic.tech"
4. Resolver --> TLD Server (.tech): "Quem cuida de neon.tech?"
TLD: "Pergunte ao autoritativo: ns1.neon.tech (IP: x.x.x.x)"
5. Resolver --> Autoritativo (neon.tech): "Qual o IP de neon.tech?"
Autoritativo: "A record: 76.76.21.21, TTL: 3600"
6. Resolver cacheia a resposta por 3600 segundos (TTL)
Retorna para o browser: "neon.tech = 76.76.21.21"
7. Browser conecta via TCP ao IP 76.76.21.21 na porta 443 (HTTPS)
Recursivo vs. Iterativo
O resolver faz queries iterativas — pergunta a cada servidor e recebe um apontamento para o proximo. O cliente faz uma query recursiva ao resolver — pede a resposta final e espera. O resolver faz todo o trabalho.
Tipos de registros DNS
Referencia
Tipo Funcao Exemplo
────── ────────────────────────────────── ──────────────────────────
A Nome -> IPv4 neon.tech -> 76.76.21.21
AAAA Nome -> IPv6 google.com -> 2607:f8b0:...
CNAME Alias (nome -> nome) www.neon.tech -> neon.tech
MX Mail server gmail.com -> alt1.gmail-smtp-in.l.google.com
TXT Texto arbitrario SPF, DKIM, verificacao
NS Nameserver autoritativo neon.tech -> ns1.neon.tech
SOA Start of Authority (metadata) Serial, refresh, retry
PTR IP -> Nome (DNS reverso) 76.76.21.21 -> neon.techDNS na pratica com Python
Python
import socket
# Resolucao basica com socket
ip = socket.gethostbyname("neon.tech")
print(f"neon.tech -> {ip}")
# Resolucao completa com getaddrinfo (suporta IPv6)
results = socket.getaddrinfo("google.com", 443)
for family, socktype, proto, canonname, sockaddr in results:
print(f" {socket.AddressFamily(family).name}: {sockaddr[0]}")
Python
# Usando dnspython para queries detalhadas
# pip install dnspython
import dns.resolver
# Query A record
answers = dns.resolver.resolve("neon.tech", "A")
for rdata in answers:
print(f"A: {rdata}")
# Query MX records
answers = dns.resolver.resolve("gmail.com", "MX")
for rdata in answers:
print(f"MX: priority={rdata.preference} server={rdata.exchange}")
# Query TXT records
answers = dns.resolver.resolve("google.com", "TXT")
for rdata in answers:
print(f"TXT: {rdata}")Caching e TTL
DNS depende fortemente de caching para performance. Cada registro DNS tem um TTL (Time To Live) que indica por quanto tempo o resultado pode ser cacheado. Quando o TTL expira, uma nova query e necessaria.
TTL trade-offs
TTL baixo (ex: 60s): mudancas propagam rapido, mas mais queries DNS. TTL alto (ex: 86400s = 1 dia): menos queries, mas mudancas demoram a propagar. Para servicos criticos que podem precisar de failover rapido, use TTL baixo.
No harness.os
O harness.os tem seu proprio "DNS" — a resolucao de project slugs:
Diagrama
DNS Internet: "DNS" harness.os:
──────────────── ────────────────────────
Domain name Project slug
"neon.tech" "build-ai"
| |
v v
DNS Resolver schema_reference table
(cache + lookup) (cache + lookup)
| |
v v
IP Address Project UUID + Neon connection
"76.76.21.21" "uuid-xxx" + "postgresql://..."
| |
v v
TCP connection MCP tool calls to correct project
(HTTP request) (scoped to project context)
Resolucao no harness.os:
SELECT project_id, neon_project_id
FROM projects
WHERE slug = 'build-ai';
Resultado: project_id = 'abc-123', neon_project = 'purple-cell-95681470'
Equivale a: build-ai -> abc-123 -> purple-cell-95681470
(slug -> UUID -> connection string)
Identico a: neon.tech -> DNS -> 76.76.21.21 -> TCP connectResumo
- DNS traduz nomes de dominio em enderecos IP
- Hierarquia: root servers -> TLD servers -> authoritative servers
- Resolucao: recursiva (cliente -> resolver) e iterativa (resolver -> servidores)
- Registros: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), TXT (texto)
- Caching com TTL reduz latencia e carga nos servidores DNS
Exercicio pratico
Projete um "harness DNS" para o mesh.
- Como o mesh deveria resolver project slugs para harness instances?
- Qual seria o equivalente de registros A, CNAME e MX no mesh?
- Onde ficaria o cache? Qual TTL seria apropriado?
- O que acontece quando uma instancia muda de endereco (redeploy no Fly.io)?
- Implemente uma funcao Python
resolve_slug(slug)que consulta o banco
Verifique seu entendimento
Em que ordem o DNS resolver consulta os servidores durante uma resolucao iterativa?