DNSSEC raggiunge .pk, ma 1.230 domini firmati attendono il DS record

DNSSEC collega ora il country-code top-level domain .pk del Pakistan alla root of trust di Internet. Le DNS Security Extensions sono controlli che consentono a un resolver di verificare che le risposte DNS siano autentiche e non siano state alterate. Tuttavia, un'analisi segnalata su CircleID da un ingegnere di EUNOMATIX ha rilevato che solo uno dei 158.561 domini .pk inclusi nel campione ha superato la validazione lungo l'intero percorso dalla root al singolo dominio.

Il cambiamento è avvenuto nell'ottobre 2026. Il 5 ottobre, .pk non aveva alcuna implementazione DNSSEC: la root zone, il livello più alto del Domain Name System, non conteneva alcun DS record per .pk; la zone .pk non pubblicava alcun DNSKEY; e non forniva prove firmate quando un nome richiesto non esisteva. DNSViz ha continuato a mostrare il dominio come insecure per tutto settembre. Il serial 2026100600 della root zone, pubblicato il 6 ottobre, e il serial 2026100901, archiviato alle 15:00 UTC del 9 ottobre, non contenevano ancora alcun DS record per .pk.

Le prime firme individuate nella zone .pk iniziavano alle 08:34 UTC dell'8 ottobre, indicando che la zone era stata firmata circa un giorno prima dell'aggiornamento della root. Entro le 22:20 UTC del 9 ottobre, DNSViz classificava .pk come secure, mentre il record IANA relativo a .pk riporta un aggiornamento in quella data. Il DS record ora presente nella root ha il key tag 34973 e corrisponde al key-signing DNSKEY fornito dai nameservers di .pk. Sedici anni dopo la firma della root stessa, la catena autenticata raggiunge quindi .pk.

La zone utilizza l'algoritmo 13, ECDSA P-256 con SHA-256, per creare e verificare le proprie firme. Per i nomi che non esistono utilizza NSEC3, un metodo per fornire una prova firmata dell'assenza di un DNS record. La configurazione NSEC3 non prevede iterazioni aggiuntive e ha un salt vuoto, in conformità con RFC 9276.

L'analisi è stata eseguita l'11 ottobre, due giorni dopo la comparsa del DS record nella root, e ha utilizzato validating resolvers, che rifiutano le risposte DNSSEC che non possono essere autenticate correttamente. Per ogni dominio sono stati richiesti il DS record conservato in .pk e il DNSKEY conservato nella zone del dominio stesso. Un nome è stato considerato completamente firmato solo quando ogni collegamento dalla root, attraverso .pk, fino a quel dominio ha superato la validazione.

Solo newspak.pk ha superato il test. Disponeva sia di un DS record in .pk sia di una zone del dominio firmata e corrispondente. Nessuno dei circa 1.360 nomi esaminati sotto gov.pk e i suffissi dei governi provinciali ha superato la validazione end-to-end.

Altri 1.230 domini, pari allo 0,78 percento del campione, pubblicavano record DNSKEY e firmavano le proprie zone, ma non disponevano di un DS record nella zone parent .pk. Quando un resolver interroga questi domini, .pk restituisce prove NSEC3 firmate del fatto che non esiste alcun DS. Di conseguenza, il resolver tratta il dominio come non firmato, anche se l'operatore del dominio ha creato le firme. Tra gli esempi figuravano accenture.pk, nexlinx.net.pk, 7dayz.com.pk e agajk.gov.pk.

Questi 1.230 domini erano distribuiti tra i principali suffissi .pk: 759 direttamente sotto .pk, 317 sotto com.pk, 58 sotto edu.pk, 40 sotto org.pk, 28 sotto gov.pk e 17 sotto net.pk. Tra i nomi rimanenti, 117.572, pari al 74 percento, non erano firmati; 25.875 non esistevano più; e 13.883 non hanno potuto essere classificati perché i loro nameservers sono andati in timeout o non erano raggiungibili.

