Usa DNSSEC avanzate

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

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

Delegare sottodomini firmati con DNSSEC

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

Per creare record DS per sottodomini delegati, devi ottenere il record DS per la zona. Se la zona delegata è ospitata anche in Cloud DNS, puoi recuperare 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. Vai 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 Configurazione registrar.

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

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

gcloud

1. Per ottenere le informazioni sui record DS per i sottodomini delegati, esegui questo comando:

   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 sarà simile al seguente:

   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, devi avere l'ID della chiave KEY_SIGNING (KSK), che in genere è 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, in genere 0.

   L'output è simile al seguente:

   44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
   

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

4. Per creare i record DS per una sottodelega sicura, esegui questo comando 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 sarà simile al seguente:

   Transaction started [transaction.yaml].
   

5. Quindi, esegui questo comando 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 padre nel progetto
   • TIME_TO_LIVE: durata in secondi per la zona, ad esempio 3600
   • subdomain.example.com: un sottodominio del nome DNS della zona
   • DS_RECORD_AND_KEY: il record DS e la chiave ottenuti nel passaggio 2, ad esempio 44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

   L'output sarà simile al seguente:

   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 padre nel progetto
   • TIME_TO_LIVE: durata in secondi per la zona, ad esempio 3600
   • subdomain.example.com: un sottodominio del nome DNS della zona

7. Inserisci i seguenti valori 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 è stato assegnato il sottodominio delegato al momento della creazione. Queste informazioni sono visibili nella precedente finestra di dialogo di configurazione del registrar: i dettagli necessari dei record DS e NS vengono visualizzati insieme.

   L'output sarà simile al seguente:

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

8. Per eseguire la transazione, utilizza questo comando:

   gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
   

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

   L'output sarà simile al seguente:

   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 le DNSSEC per una zona gestita o crei una zona gestita con DNSSEC, puoi selezionare gli algoritmi di firma delle DNSSEC e il tipo di esistenza di esistenza.

