Utilizzare DNSSEC avanzate

Questa pagina fornisce diverse opzioni di configurazione avanzate per le estensioni DNSSEC (Domain Name System Security Extensions) che puoi utilizzare se attivi DNSSEC per le tue zone gestite. Queste opzioni vanno da diversi algoritmi di firma e di rifiuto di 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 i sottodomini con firma DNSSEC

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

Per creare record DS per i 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 la quale vuoi visualizzare il record DS.

3. Per visualizzare il record DS per la zona, nell'angolo superiore destro della Nella pagina Dettagli zona, fai clic su Configurazione registrar.

4. Il record DS è disponibile nella pagina Registrar Setup (Configurazione del registrar).

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

gcloud

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

   gcloud dns dns-keys list --zone EXAMPLE_ZONE
   

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

   L'output è 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 disporre dell'ID della chiave KEY_SIGNING (KSK), che in genere è zero (0). Esegui l' seguente 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 progetto
   • KSK_ID: il numero ID KSK, in genere 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 subdelegazione sicura, esegui il seguente 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 è il 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 in il tuo progetto
   • TIME_TO_LIVE: durata della zona in secondi, 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 ottenuto nel passaggio 2, ad esempio44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

   L'output è il seguente:

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

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

   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 in il tuo progetto
   • TIME_TO_LIVE: durata della zona in secondi, 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 su quale shard del server dei nomi è stato assegnato il sottodominio delegato è stato creato. Queste informazioni sono visibili nella precedente Finestra di dialogo Registrar setup (Configurazione registrar): il record DS e NS necessario vengono visualizzati insieme.

   L'output è simile al seguente:

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

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

   gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
   

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

   L'output è il 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 DNSSEC per una zona gestita o crei una zona gestita con DNSSEC, puoi selezionare gli algoritmi di firma DNSSEC e il tipo di negazione dell'esistenza.

