Condividi tramite

Panoramica di DNSSEC (anteprima)

  • Articolo

Questo articolo offre una panoramica delle estensioni DNSSEC (Domain Name System Security Extensions) e include un'introduzione alla terminologia DNSSEC. Vengono descritti i vantaggi della firma della zona DNSSEC ed esempi per la visualizzazione dei record di risorse correlati a DNSSEC. Quando si è pronti per firmare la zona DNS pubblica di Azure, vedere le procedure seguenti:

Nota

La firma della zona DNSSEC è attualmente in ANTEPRIMA.
Vedere le condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure per termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, in anteprima o in altro modo non ancora disponibili a livello generale.

Che cos'è DNSSEC?

DNSSEC è una suite di estensioni che aggiungono sicurezza al protocollo DNS (Domain Name System) consentendo la convalida delle risposte DNS come originali. Le estensioni DNSSEC consentono di verificare l'autorevolezza dell'origine e l'integrità dei dati, oltre a supportare la negazione autenticata dell'esistenza. Con DNSSEC, il protocollo DNS risulta molto meno vulnerabile a determinati tipi di attacchi, in particolare gli attacchi di spoofing DNS.

Le estensioni DNSSEC di base sono specificate nella richiesta di commenti (RFC) seguente:

  • RFC 4033: "DNS Security Introduction and Requirements"
  • RFC 4034: "Resource Records for the DNS Security Extensions"
  • RFC 4035: "Protocol Modifications for the DNS Security Extensions"

Per un riepilogo delle RFC DNSSEC, vedere RFC9364: DNS Security Extensions (DNSSEC).

Informazioni sul funzionamento di DNSSEC

Le zone DNS sono protette con DNSSEC usando un processo denominato firma della zona. La firma di una zona con DNSSEC aggiunge il supporto per la convalida senza modificare il meccanismo di base di una query e una risposta DNS. Per firmare una zona con DNSSEC, il server DNS autorevole della zona deve supportare DNSSEC.

Le firme dei record di risorse (RRSIGs) e altri record crittografici vengono aggiunti alla zona quando è firmata. La figura seguente mostra i record di risorse DNS nella zona contoso.com prima e dopo la firma della zona.

Diagramma che mostra come i record RRSIG vengono aggiunti a una zona quando è firmato con DNSSEC.

La convalida DNSSEC delle risposte DNS avviene usando queste firme digitali con una catena di attendibilità non interrotta.

Nota

I record di risorse correlati a DNSSEC non vengono visualizzati nella portale di Azure. Per altre informazioni, vedere Visualizzare i record di risorse correlati a DNSSEC.

Perché firmare una zona con DNSSEC?

La firma di una zona con DNSSEC è necessaria per la conformità con alcune linee guida per la sicurezza, ad esempio SC-20: Secure Name/Address Resolution Service.

La convalida DNSSEC delle risposte DNS può impedire tipi comuni di attacchi di hijacking DNS, noti anche come reindirizzamento DNS. Il hijack DNS si verifica quando un dispositivo client viene reindirizzato a un server dannoso usando risposte DNS non corrette (spoofed). L'avvelenamento da cache DNS è un metodo comune usato per spoofare le risposte DNS.

Un esempio di funzionamento del hijack DNS è illustrato nella figura seguente.

Diagramma che mostra il funzionamento del hijack DNS.

Risoluzione DNS normale:

  1. Un dispositivo client invia una query DNS per contoso.com a un server DNS.
  2. Il server DNS risponde con un record di risorse DNS per contoso.com.
  3. Il dispositivo client richiede una risposta da contoso.com.
  4. L'app contoso.com o il server Web restituisce una risposta al client.

Hijack DNS

  1. Un dispositivo client invia una query DNS per contoso.com a un server DNS dirottato.
  2. Il server DNS risponde con un record di risorse DNS non valido (spoofed) per contoso.com.
  3. Il dispositivo client richiede una risposta per contoso.com da un server dannoso.
  4. Il server dannoso restituisce una risposta spoofed al client.

Il tipo di record di risorse DNS di cui è stato eseguito lo spoofing dipende dal tipo di attacco dns di hijacking. Un record MX potrebbe essere spoofing per reindirizzare i messaggi di posta elettronica client o un record A con spoofing potrebbe inviare client a un server Web dannoso.

