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 di DNSSEC, consulta la panoramica di DNSSEC.

Delega dei sottodomini con firma DNSSEC

Puoi attivare DNSSEC per i sottodomini delegati dopo aver attivato 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 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.

Utilizzare le opzioni di firma avanzate

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

Puoi modificare le impostazioni DNSSEC (ad esempio l'algoritmo utilizzato per firmare i record in modo crittografico) per una zona gestita prima di attivare DNSSEC. Se DNSSEC è già abilitato per una zona gestita, per apportare modifiche, disattiva prima DNSSEC, apporta le modifiche necessarie e poi utilizza 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 project.

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

Il seguente comando attiva DNSSEC con ECDSA a 256 bit e NSEC per i pacchetti di risposta firmati 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 fornirli tutti 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 tabella seguente. Cloud DNS non consente l'utilizzo di altri algoritmi o parametri.

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

Le differenze 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 sono più grandi (consulta le analisi delle dimensioni delle risposte per la zona principale e i TLD, e un'analisi delle prestazioni lato server su Windows).

Il supporto del resolver per ECDSA è limitato ai sistemi abbastanza 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 dei registrar e dei registry è comune, ma non universale. Solo alcuni registry e ancora meno registrar supportano ECDSA a 384 bit. L'utilizzo di ECDSA può essere efficace se non devi supportare i client 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. Questo riduce la compatibilità e potrebbe compromettere la sicurezza. Alcuni resolver con convalida DNSSEC potrebbero non riuscire a convalidare le zone con algoritmi DNSKEY che non vengono utilizzati per firmare tutti i record della zona. Questo è vero anche se RFC 6840 dice che "non devono insistere sul fatto che tutti gli algoritmi ... nell'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 registrar del tuo 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 non offre protezione contro il roaming nella zona. L'utilizzo di NSEC può anche ridurre le query per domini inesistenti. Google Public DNS e diversi altri resolver che convalidano DNSSEC possono synthesize risposte negative dai record NSEC memorizzati nella cache senza eseguire query sulla zona Cloud DNS.

L'RFC 8624 contiene ulteriori indicazioni sulla selezione dell'algoritmo.

Utilizzare nuovi tipi di record DNS con zone protette da DNSSEC

Dopo aver protetto completamente il tuo dominio con DNSSEC, puoi iniziare a utilizzare diversi nuovi tipi di record DNS che sfruttano le garanzie di autenticità e integrità delle 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 dell'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

StackExchange offre suggerimenti per la creazione di SSHFP e esistono strumenti per generarli analizzando i server, utilizzando file host noti esistenti o la gestione della configurazione. Per altri esempi e link, consulta 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.

DANE (Domain Authentication of Named Entities), come specificato nel RFC 6698 e nei relativi RFC, utilizza i record TLSA in modi specifici per proteggere molti protocolli e 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.

Lo strumento di convalida DANE per i 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 disattivano la crittografia, e DANE offre un modo per prevenirli.

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 di convalida dell'email controlla anche DANE.

Verifica del certificato TLS XMPP (chat Jabber)

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

Associazione della chiave pubblica TXT (OpenPGP / GnuPG)

I record TXT possono essere utilizzati senza DNSSEC, ma i record TXT firmati DNSSEC forniscono una maggiore garanzia della loro 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 zona an.example firmata DNSSEC e ospita una copia della chiave pubblica con codifica ASCII all'URI specificato, Bob può cercare una chiave OpenPGP per alice@an.example 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 nel 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 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).KEYBASE_USERNAME

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 inviare email per un dominio.

• DKIM: pubblica un insieme di chiavi pubbliche utilizzate per verificare che le email vengano inviate da un dominio e protegge i messaggi da eventuali modifiche durante il transito.

• DMARC: specifica i criteri e i report del dominio per la convalida di SPF e DKIM e la generazione di 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 email. Per trovare consigli utili sulla configurazione dei record SPF, consulta Domande frequenti sugli errori comuni.

Utilizzare altri tipi di set di record ottimizzati da DNSSEC

Oltre ai record TXT, esistono alcuni altri tipi di set di record che beneficiano di 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.

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

IPSECKEY

Puoi anche attivare la crittografia opportunistica tramite i tunnel IPsec pubblicando record IPSECKEY. L'implementazione della VPN IPsec di strongSwan 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 di DNSSEC per le zone inverse è meno comune rispetto alle zone in avanti e richiede un provider di servizi internet (ISP) che implementi DNSSEC. Tuttavia, alcuni ISP possono supportare DNSSEC per le deleghe di zone inverse.

Le zone inverse per gli indirizzi IP esterni delle VM 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 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 la panoramica di Cloud DNS.