Utilizza DNSSEC avanzate

Questa pagina offre diverse opzioni di configurazione avanzate di Domain Name System Security Extensions (DNSSEC) che puoi utilizzare se abiliti DNSSEC per le tue zone gestite. Queste opzioni vanno da diversi algoritmi di firma e negenza di esistenza alla possibilità di utilizzare tipi di record che richiedono o consigliano DNSSEC per il loro utilizzo.

Per una panoramica concettuale di DNSSEC, consulta la panoramica DNSSEC.

Delegare i sottodomini con firma DNSSEC

Puoi abilitare DNSSEC per sottodomini delegati dopo aver abilitato DNSSEC per il tuo dominio principale. Per abilitare DNSSEC per sottodomini delegati, devi prima creare un record DS in una zona Cloud DNS. Devi inoltre creare uno o più record NS.

Per creare i record DS per i sottodomini delegati, devi ottenere il record DS per la zona. Se la zona delegata è ospitata anche in Cloud DNS, puoi ottenere il record DS dalla console Google Cloud o da Google Cloud CLI.

Console

1. Nella console Google Cloud, vai alla pagina Cloud DNS.

   Vai a Cloud DNS

2. Accedi alla zona gestita per cui vuoi visualizzare il record DS.

3. Per visualizzare il record DS per la zona, nell'angolo in alto a destra della pagina Dettagli zona, fai clic su Registrar Configuration (Configurazione registrar).

4. Il record DS è disponibile nella pagina Configurazione del registrar.

5. Per creare i record NS, segui le istruzioni riportate in Aggiunta di un record.

gcloud

1. Per ottenere le informazioni sul record DS per i sottodomini delegati, esegui il comando seguente:

   gcloud dns dns-keys list --zone EXAMPLE_ZONE
   

   Sostituisci EXAMPLE_ZONE con il nome della zona DNS del sottodominio delegato nel tuo progetto.

   L'output ha il seguente aspetto:

   ID  KEY_TAG  TYPE          IS_ACTIVE  DESCRIPTION
   0   1234     KEY_SIGNING   True
   1   12345    ZONE_SIGNING  True
   

2. Per ottenere un record DS completo e tutti i dettagli della chiave, ti serve l'ID della chiave KEY_SIGNING (KSK), che di solito è zero (0). Esegui questo comando:

   gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \
      --format "value(ds_record())"
   

   Sostituisci quanto segue:

   • EXAMPLE_ZONE: il nome della zona DNS del sottodominio delegato nel tuo progetto
   • KSK_ID: numero ID KSK, solitamente 0

   L'output è simile al seguente:

   44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
   

3. Copia l'output del comando precedente per utilizzarlo in un passaggio successivo.

4. Per creare i record DS per una sottodelega sicura, esegui il comando seguente per avviare la transazione:

   gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
   

   Sostituisci EXAMPLE_ZONE con il nome della zona DNS principale nel progetto in cui stai creando i record per il sottodominio delegato.

   L'output ha il seguente aspetto:

   Transaction started [transaction.yaml].
   

5. Quindi, esegui il comando seguente per aggiungere un set di record:

   gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \
      --ttl TIME_TO_LIVE \
      --type DS \
      --name subdomain.example.com \
      "DS_RECORD_AND_KEY"
   

   Sostituisci quanto segue:

   • EXAMPLE_ZONE: il nome della zona DNS principale nel progetto
   • TIME_TO_LIVE: durata in secondi in zona, ad esempio 3600
   • subdomain.example.com: un sottodominio del nome DNS della zona
   • DS_RECORD_AND_KEY: il record DS e la chiave che hai recuperato nel passaggio 2, ad esempio 44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

   L'output ha il seguente aspetto:

   44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
   Record addition appended to transaction at [transaction.yaml].
   

6. Per aggiungere record NS, utilizza il comando seguente:

   gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \
      --ttl TIME_TO_LIVE \
      --type NS \
      --name subdomain.example.com \
   

   Sostituisci quanto segue:

   • EXAMPLE_ZONE: il nome della zona DNS principale nel progetto
   • TIME_TO_LIVE: durata in secondi in zona, ad esempio 3600
   • subdomain.example.com: un sottodominio del nome DNS della zona