DNSSEC funziona per impedire il hijack DNS eseguendo la convalida sulle risposte DNS. Nello scenario di hijacking DNS illustrato qui, il dispositivo client può rifiutare risposte DNS non convalidate se il dominio contoso.com è firmato con DNSSEC. Per rifiutare risposte DNS non convalidate, il dispositivo client deve applicare la convalida DNSSEC per contoso.com.

DNSSEC include anche Next Secure 3 (NSEC3) per impedire l'enumerazione della zona. L'enumerazione della zona, nota anche come area a piedi, è un attacco in cui l'utente malintenzionato stabilisce un elenco di tutti i nomi in una zona, incluse le zone figlio.

Prima di firmare una zona con DNSSEC, assicurarsi di comprendere il funzionamento di DNSSEC. Quando si è pronti per firmare una zona, vedere Come firmare la zona DNS pubblica di Azure con DNSSEC.

Convalida DNSSEC

Se un server DNS è compatibile con DNSSEC, può impostare il flag DNSSEC OK (DO) in una query DNS su un valore di 1. Questo valore indica al server DNS che risponde di includere i record di risorse correlati a DNSSEC con la risposta. Questi record DNSSEC sono record RRSIG (Resource Record Signature) usati per verificare che la risposta DNS sia autentica.

Un server DNS ricorsivo (non autorevole) esegue la convalida DNSSEC sui record RRSIG usando un trust anchor (DNSKEY). Il server usa una chiave DNSKEY per decrittografare le firme digitali nei record RRSIG (e altri record correlati a DNSSEC) e quindi calcola e confronta i valori hash. Se i valori hash sono gli stessi, fornisce una risposta al client DNS con i dati DNS richiesti, ad esempio un record dell'indirizzo host (A). Vedere il diagramma seguente:

Diagramma che mostra il funzionamento della convalida DNSSEC.

Se i valori hash non sono uguali, il server DNS ricorsivo risponde con un messaggio SERVFAIL. In questo modo, i server DNS in grado di risolvere (o inoltrare) DNS con un trust anchor valido installato possono proteggere dal dirottamento DNS nel percorso tra il server ricorsivo e il server autorevole. Questa protezione non richiede che i dispositivi client DNS siano in grado di essere consapevoli di DNSSEC o di applicare la convalida della risposta DNS, a condizione che il server DNS locale (ultimo hop) sia protetto dal dirottamento.

I dispositivi client Windows 10 e Windows 11 non convalidano i resolver stub con riconoscimento della sicurezza. Questi dispositivi client non eseguono la convalida, ma possono applicare la convalida DNSSEC usando Criteri di gruppo. La tabella NRPT può essere usata per creare e applicare criteri di convalida DNSSEC basati su spazio dei nomi.

Trust anchor e convalida DNSSEC

Nota

La convalida della risposta DNSSEC non viene eseguita dal sistema di risoluzione predefinito fornito da Azure. Le informazioni contenute in questa sezione sono utili se si configurano i propri server DNS ricorsivi per la convalida DNSSEC o la risoluzione dei problemi di convalida.

Gli ancoraggi attendibili operano in base alla gerarchia dello spazio dei nomi DNS. Un server DNS ricorsivo può avere un numero qualsiasi di trust anchor o nessun trust anchor. I trust anchor possono essere aggiunti per una singola zona DNS figlio o per qualsiasi zona padre. Se un server DNS ricorsivo ha un trust anchor radice (.), può eseguire la convalida DNSSEC in qualsiasi zona DNS. Per altre informazioni, vedere Root Zone Operator Information.For more information, see Root Zone Operator Information.

Il processo di convalida DNSSEC funziona con trust anchor come indicato di seguito:

  • Se un server DNS ricorsivo non ha un trust anchor DNSSEC per una zona o uno spazio dei nomi gerarchico padre della zona, non eseguirà la convalida DNSSEC su tale zona.
  • Se un server DNS ricorsivo dispone di un trust anchor DNSSEC per lo spazio dei nomi padre di una zona e riceve una query per la zona figlio, verifica se nella zona padre è presente un record DS per le zone figlio.
    • Se viene trovato il record DS, il server DNS ricorsivo esegue la convalida DNSSEC.
    • Se il server DNS ricorsivo determina che la zona padre non dispone di un record DS per la zona figlio, presuppone che la zona figlio non sia sicura e non esegua la convalida DNSSEC.
  • Se più server DNS ricorsivi sono coinvolti in una risposta DNS (inclusi i server d'inoltro), ogni server deve essere in grado di eseguire la convalida DNSSEC sulla risposta in modo che sia presente una catena di attendibilità non interrotta.
  • I server ricorsivi con convalida DNSSEC disabilitata o non con riconoscimento DNSSEC non eseguono la convalida.

Catena di attendibilità

Una catena di attendibilità si verifica quando tutti i server DNS coinvolti nell'invio di una risposta per una query DNS sono in grado di verificare che la risposta non sia stata modificata durante il transito. Affinché la convalida DNSSEC funzioni end-to-end, la catena di attendibilità deve essere interrotta. Questa catena di attendibilità si applica ai server autorevoli e non autorevoli (ricorsivi).

Server autorevoli

I server DNS autorevoli mantengono una catena di attendibilità tramite l'uso di record del firmatario di delega. I record DS vengono usati per verificare l'autenticità delle zone figlio nella gerarchia DNS.

  • Affinché la convalida DNSSEC venga eseguita in una zona firmata, è necessario firmare anche l'elemento padre della zona firmata. Anche la zona padre deve avere un record DS per la zona figlio.
  • Durante il processo di convalida, viene eseguita una query sull'elemento padre di una zona per il record DS. Se il record DS non è presente o i dati del record DS nell'elemento padre non corrispondono ai dati DNSKEY nella zona figlio, la catena di attendibilità viene interrotta e la convalida non riesce.

Server ricorsivi

I server DNS ricorsivi (chiamati anche risoluzione o memorizzazione nella cache dei server DNS) mantengono una catena di attendibilità tramite l'uso di trust anchor DNSSEC.

  • L'ancoraggio di attendibilità è un record DNSKEY o un record DS contenente un hash di un record DNSKEY. Il record DNSKEY viene creato in un server autorevole quando una zona è firmata e rimossa dalla zona se la zona non è firmata.
  • Gli ancoraggi attendibili devono essere installati manualmente nei server DNS ricorsivi.
  • Se è presente un trust anchor per una zona padre, un server ricorsivo può convalidare tutte le zone figlio nello spazio dei nomi gerarchico. Sono incluse le query inoltrate. Per supportare la convalida DNSSEC di tutte le zone DNSSEC firmate da DNS, è possibile installare un trust anchor per la zona radice (.).

Rollover della chiave

La chiave di firma della zona (ZSK) in una zona con firma DNSSEC viene eseguito periodicamente il roll over (sostituito) automaticamente da Azure. Non deve essere necessario sostituire la chiave di firma della chiave (KSK), ma questa opzione è disponibile contattando il supporto tecnico Microsoft. Per sostituire KSK è necessario aggiornare anche il record DS nella zona padre.

Algoritmo di firma della zona

Le zone sono firmate DNSSEC usando l'algoritmo di firma digitale a curva ellittica (ECDSAP256SHA256).

Nella tabella seguente viene fornita una breve descrizione dei record correlati a DNSSEC. Per informazioni più dettagliate, vedere RFC 4034: Record di risorse per le estensioni di sicurezza DNS e RFC 7344: Automazione della manutenzione dell'attendibilità della delega DNSSEC.

Registra Descrizione
Firma record di risorse (RRSIG, Resource Record Signature) Tipo di record di risorsa DNSSEC usato per contenere una firma, che copre un set di record DNS per un nome e un tipo specifici.
DNSKEY Tipo di record di risorse DNSSEC usato per archiviare una chiave pubblica.
Firmatario di delega (DS) Tipo di record di risorse DNSSEC usato per proteggere una delega.
Sicurezza successiva (NSEC) Tipo di record di risorsa DNSSEC usato per dimostrare la non esistenza di un nome DNS.
Sicurezza successiva 3 (NSEC3) Record di risorse NSEC3 che fornisce l'hashing e la negazione autenticata dell'esistenza per i set di record di risorse DNS.
Proteggere quindi 3 parametri (NSEC3PARAM) Specifica i parametri per i record NSEC3.
Firmatario di delega figlio (CDS) Questo record è facoltativo. Se presente, il record CDS può essere utilizzato da una zona figlio per specificare il contenuto desiderato del record DS in una zona padre.
DNSKEY figlio (CDNSKEY) Questo record è facoltativo. Se il record CDNSKEY è presente in una zona figlio, può essere usato per generare un record DS da un record DNSKEY.

I record correlati a DNSSEC non vengono visualizzati nella portale di Azure. Per visualizzare i record correlati a DNSSEC, usare strumenti da riga di comando come Resolve-DnsName o dig.exe. Questi strumenti sono disponibili usando Cloud Shell o localmente, se installati nel dispositivo. Assicurarsi di impostare il flag DO nella query usando l'opzione -dnssecok Resolve-DnsName o l'opzione +dnssec in dig.exe.

Importante

Non usare lo strumento da riga di comando nslookup.exe per eseguire query per i record correlati a DNSSEC. Lo strumento nslookup.exe usa un client DNS interno che non è compatibile con DNSSEC.

Vedere gli esempi seguenti:

PS C:\> resolve-dnsname server1.contoso.com -dnssecok

Name                                      Type   TTL   Section    IPAddress
----                                      ----   ---   -------    ---------
server1.contoso.com                        A     3600  Answer     203.0.113.1

Name        : server1.contoso.com
QueryType   : RRSIG
TTL         : 3600
Section     : Answer
TypeCovered : A
Algorithm   : 13
LabelCount  : 3
OriginalTtl : 3600
Expiration  : 9/20/2024 11:25:54 PM
Signed      : 9/18/2024 9:25:54 PM
Signer      : contoso.com
Signature   : {193, 20, 122, 196…}

C:\>dig server1.contoso.com +dnssec

; <<>> DiG 9.9.2-P1 <<>> server1.contoso.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61065
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;server1.contoso.com.       IN      A

;; ANSWER SECTION:
server1.contoso.com. 3600   IN      A       203.0.113.1
server1.contoso.com. 3600   IN      RRSIG   A 13 3 3600 20240920232359 20240918212359 11530 contoso.com. GmxeQhNk1nJZiep7nuCS2qmOQ+Ffs78Z2eoOgIYP3j417yqwS1DasfA5 e1UZ4HuujDk2G6GIbs0ji3RiM9ZpGQ==

;; Query time: 153 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 15:23:45 2024
;; MSG SIZE  rcvd: 179

PS C:\> resolve-dnsname contoso.com -Type dnskey -dnssecok

Name                                 Type   TTL   Section    Flags  Protocol Algorithm      Key
----                                 ----   ---   -------    -----  -------- ---------      ---
contoso.com                          DNSKEY 3600  Answer     256    DNSSEC   13             {115, 117, 214,
                                                                                                165…}
contoso.com                          DNSKEY 3600  Answer     256    DNSSEC   13             {149, 166, 55, 78…}
contoso.com                          DNSKEY 3600  Answer     257    DNSSEC   13             {45, 176, 217, 2…}

Name        : contoso.com
QueryType   : RRSIG
TTL         : 3600
Section     : Answer
TypeCovered : DNSKEY
Algorithm   : 13
LabelCount  : 2
OriginalTtl : 3600
Expiration  : 11/17/2024 9:00:15 PM
Signed      : 9/18/2024 9:00:15 PM
Signer      : contoso.com
Signature   : {241, 147, 134, 121…}

C:\>dig contoso.com dnskey

; <<>> DiG 9.9.2-P1 <<>> contoso.com dnskey
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46254
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;contoso.com.               IN      DNSKEY

;; ANSWER SECTION:
contoso.com.        3600    IN      DNSKEY  256 3 13 laY3Toc/VTyjupgp/+WgD05N+euB6Qe1iaM/253k7bkaA0Dx+gSDhbH2 5wXTt+uLQgPljL9OusKTneLdhU+1iA==
contoso.com.        3600    IN      DNSKEY  257 3 13 LbDZAtjG8E9Ftih+LC8CqQrSZIJFFJMtP6hmN3qBRqLbtAj4JWtr2cVE ufXM5Pd/yW+Ca36augQDucd5n4SgTg==
contoso.com.        3600    IN      DNSKEY  256 3 13 c3XWpTqZ0q9IO+YqMEtOBHZSzGGeyFKq0+3xzs6tifvD1rey1Obhrkz4 DJlEIxy2m84VsG1Ij9VYdtGxxeVHIQ==

;; Query time: 182 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 16:35:10 2024
;; MSG SIZE  rcvd: 284

Terminologia DNSSEC

Questo elenco viene fornito per comprendere alcuni dei termini comuni usati durante la discussione su DNSSEC. Vedere anche: Record di risorse correlati a DNSSEC

Termine Descrizione
Bit di dati autenticati (AD) Bit di dati che indica in una risposta che tutti i dati inclusi nelle sezioni di risposta e autorità della risposta sono stati autenticati dal server DNS in base ai criteri del server.
Catena di autenticazione Catena di record DNS firmati e convalidati che si estende da un trust anchor preconfigurato a una zona figlio nell'albero DNS.
Estensione DNS (EDNS0) Un record DNS che contiene informazioni di intestazione DNS estese, ad esempio il bit DO e le dimensioni massime dei pacchetti UDP.
Estensioni di sicurezza DNS (DNSSEC) Estensioni al servizio DNS che forniscono meccanismi per la firma e per la risoluzione sicura dei dati DNS.
BIT DNSSEC OK (DO) Un bit nella parte EDNS0 di una richiesta DNS che segnala che il client è compatibile con DNSSEC.
Convalida DNSSEC La convalida DNSSEC è il processo di verifica dell'origine e dell'integrità dei dati DNS usando chiavi di crittografia pubbliche.
Isola di sicurezza Zona firmata che non ha una catena di autenticazione dalla relativa zona padre delegata.
Chiave di firma della chiave (KSK) Chiave di autenticazione che corrisponde a una chiave privata usata per firmare una o più chiavi di firma per una determinata zona. In genere, la chiave privata che corrisponde a una chiave KSK firma una chiave di firma della zona (ZSK), che a sua volta ha una chiave privata corrispondente che firma altri dati della zona. I criteri locali possono richiedere che la ZSK venga modificata di frequente, mentre KSK può avere un periodo di validità più lungo per fornire un punto di ingresso più stabile e sicuro nella zona. La progettazione di una chiave di autenticazione come KSK è puramente un problema operativo: la convalida DNSSEC non distingue tra KSK e altre chiavi di autenticazione DNSSEC. È possibile usare una singola chiave sia come KSK che come ZSK.
Sistema di risoluzione stub non convalidante Sistema di risoluzione stub compatibile con la sicurezza che considera attendibile uno o più server DNS con riconoscimento della sicurezza per eseguire la convalida DNSSEC per suo conto.
chiave sep (secure entry point) Subset di chiavi pubbliche all'interno di DNSKEY RRSet. Una chiave SEP viene usata per generare un RR DS o viene distribuita ai resolver che usano la chiave come trust anchor.
Server DNS compatibile con la sicurezza Un server DNS che implementa le estensioni di sicurezza DNS come definito nelle RFC 4033 [5], 4034 [6]e 4035 [7]. In particolare, un server DNS compatibile con la sicurezza è un'entità che riceve query DNS, invia risposte DNS, supporta l'estensione delle dimensioni dei messaggi EDNS0 [3] e il bit DO e supporta i tipi di record DNSSEC e i bit di intestazione del messaggio.
Area firmata Zona i cui record sono firmati come definito dalla RFC 4035 [7] Sezione 2. Una zona firmata può contenere record di risorse DNSKEY, NSEC, NSEC3, NSEC3PARAM, RRSIG e DS. Questi record di risorse consentono la convalida dei dati DNS da parte dei resolver.
Trust anchor Chiave pubblica preconfigurata associata a una determinata zona. Un trust anchor consente a un resolver DNS di convalidare i record di risorse DNSSEC firmati per tale zona e di creare catene di autenticazione nelle zone figlio.
Area senza segno Qualsiasi zona DNS non firmata come definito dalla RFC 4035 [7] Sezione 2.
Firma della zona La firma della zona è il processo di creazione e aggiunta di record di risorse correlati a DNSSEC a una zona, rendendolo compatibile con la convalida DNSSEC.
Annullamento della firma della zona L'annullamento della firma della zona è il processo di rimozione dei record di risorse correlati a DNSSEC da una zona, ripristinandolo in uno stato non firmato.
Chiave di firma della zona (ZSK) Chiave di autenticazione che corrisponde a una chiave privata usata per firmare una zona. In genere, una chiave di firma della zona fa parte dello stesso RRSet DNSKEY della chiave di firma della chiave la cui chiave privata corrispondente firma questo RRSet DNSKEY, ma la chiave di firma della zona viene usata per uno scopo leggermente diverso e può differire dalla chiave di firma della chiave in altri modi, ad esempio nella durata della validità. La progettazione di una chiave di autenticazione come chiave di firma della zona è puramente un problema operativo; La convalida DNSSEC non distingue tra le chiavi di firma della zona e altre chiavi di autenticazione DNSSEC. È possibile usare una singola chiave sia come chiave di firma della chiave che come chiave di firma della zona.

Passaggi successivi