Puoi modificare le impostazioni DNSSEC (ad esempio, con l'algoritmo utilizzato per eseguire la firma crittografica dei record) per una zona gestita prima di abilitarla DNSSEC. Se DNSSEC è già abilitato per una zona gestita, prima di apportare modifiche disabilita DNSSEC, apporta le modifiche necessarie e utilizza il seguente comando per riattivare 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 Abilitare DNSSEC per zone gestite esistenti.

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

Il seguente comando abilita le DNSSEC con ECDSA a 256 bit e NSEC 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 project.

Se fornisci algoritmi o lunghezze di chiavi KSK o ZSK, devi indicare tutte 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 dell'algoritmo supportati sono elencati nella seguente tabella. Cloud DNS non consente l'utilizzo di altri algoritmi o parametri.

Algoritmo	Lunghezze KSK	Lunghezze 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 firmate sono identiche. La lunghezza dei tasti è importante: i tasti più lunghi sono più lenti e le risposte sono più grandi (vedi le analisi delle dimensioni della risposta per zona principale e TLD, e un'analisi delle prestazioni lato server Windows).

Il supporto dei resolver per ECDSA è limitato ai sistemi abbastanza recenti. I resolver meno recenti che non riescono a convalidare le zone con firma ECDSA li considerano non firmati, che potrebbero non essere sicure Utilizzare nuovi tipi di record che si basano su DNSSEC. Il supporto di ECDSA a 256 bit da parte dei registrar e dei registry è comune, ma non universale. Solo alcuni registry e ancora meno registrar supportano ECDSA a 384 bit. L'utilizzo dell'ECDSA può essere efficace se non hai bisogno di supportare i clienti meno recenti. le firme sono molto più piccole e più veloci da calcolare.

Evita di utilizzare algoritmi diversi per KSK e ZSK nelle zone gestite. riduce la compatibilità e potrebbe compromettere la sicurezza. Alcune funzionalità di convalida DNSSEC i resolver potrebbero non riuscire a eseguire la convalida per zone con algoritmi DNSKEY che non utilizzato per firmare tutti i record nella zona. Ciò è vero anche se RFC 6840 dice "non devono insistere sul fatto che tutti gli algoritmi ... nel RRset DNSKEY funzionino." Se questo non è un problema (la maggior parte dei resolver di convalida segue RFC 6840), puoi utilizzare RSASHA256 per la KSK e ECDSA per la ZSK se il tuo registrar del dominio o il registry del TLD non supporta ECDSA e hai bisogno di dimensioni di risposta ridotte.

NSEC3 è il tipo di rifiuto di esistenza predefinito; offre una protezione limitata contro i "zone walker" che cercano di scoprire tutti i record della tua zona. Le impostazioni NSEC3PARAM sono fisse: NSEC3 opt-out è disabilitato per motivi di sicurezza e c'è un'altra iterazione di hash (per un totale di due) con un valore di salted a 64 bit.

NSEC ha risposte leggermente più piccole, ma nessuna protezione contro le zone camminate. L'uso della NSEC può anche ridurre le query per i domini inesistenti. Google Public DNS e molti altri resolver con convalida DNSSEC synthesize risposte negative dai record NSEC memorizzati nella cache senza interrogare il tuo nella zona Cloud DNS.

RFC 8624 contiene ulteriori indicazioni sulla selezione dell'algoritmo.

Utilizzare nuovi tipi di record DNS con zone protette da DNSSEC

Dopo che il dominio è stato completamente protetto con DNSSEC, puoi iniziare utilizzando diversi nuovi tipi di record DNS che usano le garanzie di autenticità e integrità Zone firmate DNSSEC per migliorare la sicurezza di altri servizi.

SSHFP

I record SSHFP contengono un'impronta digitale della chiave pubblica di un server SSH che le applicazioni client SSH possono utilizzare per convalidare i server SSH. I client SSH in genere 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 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 algoritmo
• Numero del tipo di impronta
• Impronta della chiave server

I numeri degli algoritmi per SSH sono i seguenti:

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

I tipi di impronte sono i seguenti:

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

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

• Non creare record SSHFP in una zona non protetta da DNSSEC.
• Mai configurare i client SSH in modo che utilizzino SSHFP per un dominio senza protezione DNSSEC.
• Non configurare mai i client SSH per l'utilizzo di SSHFP a meno che non convalidare le DNSSEC o usare un resolver di convalida come Google Public DNS.

Il mancato rispetto di queste regole potrebbe consentire agli avversari di creare record SSHFP falsificati per i tuoi server per rubare la loro identità, rendendo le connessioni SSH ai server non sicure e vulnerabili agli attacchi.

StackExchange ha suggerimenti per la creazione di SSHFP, e ci sono strumenti per generarli scansionando i server, usando i server file host conosciuti oppure gestione della configurazione. Per ulteriori esempi e link, consulta l'articolo 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 da uno di un insieme preconfigurato di autorità di certificazione (CA) che li firmano.

In questo modo puoi configurare le tue CA e generare certificati per HTTPS. Ciò consente anche la convalida dei certificati per protocolli come SMTP, dove tipicamente non è supportata l'applicazione di CA attendibili preconfigurate.

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

DANE (Domain Authentication of Named Entities), come specificato in RFC 6698 e le relative RFC, utilizza i record TLSA in modi specifici per proteggere molti protocolli diverse applicazioni. IETF Journal e Internet Society hanno un articolo introduttivo e una panoramica di DANE utili.

HTTPS

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

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

Verifica del certificato TLS SMTP (email)

Il protocollo email SMTP è vulnerabile eseguire il downgrade degli attacchi che disattivano la crittografia, e DANE offre un modo per prevenire questi attacchi.

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

• Parte 1
• Parte 2

Puoi trovare ottimi consigli (e un validatore del dominio DANE per HTTPS e SMTP) in Errori comuni. Lo strumento Testare lo strumento di convalida delle email controlla anche DANE.

Verifica del certificato TLS XMPP (chat Jabber)

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

Associazione della chiave pubblica TXT (OpenPGP/GnuPG)

I record TXT possono essere utilizzati senza DNSSEC, ma i record TXT firmati con DNSSEC forniscono maggiore fiducia nella propria autenticità. Questo è importante per la pubblicazione basata su DNS delle chiavi pubbliche OpenPGP (GnuPG), che non sono firmate da entità ben note come le CA X.509.

Ad esempio, se Alice pubblica un record TXT come il seguente nella La zona an.example con firma DNSSEC e ospita una copia del dominio pubblico protetto da ASCII chiave nell'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 istruzioni per generare questi record TXT PKA versione 1 (come vengono chiamati in Pubblicazione delle chiavi nel DNS).

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

Se hai registrato la tua chiave OpenPGP su Keybase.io, non devi ospitarla sul tuo server. In alternativa, puoi utilizzare un URL come https://keybase.io/KEYBASE_USERNAME/key.asc (sostituire https://keybase.io/KEYBASE_USERNAME/key.asc con il tuo nome utente Keybase.io).

Se hai caricato la tua chiave OpenPGP su un keyserver, puoi anche utilizzare un URI HKP per quel keyserver, ad esempio hkp://subkeys.pgp.net o hkp://pgp.mit.edu, anche se gli utenti dietro firewall che bloccano la porta 11371 potrebbero non essere in grado di raggiungerlo (alcuni keyserver forniscono URL HTTP della 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 ed evitare che spammer e truffatori inviino email che sembrano provenire dal tuo dominio (anche se non è così):

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

• DKIM: Pubblica un set di chiavi pubbliche utilizzate per verificare che l'email provenga da un dominio. e protegge i messaggi dalla modifica in transito.

• DMARC: Specifica i criteri del dominio e i report per la convalida SPF e DKIM e Error Reporting.

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 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 da DNSSEC. anche se non lo richiedono.

CAA

I set di record CAA (Certification Authority Authorization) ti consentono di controllare quali autorità di certificazione pubbliche possono generare certificati TLS o di altro tipo per il tuo dominio. Questo controllo è molto utile (ed efficace) se vuoi assicurarti che un'autorità di certificazione pubblica che emette certificati con validazione del 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 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.

Il documento RFC 6844 fornisce ulteriori dettagli sull'utilizzo del tipo di set di record CAA e, consiglia di usare DNSSEC.

IPSECKEY

Puoi anche abilitare la crittografia opportunistica tramite i tunnel IPsec pubblicando Record IPSECKEY. Il strongSwan L'implementazione VPN IPsec ha un plug-in che utilizza i record IPSECKEY.

Oltre a posizionare i record IPSECKEY nelle zone in avanti consuete, come service.example.com, la sezione 1.2 del documento RFC 4025 richiede ai gateway di sicurezza di cercare i record IPSECKEY nelle zone in retromarcia ip6.arpa e in-addr.arpa.

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

L'inversione di zone per gli indirizzi IP esterni delle VM di Compute Engine non è ancora stata eseguita delega dell'assistenza.

Passaggi successivi

• Per creare, aggiornare, elencare ed eliminare le zone gestite, consulta Gestisci zone.
• Per trovare soluzioni ai 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.