Il DNS (Domain Name System) è la rubrica telefonica di internet: traduce un nome leggibile dall'uomo come example.com in un indirizzo IP come 93.184.216.34. La risoluzione è un lookup gerarchico, di solito eseguito per te da un recursive resolver (quello del tuo ISP o uno pubblico come 8.8.8.8) che percorre l'albero dei name server per tuo conto:
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
Il resolver interroga i server root (che conoscono i server TLD), poi i server TLD per .com (che sanno chi è authoritative per example.com), poi il server authoritative (che detiene il record effettivo). Per evitare di ripetere tutto questo ogni volta, i risultati vengono messi in cache a ogni livello — browser, OS e resolver — rispettando ciascuno il TTL (time-to-live) del record. Una cache calda risolve in microsecondi; un lookup a freddo può costare diversi round trip.
Tipi di record comuni: A (name → IPv4), AAAA (name → IPv6), CNAME (alias verso un altro nome), MX (mail server), TXT (testo arbitrario, usato per SPF/verifica) e NS (delega una zona). Puoi ispezionare direttamente la risoluzione:
dig example.com A # shows the A record and which server answered
Il DNS si trova sul percorso critico di ogni richiesta che parte da un nome, quindi un resolver lento o mal configurato aggiunge latenza a tutto. Chi conduce il colloquio ama questa domanda perché rivela se capisci gerarchia e caching — le due idee che permettono a un sistema distribuito globale di rispondere a miliardi di query velocemente. È anche una frequente fonte di incidenti reali in produzione ("è sempre il DNS"): record scaduti, TTL errati o ritardi di propagazione dopo una modifica, quindi sapere come funzionano caching e TTL è di diretta utilità pratica.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona