Utilizza 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 negazione dell'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 pagina della panoramica di DNSSEC.

Delega i sottodomini con firma DNSSEC

Puoi abilitare DNSSEC per i sottodomini delegati dopo aver abilitato DNSSEC per il tuo dominio principale. Per abilitare DNSSEC per i sottodomini delegati, crea prima un record DS all'interno di una zona Cloud DNS. Devi creare anche 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, fai clic su Configurazione del registrar nell'angolo in alto a destra della pagina Dettagli zona.

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

  5. Per creare record NS, segui le istruzioni per aggiungere un record.

Pagina Configurazione del registrar

gcloud

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

    gcloud dns dns-keys list --zone SUBDOMAIN_ZONE

    Sostituisci SUBDOMAIN_ZONE con il nome della zona DNS del sottodominio delegato 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 questo comando:

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

    Sostituisci quanto segue:

    • SUBDOMAIN_ZONE: il nome della zona DNS del sottodominio delegato nel tuo progetto
    • KSK_ID: il numero ID KSK, di solito 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 questo comando per avviare la transazione:

    gcloud dns record-sets transaction start --zone PARENT_ZONE

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

    L'output è 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 PARENT_ZONE \
   --ttl TIME_TO_LIVE \
   --type DS \
   --name subdomain.example.com \
   "DS_RECORD_AND_KEY"

    Sostituisci quanto segue:

    • PARENT_ZONE: il nome della zona DNS principale nel tuo progetto
    • TIME_TO_LIVE: la durata (TTL) per la 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 esempio 44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

    L'output è simile al seguente: 

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

  6. Per aggiungere record NS, utilizza questo comando:

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

    Sostituisci quanto segue:

    • PARENT_ZONE: il nome della zona DNS principale nel tuo progetto
    • TIME_TO_LIVE: la durata (TTL) per la 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.

    L'output è 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 tuo progetto.

    L'output è 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

Utilizza 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, 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 apportare modifiche disabilita prima DNSSEC, apporta le modifiche necessarie e poi utilizza il comando seguente 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 Abilita DNSSEC per le zone pubbliche gestite esistenti.