Puoi modificare le impostazioni DNSSEC (ad esempio, l'algoritmo utilizzato per firmare i record critopgraficamente) per una zona gestita prima di attivare DNSSEC. Se DNSSEC è già abilitato per una zona gestita, per apportare modifiche devi prima disabilitare DNSSEC, apportare le modifiche richieste, quindi utilizzare il seguente comando per riabilitare 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, consulta Abilitare DNSSEC per le zone gestite esistenti.

Nota: se vuoi che il dominio venga risolto quando le DNSSEC sono disabilitate, devi prima disattivare DNSSEC per la tua zona presso il tuo registrar di domini per assicurarti che i resolver che convalidano le DNSSEC possano comunque risolvere i nomi nella zona. Per maggiori dettagli, consulta Disabilitare DNSSEC per le zone gestite.

Il seguente comando abilita le DNSSEC con ECDSA e NSEC a 256 bit per i pacchetti di risposta con firma DNSSEC più piccoli possibili 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 fornisci algoritmi o lunghezze delle chiavi KSK o ZSK, devi fornire tutti e i relativi argomenti nel comando:

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

Puoi specificare il denial of Pubblica come NSEC o NSEC3 indipendentemente dagli algoritmi.

Le opzioni e gli argomenti dell'algoritmo supportati sono elencati nella tabella seguente. 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 i seguenti valori predefiniti:

Tipo di chiave	Algoritmo predefinito	Lunghezza predefinita della chiave
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 con firma sono identiche. La lunghezza delle chiavi è importante: le chiavi più lunghe sono più lente e le risposte sono più grandi (vedi le analisi delle dimensioni delle risposte per la zona principale e i domini di primo livello, nonché un'analisi delle prestazioni lato server su Windows).

Il supporto del resolver per ECDSA è limitato a sistemi abbastanza recenti. I resolver meno recenti che non sono in grado di convalidare le zone con firma ECDSA le considerano non firmate, il che potrebbe non essere sicuro se utilizzi nuovi tipi di record basati su DNSSEC. Il supporto per registrar e registry per ECDSA a 256 bit è comune, ma non universale. Solo alcuni registry e ancora meno registrar supportano il protocollo ECDSA a 384 bit. L'utilizzo di ECDSA può essere efficace se non hai bisogno di supportare client meno recenti; le firme sono molto più piccole e più rapide 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 che convalidano le DNSSEC potrebbero non riuscire nella convalida per le zone con algoritmi DNSKEY che non vengono utilizzati per firmare tutti i record nella zona. Questo è vero anche se il documento RFC 6840 afferma che "non devono insistere sul fatto che tutti gli algoritmi ... nel lavoro DNSKEY RRset". Se questo non è un problema (la maggior parte dei resolver di convalida segue RFC 6840), puoi utilizzare RSASHA256 per KSK ed ECDSA per ZSK se il tuo registrar di domini o il registro di TLD non supporta ECDSA e hai bisogno di dimensioni di risposta ridotte.

NSEC3 è il tipo predefinito di denial of existence e offre protezione limitata contro gli utenti che navigano in una zona che tentano di scoprire tutti i record della tua zona. Le impostazioni di NSEC3PARAM sono fisse: NSEC3 opt-out è disabilitato per sicurezza ed è prevista un'iterazione hash aggiuntiva (per un totale di due) con un sale a 64 bit.

Il NSEC ha risposte leggermente più piccole, ma non protegge dal camminamento nelle zone. L'utilizzo del NSEC può anche ridurre le query per domini inesistenti. Google Public DNS e molti altri resolver che convalidano le DNSSEC possono sintesi delle risposte negative dai record NSEC memorizzati nella cache senza eseguire query nella zona Cloud DNS.

RFC 8624 contiene ulteriori indicazioni sulla selezione dell'algoritmo.

Usa nuovi tipi di record DNS con zone protette con DNSSEC

Una volta che il tuo dominio è stato completamente protetto tramite DNSSEC, puoi iniziare utilizzando diversi nuovi tipi di record DNS che utilizzano le garanzie di autenticità e integrità delle zone firmate con 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. I client SSH di solito richiedono l'interazione dell'utente per confermare la chiave pubblica del server alla prima connessione e generare avvisi se la chiave viene modificata. Un client SSH configurato per l'utilizzo di SSHFP utilizza sempre la chiave presente nel record SSHFP del server. Solo le chiavi dei server senza un record SSHFP vengono salvate per essere riutilizzate.

Il formato del record SSHFP è il seguente:

• Numero algoritmo
• Numero del tipo di impronta
• Fingerprint della chiave server

Di seguito sono riportati i numeri dell'algoritmo per SSH:

1. Addetto alle vendite
2. DSA
3. ECDSA
4. ED25519

I tipi di impronte digitali sono i seguenti:

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

Attenzione: l'uso improprio dei record SSHFP può avere gravi conseguenze sulla sicurezza; segui queste regole per evitare di creare vulnerabilità di sicurezza:

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

Il mancato rispetto di queste regole potrebbe consentire agli utenti malintenzionati di creare record SSHFP con spoofing per rubare l'identità dei tuoi server, rendendo le connessioni SSH ai server non sicure e vulnerabili agli attacchi.

StackExchange offre suggerimenti per la creazione di SSHFP, e sono disponibili strumenti per generarli scansionando i server, utilizzando i file host noti o la gestione della configurazione esistenti. Per altri esempi e link, vedi Record SSHFP: 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 quelli utilizzati da HTTPS) senza dipendere dalla firma di un insieme preconfigurato di autorità di certificazione (CA).

In questo modo puoi configurare CA personalizzate e generare certificati per HTTPS. Ciò consente inoltre la convalida dei certificati per protocolli come SMTP, dove in genere non è previsto alcun supporto 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 delle DNSSEC, quindi la creazione di questi record non ha alcun effetto. Tuttavia, potrebbe creare una vulnerabilità in applicazioni configurate in modo errato.

DANE (Domain Authentication of Named Entities), come specificato nel documento RFC 6698 e nelle relative RFC, utilizza i record TLSA in modi specifici per proteggere molti protocolli e applicazioni. IETF Journal and Internet Society offre un utile articolo introduttivo e una panoramica di DANE.

HTTPS

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

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

Verifica del certificato TLS per SMTP (email)

Il protocollo email SMTP è vulnerabile ad attacchi di downgrade che disabilitano la crittografia e DANE fornisce un modo per evitarli.

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

• Parte 1
• Parte 2

Puoi trovare ottimi consigli (e uno strumento di convalida di domini DANE per HTTPS e SMTP) alla pagina Errori comuni. Lo strumento Testa lo strumento di convalida delle email controlla anche il codice DANE.

Verifica del certificato TLS XMPP (Jabber Chat)

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

Associazione di chiave pubblica TXT (OpenPGP / GnuPG)

I record TXT possono essere utilizzati senza DNSSEC, ma i record TXT firmati con DNSSEC forniscono una maggiore affidabilità della loro autenticità. Ciò è importante per la pubblicazione basata su DNS delle 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 con DNS e ospita una copia della chiave pubblica armata con ASCII all'URI specificato, Bob può cercare una chiave OpenPGP per [e-mail] con una sicurezza ragionevole (questa operazione non sostituisce la convalida 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 instructions per generare questi record TXT PKA di versione 1 (così come vengono chiamati nelle chiavi di pubblicazione in DNS).

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

Se hai registrato la chiave OpenPGP su Keybase.io, non è necessario ospitarla sul tuo server. Puoi invece 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 tua chiave OpenPGP su un server di chiavi, puoi utilizzare anche un URI hkp: per il server di 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 riuscire a raggiungerlo (alcuni server chiavi forniscono URL HTTP sulla porta 80).

TXT (SPF, DKIM e DMARC)

Di seguito sono riportati 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 sono):

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

