DNS (Domain Name System) is het telefoonboek van het internet: het vertaalt een door mensen leesbare naam als example.com naar een IP-adres als 93.184.216.34. Resolutie is een hiërarchische lookup, meestal voor je gedaan door een recursive resolver (die van je ISP of een publieke zoals 8.8.8.8) die namens jou de boom van authoritative name servers afloopt:
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
De resolver vraagt de root-servers (die de TLD-servers kennen), dan de TLD-servers voor .com (die weten wie authoritative is voor example.com), dan de authoritative server (die het daadwerkelijke record bevat). Om dit niet elke keer te herhalen, worden resultaten op elk niveau gecachet — browser, OS en resolver — elk met respect voor de TTL (time-to-live) van het record. Een warme cache resolvet in microseconden; een koude lookup kan meerdere round trips kosten.
Veelvoorkomende record types: A (naam → IPv4), AAAA (naam → IPv6), CNAME (alias naar een andere naam), MX (mailservers), TXT (willekeurige tekst, gebruikt voor SPF/verificatie), en NS (delegeert een zone). Je kunt de resolutie direct inspecteren:
dig example.com A # toont het A-record en welke server antwoordde
DNS ligt op het kritieke pad van elke request die vanuit een naam begint, dus een trage of verkeerd geconfigureerde resolver voegt aan alles latency toe. Interviewers houden van deze vraag omdat ze onthult of je hiërarchie en caching begrijpt — de twee ideeën die een globaal, gedistribueerd systeem miljarden queries snel laten beantwoorden. Het is ook een frequente bron van echte productie-incidenten ("het is altijd DNS"): verlopen records, verkeerde TTL's, of propagatievertragingen na een wijziging, dus weten hoe caching en TTL werken is direct praktisch.
Een bibliotheek met IT-sollicitatievragen met gedetailleerde antwoorden — van Junior tot Senior.
Doneren