Il comando seguente abilita DNSSEC con ECDSA a 256 bit e NSEC per i pacchetti di risposta firmati con 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 fornirli tutti assieme ai 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 degli algoritmi supportati sono elencati nella tabella seguente. 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 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 in termini di sicurezza e prestazioni tra RSASHA256 e RSASHA512 sono minime e le dimensioni delle risposte firmate sono identiche. La lunghezza delle chiavi è importante: le chiavi più lunghe sono più lente e le risposte hanno dimensioni maggiori (vedi le analisi delle dimensioni delle risposte per la zona root e i TLD e un'analisi delle prestazioni lato server su Windows).

Il supporto dei resolver per ECDSA è limitato a sistemi piuttosto recenti. I resolver meno recenti che non possono convalidare le zone firmate con ECDSA le considerano non firmate, il che potrebbe non essere sicuro se utilizzi nuovi tipi di record che si basano su DNSSEC. Il supporto di ECDSA a 256 bit da parte di registrar e registry è comune, ma non universale. Solo alcuni registri e un numero ancora inferiore di registrar supportano ECDSA a 384 bit. L'utilizzo di ECDSA può essere efficace se non devi supportare client meno recenti; le firme sono molto più piccole e più veloci da calcolare.

Evita di utilizzare algoritmi diversi per la KSK e la ZSK nelle zone gestite, in quanto riduce la compatibilità e potrebbe compromettere la sicurezza. Alcuni resolver di convalida DNSSEC potrebbero non riuscire a convalidare le zone con algoritmi DNSKEY che non vengono utilizzati per firmare tutti i record nella zona. Ciò è vero anche se RFC 6840 afferma che "non devono esigere 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 ed ECDSA per la ZSK se il registrar del dominio o il registro TLD non supporta ECDSA e hai bisogno di dimensioni delle risposte ridotte.

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

NSEC ha risposte leggermente più piccole, ma non offre protezione contro lo zone walking. L'utilizzo di NSEC può anche ridurre le query per domini inesistenti. Google Public DNS e diversi altri resolver di convalida DNSSEC possono sintetizzare risposte negative dai record NSEC memorizzati nella cache senza eseguire query sulla zona Cloud DNS.

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

Utilizza nuovi tipi di record DNS con zone protette da DNSSEC

Dopo che il tuo dominio è stato interamente protetto con DNSSEC, puoi iniziare a utilizzare diversi nuovi tipi di record DNS che usano 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 generano avvisi se la chiave viene modificata. Un client SSH configurato per utilizzare 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 essere riutilizzate.

Il formato dei record SSHFP è il seguente:

  • Numero dell'algoritmo
  • Numero del tipo di impronta
  • Impronta della chiave del server

I numeri degli algoritmi per SSH sono i seguenti:

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

I tipi di impronta sono i seguenti:

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

StackExchange ha suggerimenti per la creazione di SSHFP e sono disponibili strumenti per generarli eseguendo la scansione dei server, utilizzando file host noti esistenti o la gestione della configurazione. Per altri esempi e link, consulta Record SSHFP: chiavi host SSH pubbliche fornite dal DNS.

TLSA e DANE

I record TLSA contengono informazioni che possono essere utilizzate per convalidare i certificati X.509 (come i certificati 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, in cui in genere non è previsto il supporto delle applicazioni per le CA attendibili preconfigurate.

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

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 per server HTTPS di SIDNLabs è utile per testare un deployment DANE per HTTPS.

Verifica del certificato TLS SMTP (email)

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

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

Puoi trovare ottimi consigli (e uno strumento di convalida di domini DANE per HTTPS e SMTP) in Errori comuni. Anche lo strumento Test your email validator verifica DANE.

Verifica del certificato TLS XMPP (chat Jabber)

Anche XMPP (e altri servizi che utilizzano record SRV) possono trarre vantaggio da 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 firmati con DNSSEC offrono una certezza maggiore della loro autenticità. Ciò è importante per la pubblicazione basata su DNS di chiavi pubbliche OpenPGP (GnuPG), che non sono firmate da parti note come le CA X.509.

Ad esempio, se Alice pubblica un record TXT come il seguente nella zona an.example firmata con DNSSEC e ospita una copia della chiave pubblica ASCII armored all'URI specificato, Bob può cercare una chiave OpenPGP per alice@an.example con una sicurezza ragionevole (non si tratta di una sostituzione della convalida della 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 Version 1 PKA (come vengono chiamati in Pubblicazione delle chiavi in DNS).

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

Se hai registrato la tua chiave OpenPGP su Keybase.io, non è necessario ospitarla sul tuo 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 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 e impedire a spammer e truffatori di inviare 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 potrebbero email per un dominio.

  • DKIM: pubblica un insieme di chiavi pubbliche utilizzate per verificare che l'email sia stata inviata da un dominio e protegge i messaggi da modifiche durante il transito.

  • DMARC: specifica le policy 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 utilizzare tutti e tre questi tipi di record, puoi utilizzare lo strumento Test your email validator. Per trovare consigli utili sulla configurazione dei record SPF, consulta 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 traggono vantaggio da DNSSEC, anche se non lo richiedono.

CAA

I set di record di autorizzazione dell'autorità di certificazione (CAA) consentono di controllare quali CA pubbliche possono generare certificati TLS o di altro tipo per il tuo dominio. Questo controllo è più utile (ed efficace) se vuoi assicurarti che una CA pubblica che emette certificati con convalida 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.

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 opportunistica tramite i tunnel IPsec pubblicando i record IPSECKEY. L'implementazione della VPN IPsec strongSwan ha un plug-in che utilizza i record IPSECKEY.

Oltre a inserire i record IPSECKEY nelle zone di ricerca diretta abituali, ad esempio service.example.com, la sezione 1.2 dell'RFC 4025 richiede ai gateway di sicurezza di cercare i record IPSECKEY nelle zone di ricerca inversa ip6.arpa e in-addr.arpa.

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

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

Passaggi successivi