• DKIM: pubblica un set di chiavi pubbliche utilizzate per verificare l'invio dell'email da un dominio e protegge i messaggi dalla modifica durante il transito.

• DMARC: specifica le norme e i report del dominio per la convalida SPF e DKIM e la segnalazione degli errori.

Per verificare che il tuo dominio sia configurato correttamente per l'utilizzo di tutti e tre questi tipi di record, puoi usare lo strumento Testare lo strumento di convalida delle email. Per trovare consigli utili sulla configurazione dei record SPF, vedi Domande frequenti sugli errori comuni.

Usa altri tipi di set di record migliorati da DNSSEC

Oltre a TXT, esistono altri tipi di set di record che traggono vantaggio dalle DNSSEC, anche se non lo richiedono.

CAA

I set di record CAA (Certification Authority Authorization) consentono di controllare quali CA pubbliche possono generare certificati TLS o altri certificati per il dominio. Questo controllo è particolarmente utile ed efficace se vuoi assicurarti che una CA pubblica che emette certificati convalidate per il dominio (DV, ad esempio 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 alla CA best-ca.example (e a nessun'altra CA) di emettere certificati per i nomi nel dominio in cui si trova il set di record CAA. Se vuoi consentire a più CA di emettere certificati, crea più record CAA.

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

IPSECKEY

Puoi anche abilitare la crittografia opportunità attraverso i tunnel IPsec pubblicando record IPSECKEY. L'implementazione VPN IPsec strongSwan ha un plug-in che utilizza record IPSECKEY.

Oltre a posizionare i record IPSECKEY nelle normali zone di forwarding, come service.example.com, RFC 4025 sezione 1.2 richiede ai gateway di sicurezza di cercare record IPSECKEY nelle zone inverse ip6.arpa e in-addr.arpa.

Il supporto DNSSEC per le zone inverse è meno comune rispetto a quello per le zone di forwarding e richiede un provider di servizi internet (ISP) che implementi DNSSEC. Tuttavia, esistono alcuni ISP che possono supportare DNSSEC per le deleghe in zone inverse.

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

Passaggi successivi

• Per creare, aggiornare, elencare ed eliminare zone gestite, consulta Gestione delle zone.
• Per trovare soluzioni ai problemi comuni che potresti riscontrare quando utilizzi Cloud DNS, consulta Risoluzione dei problemi.
• Per una panoramica di Cloud DNS, consulta la panoramica di Cloud DNS.