7. Inserisci i seguenti RRData:

   ns-cloud-e1.googledomains.com. \
   ns-cloud-e2.googledomains.com. \
   ns-cloud-e3.googledomains.com. \
   ns-cloud-e4.googledomains.com.
   

   Nota: la scelta dei server dei nomi per il record NS dipende dallo shard del server dei nomi a cui era assegnato il sottodominio delegato al momento della creazione. Queste informazioni sono visibili nella finestra di dialogo Configurazione del registrar precedente: i dettagli del record DS e NS necessari vengono visualizzati insieme.

   L'output ha il seguente aspetto:

   Record addition appended to transaction at [transaction.yaml].
   

8. Per eseguire la transazione, utilizza il comando seguente:

   gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
   

   Sostituisci EXAMPLE_ZONE con il nome di una zona DNS nel tuo progetto.

   L'output ha il seguente aspetto:

   Executed transaction [transaction.yaml] for managed-zone [dns-example].
   Created     [https://dns.googleapis.com/dns/v1/projects/example/managedZones/example_zone/changes/42].
   ID  START_TIME                STATUS
   42  2019-08-08T23:12:49.100Z  PENDING
   

Utilizzare le opzioni di firma avanzate

Quando abiliti DNSSEC per una zona gestita o crei una zona gestita con DNSSEC, puoi selezionare gli algoritmi di firma DNSSEC e il tipo di rifiuto dell'esistenza.

Puoi modificare le impostazioni DNSSEC (ad esempio, l'algoritmo utilizzato per firmare i record in modo crittografico) per una zona gestita prima di abilitare DNSSEC. Se DNSSEC è già abilitato per una zona gestita, per disabilitare le modifiche, devi prima disabilitare le DNSSEC, apportare le modifiche richieste, quindi utilizzare il comando seguente per riattivare le DNSSEC:

gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on

Sostituisci EXAMPLE_ZONE con il nome di una zona DNS nel tuo progetto.

Per maggiori dettagli, vedi Attivare DNSSEC per le zone gestite esistenti.

Nota: se vuoi che il tuo dominio venga risolto durante la disattivazione delle DNSSEC, devi prima disattivare DNSSEC per la tua zona nel registrar di dominio per assicurarti che i resolver con convalida DNSSEC siano ancora in grado di risolvere i nomi nella zona. Per maggiori dettagli, vedi Disattiva DNSSEC per le zone gestite.

Il seguente comando abilita DNSSEC con ECDSA e NSEC a 256 bit per i più piccoli pacchetti di risposta con firma DNSSEC disponibili utilizzando Cloud DNS:

gcloud dns managed-zones update EXAMPLE_ZONE \
  --dnssec-state on \
  --ksk-algorithm ECDSAP256SHA256 --ksk-key-length 256 \
  --zsk-algorithm ECDSAP256SHA256 --zsk-key-length 256 \
  --denial-of-existence NSEC

Sostituisci EXAMPLE_ZONE con il nome di una zona DNS nel tuo progetto.

Se specifichi algoritmi o lunghezze chiave KSK o ZSK, devi fornire tutti gli argomenti e i relativi argomenti nel comando:

--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length

Puoi specificare la negazione dell'esistenza come NSEC o NSEC3, indipendentemente dagli algoritmi.

Le opzioni e gli argomenti relativi all'algoritmo supportato sono elencati nella seguente tabella. Cloud DNS non consente l'utilizzo di altri algoritmi o parametri.

Algoritmo	Vasche KSK	Vasche ZSK	Commenti
RSASHA256	2048	1024 2048
RSASHA512	2048	1024 2048	Non ampiamente supportato
ECDSAP256SHA256	256	256
ECDSAP384SHA384	384	384	Non ampiamente supportato

Se non viene specificato alcun algoritmo, Cloud DNS utilizza questi valori predefiniti:

Tipo di chiave	Algoritmo predefinito	Lunghezza della chiave predefinita
Chiave di firma della chiave (KSK)	RSASHA256	2048
Chiave di firma della zona (ZSK)	RSASHA256	1024

Le differenze di sicurezza e prestazioni tra RSASHA256 e RSASHA512 sono minime e le dimensioni delle risposte firmate sono identiche. Le lunghezze delle chiavi sono importanti: le chiavi più lunghe sono più lente e le risposte sono più grandi (consulta le analisi delle dimensioni delle risposte per la zona radice e i TLD, e un'analisi delle prestazioni lato server su Windows).

Il supporto del resolver per ECDSA è limitato a sistemi abbastanza recenti. I resolver precedenti che non possono convalidare le zone firmate ECDSA li considerano non firmati, il che potrebbe non essere sicuro se utilizzi nuovi tipi di record che si basano su DNSSEC. Il supporto di registrar e registry per gli ECDSA a 256 bit è comune, ma non universale. Solo pochi registry e ancora meno registrar supportano ECDSA a 384 bit. L'uso di ECDSA può essere efficace se non hai bisogno di supportare client meno recenti; le firme sono molto più piccole e veloci da calcolare.

Evita di utilizzare algoritmi diversi per KSK e ZSK nelle zone gestite, in quanto riduce la compatibilità e potrebbe compromettere la sicurezza. Alcuni risolutori con convalida DNSSEC potrebbero non superare la convalida per le zone con algoritmi DNSKEY che non vengono utilizzati per firmare tutti i record nella zona. Questo vale anche se RFC 6840 afferma che non devono insistere sul fatto che tutti gli algoritmi nel lavoro RRset DNSKEY". Se non è un problema (la maggior parte dei risolutori di convalida segue RFC 6840), puoi utilizzare RSASHA256 per KSK ed ECDSA per ZSK se il tuo registrar di domini o registry TLD non supporta i formati ECDSA e hai bisogno di dimensioni di risposta ridotte.

NSEC3 è il tipo di negazione dell'esistenza predefinito; offre una protezione limitata contro i camminatori di zona che tentano di scoprire tutti i record nella tua zona. Le impostazioni NSEC3PARAM sono fisse: NSEC3 opt-out è disattivato per motivi di sicurezza ed è presente un'iterazione di hash aggiuntiva (per un totale di due) con un valore a 64 bit.

NSEC ha risposte leggermente più piccole, ma non protegge da zone camminate. L'uso di NSEC può anche ridurre le query per domini inesistenti. Google Public DNS e diversi altri resolver con convalida DNSSEC possono sintetizzare le risposte negative dei record NSEC memorizzati nella cache senza eseguire query sulla zona Cloud DNS.

Il documento RFC 8624 contiene ulteriori indicazioni sulla selezione dell'algoritmo.

Utilizza i nuovi tipi di record DNS con zone protette da DNSSEC

Dopo che il tuo dominio è stato completamente protetto mediante DNSSEC, puoi iniziare a utilizzare diversi nuovi tipi di record DNS che usano le garanzie di autenticità e integrità delle zone firmate DNSSEC per migliorare la sicurezza di altri servizi.

SSHFP

I record SSHFP contengono un'impronta della chiave pubblica di un server SSH che le applicazioni client SSH possono utilizzare per convalidare i server SSH. In genere, i client SSH richiedono l'interazione dell'utente per confermare la chiave pubblica del server alla prima connessione e generare avvisi in caso di modifica della chiave. Un client SSH configurato per l'utilizzo di SSHFP utilizza sempre la chiave nel record SSHFP di un server per quel server; solo le chiavi per i server senza un record SSHFP vengono salvate per il riutilizzo.

Il formato del record SSHFP è il seguente:

• Numero di algoritmo
• Numero tipo di impronta
• Impronta chiave server

I numeri dell'algoritmo per SSH sono i seguenti:

1. RSA
2. DSA
3. ECDSA
4. ED25519

I tipi di impronte digitali sono i seguenti:

• SHA-1 (deprecato, solo per compatibilità)
• SHA-256

Attenzione: un uso improprio dei record SSHFP può avere gravi conseguenze per la sicurezza. Segui queste regole per evitare di creare vulnerabilità di sicurezza:

• Non creare record SSHFP in una zona non protetta da DNSSEC.
• Non mai configurare client SSH per l'utilizzo di SSHFP per un dominio non protetto da DNSSEC.
• Mai configurare client SSH per l'utilizzo di SSHFP a meno che non convalidino le DNSSEC o utilizzino un resolver di convalida, come DNS pubblico di Google.

Il mancato rispetto di queste regole potrebbe consentire agli utenti malintenzionati di creare record SSHFP con spoofing per i tuoi server per impersonarli, rendendo le connessioni SSH ai server non sicure e vulnerabili agli attacchi.

Sono disponibili suggerimenti per la creazione di SSHFP da parte di StackExchange e esistono strumenti per generarli tramite la scansione dei server, utilizzando i file host noti o la gestione della configurazione esistenti. Per altri esempi e link, consulta la sezione Record SSH: DNS che fornisce chiavi host SSH pubbliche.

TLSA e DANE

I record TLSA contengono informazioni che possono essere utilizzate per convalidare i certificati X.509 (ad esempio i certificati utilizzati da HTTPS) senza dipendere dalla loro firma da parte di un insieme preconfigurato di autorità di certificazione (CA).

Questo ti permette di configurare le tue autorità di certificazione e di generare certificati per HTTPS. Ciò consente anche la convalida di certificati per protocolli come SMTP in cui di solito non è supportato l'applicazione per le CA attendibili preconfigurate.

Attenzione: non creare record TLSA in una zona non protetta da DNSSEC. La maggior parte delle applicazioni che utilizzano record TLSA richiede la convalida DNSSEC, quindi la creazione di tali record non ha alcun effetto. Tuttavia, potrebbe creare una vulnerabilità nelle applicazioni configurate in modo errato.

DANE (Domain Authentication of Named Entity), come specificato in RFC 6698 e RFC correlati, utilizza i record TLSA in modi specifici per proteggere molti protocolli e applicazioni. L'IETF Journal and Internet Society offre un utile articolo introduttivo e una panoramica DANE.

HTTPS

DANE consente di configurare in modo sicuro i server HTTPS utilizzando certificati generati con la tua infrastruttura CA basata su OpenSSL o CFSSL di Cloudflare.

Lo strumento di convalida DANE di SIDNLabs per i server HTTPS è utile per testare un deployment DANE per HTTPS.

Verifica del certificato TLS SMTP (email)

Il protocollo email SMTP è vulnerabile agli abbonamenti di downgrade che disattivano la crittografia e DANE fornisce un modo per evitarli.

L'Internet Society ha un tutorial in due parti sull'utilizzo di DANE per SMTP con i certificati gratuiti e automatizzati disponibili con Let's Encrypt, incluso consigli per evitare di utilizzare determinati formati di record TLSA con i certificati Let's Encrypt:

• Parte 1
• Parte 2

Puoi trovare suggerimenti eccellenti (e uno strumento di convalida dei domini DANE per HTTPS e SMTP) alla pagina Errori comuni. Lo strumento di convalida degli indirizzi email verifica anche DANE.

Verifica del certificato TLS XMPP (Jabber Chat)

Anche XMPP (e altri servizi che utilizzano i record SRV) possono usufruire di DANE. Un esempio XMPP utilizza la configurazione DANE-SRV come specificato in RFC 7673.

Associazione di chiavi pubbliche TXT (OpenPGP / GnuPG)

I record TXT possono essere utilizzati senza DNSSEC, ma i record TXT con firma DNSSEC forniscono maggiore fiducia nell'autenticità. Ciò è importante per la pubblicazione basata su DNS di chiavi pubbliche OpenPGP (GnuPG), che non sono firmate da parti note come CA X.509.

Ad esempio, se Alice pubblica un record TXT come il seguente nella zona an.example firmata da DNSSEC e ospita una copia della chiave pubblica con struttura ASCII all'URI specificato, Bob può cercare una chiave OpenPGP per [e-mail] con una sicurezza ragionevole. Questo non sostituisce la convalida del web of Trust, ma rende possibile la crittografia OpenPGP con parti precedentemente sconosciute:

    alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"

Puoi utilizzare queste istruzioni per generare questi record TXT PKA versione 1 (come vengono chiamati in Pubblicazione delle chiavi in DNS).

La guida completa alla pubblicazione di chiavi PGP in DNS spiega come creare record CERT di OpenPGP (ma Cloud DNS non supporta i record CERT o OPENPGPKEY).

Se hai registrato la chiave OpenPGP in Keybase.io, non è necessario ospitare la chiave sul server. In alternativa, puoi utilizzare un URL come https://keybase.io/KEYBASE_USERNAME/key.asc (sostituisci KEYBASE_USERNAME con il tuo nome utente Keybase.io).

Se hai caricato la chiave OpenPGP su un server delle chiavi, puoi anche utilizzare un hkp: URI per quel server delle chiavi, ad esempio hkp://subkeys.pgp.net o hkp://pgp.mit.edu, anche se gli utenti protetti da firewall che bloccano la porta 11371 potrebbero non essere in grado di raggiungerla (alcuni server delle chiavi forniscono URL HTTP della porta 80).

TXT (SPF, DKIM e DMARC)

Di seguito sono descritti altri tre tipi di record TXT che puoi utilizzare per proteggere i tuoi servizi email e impedire a spammer e truffatori di inviare email che sembrano provenire dal tuo dominio (anche se non lo fanno):

• SPF: specifica i server SMTP (per nome di dominio o indirizzo IP) che possono inviare email per un dominio.

• DKIM: pubblica un insieme di chiavi pubbliche utilizzate per verificare che le email vengano inviate da un dominio e impedisce che i messaggi vengano modificati in transito.

• DMARC: specifica i criteri di dominio e i report per la convalida di SPF e DKIM e i report sugli errori.

Per verificare che il tuo dominio sia configurato correttamente per l'utilizzo di tutti e tre questi tipi di record, puoi utilizzare lo Strumento di convalida dell'email. Per trovare suggerimenti utili sulla configurazione dei record SPF, consulta le domande frequenti sugli errori comuni.

Utilizza altri tipi di set di record ottimizzati da DNSSEC

Oltre a TXT, esistono altri tipi di set di record che utilizzano le DNSSEC, anche se non sono necessari.

CAA

I set di record dell'autorità di certificazione (CAA) ti consentono di controllare quali CA pubbliche possono generare TLS o altri certificati per il tuo dominio. Questo controllo è più utile (ed efficace) se vuoi assicurarti che una CA pubblica che emette certificati convalidati dal dominio (DV) come LetsEncrypt.org non emetta certificati per il tuo dominio.

Un tipico record CAA ha un formato semplice come 0 issue "best-ca.example" che consente ai best-ca.example certificati CA (e nessun altro CA) di emettere certificati per i nomi nel dominio in cui si trova il set di record CAA. Se vuoi consentire a più autorità di certificazione di emettere certificati, crea più record CAA.

RFC 6844 fornisce ulteriori dettagli sull'uso del tipo di set di record CAA e consiglia vivamente l'uso di DNSSEC.

CHIAVE

Puoi anche abilitare la crittografia opportunistica attraverso i tunnel IPsec pubblicando record IPSECKEY. L'implementazione VPN strongSwan dell'IPsec dispone di un plug-in che utilizza i record IPSECKEY.

Oltre a posizionare i record IPSECKEY nelle abituali zone di inoltro, come service.example.com, RFC 4025 sezione 1.2 è necessario che i gateway di sicurezza cerchino record IPSECKEY nelle zone inverse ip6.arpa e in-addr.arpa.

Il supporto DNSSEC per le zone inverse è meno comune rispetto alle zone in avanti e richiede un provider di servizi Internet (ISP) che implementa DNSSEC. Tuttavia, alcuni ISP possono supportare DNSSEC per le deleghe della zona inversa.

Le zone inverse per gli indirizzi IP esterni delle VM di Compute Engine non supportano ancora la delega.

Passaggi successivi

• Per creare, aggiornare, elencare ed eliminare le zone gestite, consulta Gestire le zone.
• Per trovare soluzioni per i problemi comuni che potresti riscontrare durante l'utilizzo di Cloud DNS, consulta la sezione Risoluzione dei problemi.
• Per una panoramica di Cloud DNS, consulta Panoramica di Cloud DNS.