Il record delle risorse DNSKEY è il fondamento crittografico del DNSSEC (Domain Name System Security Extensions). Il protocollo DNS di base è intrinsecamente non cifrato e stateless, il che lo rende altamente suscettibile al cache poisoning e allo spoofing man-in-the-middle (MitM). Il DNSSEC risolve questo problema allegando firme matematiche crittografiche alle risposte DNS. Il record DNSKEY funge da repository delle chiavi pubbliche: contiene le chiavi pubbliche codificate in Base64 che i resolver remoti usano per verificare che un payload di record A o MX provenga genuinamente dal server di nomi autoritativo e non sia stato manipolato durante il transito.

L'architettura ZSK e KSK

Un'implementazione DNSSEC standard distribuisce due chiavi distinte per bilanciare sicurezza ed efficienza operativa. La Zone Signing Key (ZSK) è una chiave crittografica più piccola e a basso overhead usata per firmare rapidamente i singoli record (A, TXT, CNAME) all'interno della zona. Poiché gestisce la firma in blocco, la ZSK viene ruotata frequentemente (es. ogni 30 giorni) per prevenire il cracking per forza bruta. La Key Signing Key (KSK) è una chiave molto più forte e rigidamente protetta, il cui unico scopo è firmare la ZSK stessa. Separando queste chiavi, gli amministratori possono ruotare la ZSK localmente sul server di nomi senza dover comunicare costantemente con il registro del TLD genitore.

La catena di fiducia e i record DS

Pubblicare un record DNSKEY nella propria zona è inutile se non esiste un percorso di fiducia verificabile fino alla radice di internet. Una volta che la KSK genera una firma, un hash matematico di quella KSK viene inviato al registrar di dominio come record DS (Delegation Signer). Il registrar pubblica questo record DS nella zona del TLD genitore (come il registro .com). Quando un resolver ricorsivo interroga il tuo dominio, recupera il record DS dal genitore per autenticare la KSK, usa la KSK per autenticare la ZSK e la ZSK per autenticare l'indirizzo IP finale. Se un anello della catena crittografica viene interrotto, la validazione fallisce completamente.

Interruzioni catastrofiche da SERVFAIL

La gestione dei record DNSKEY richiede precisione assoluta. Il DNSSEC è progettato per "fail closed". Se uno script automatico ruota la ZSK sul server ma il corrispondente record pubblico DNSKEY non viene aggiornato nella zona globale, le firme crittografiche non corrisponderanno. Gli ISP e i resolver pubblici come Google (8.8.8.8) e Cloudflare (1.1.1.1) interpreteranno questo come un cyberattacco attivo: scarteranno immediatamente la risposta DNS e restituiranno uno stato SERVFAIL fatale al client, cancellando di fatto il dominio da internet finché le chiavi non vengono sincronizzate manualmente o il DNSSEC non viene disabilitato del tutto a livello di registrar.