Un DS record è il fingerprint della key DNSSEC di un dominio. Il proprietario del dominio o il provider DNS crea il materiale crittografico e firma la zone, ma il registry parent deve pubblicare il DS record. Senza questa voce lato parent, non esiste alcun collegamento autenticato con la root e i validating resolvers non hanno alcuna base per considerare attendibili le firme del dominio.

Per la maggior parte dei top-level domains, i titolari inviano le informazioni DS tramite un registrar. L'implementazione può bloccarsi quando un proprietario non sa che questo passaggio separato è necessario, quando un registrar non accetta l'invio di DS record o quando la procedura disponibile è manuale e soggetta a errori. Il record richiede attenzione anche quando un provider modifica il proprio materiale DNSSEC o un dominio viene trasferito a un altro provider. Un DS record obsoleto o errato può far apparire il dominio bogus ai validating resolvers, rendendolo potenzialmente irraggiungibile attraverso di essi.

Il risultato è più estremo rispetto al modello rilevato in uno studio USENIX Security del 2017 su .com, .net e .org, nel quale circa il 30 percento dei domini firmati era privo di un DS record nel parent e il divario era concentrato presso un numero limitato di operatori. In .pk, il percorso amministrativo è relativamente concentrato perché com.pk, org.pk, edu.pk e gov.pk non sono zone delegate separatamente. Rimangono all'interno di .pk, quindi una sola organizzazione pubblicherebbe tutti i DS record interessati dall'analisi.

L'analisi identifica i 1.230 domini già firmati come l'opportunità immediata. I loro record DNSKEY sono pubblici, consentendo al registry o ai registrar di contattare i proprietari e organizzare la pubblicazione dei DS record corrispondenti. Secondo l'analisi, completare questo lavoro potrebbe aumentare di oltre mille volte, nel giro di poche settimane, il numero di domini .pk che superano la validazione.

Tra le opzioni a più lungo termine figurano l'accettazione delle informazioni DS dai registrar tramite EPP, l'Extensible Provisioning Protocol utilizzato per gestire i record dei domini, seguendo RFC 5910. Il supporto per CDS e CDNSKEY secondo RFC 7344 e RFC 8078 potrebbe automatizzare una parte maggiore del processo, consentendo a un dominio firmato di pubblicare le informazioni DS che desidera siano utilizzate dal proprio parent. RFC 10026 fornisce recenti indicazioni sulle best practice per questo approccio.

L'analisi raccomanda inoltre una DNSSEC Practice Statement che spieghi come il registry crea e protegge il proprio materiale di firma, con quale frequenza lo modifica e come saranno gestite le emergenze. RFC 6841 definisce questo tipo di statement, mentre RFC 6781 fornisce indicazioni operative. Lo statement di .se viene citato come modello, mentre i problemi di rollover che hanno interessato .de nel 2026 e .nz nel 2023 illustrano l'importanza operativa di procedure documentate.

Una misurazione separata dell'infrastruttura effettuata il 5 ottobre ha rilevato che nessuno dei quattro nameservers pubblici di .pk si trovava in Pakistan. Due utilizzavano il servizio anycast di CIRA, che serve lo stesso indirizzo da più località, mentre un server si trovava a Singapore e un altro nei Paesi Bassi. I round-trip time misurati da Lahore e Islamabad variavano da 130 a 263 millisecondi. I due server privi di anycast non disponevano inoltre di indirizzi IPv6. L'analisi raccomanda di aggiungere un nameserver all'interno del Pakistan e il supporto IPv6 a ogni server.

I risultati rimangono un'istantanea anziché un censimento completo. Alcuni dei 1.230 domini potrebbero aver ottenuto DS record dopo l'11 ottobre. La zone .pk non consente zone transfer e non viene resa pubblica, quindi non è possibile confermare che il campione costituisca un elenco completo. Inoltre, quasi il 9 percento dei nomi inclusi nel campione è rimasto senza classificazione perché i relativi nameservers non erano disponibili; alcuni potrebbero essere firmati.

I proprietari di siti web che utilizzano .pk dovrebbero quindi verificare entrambe le componenti di DNSSEC: le firme presso il proprio provider DNS e una voce DS corrispondente presso il registrar o il registry.