Utilizzare DNSSEC avanzate

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questa pagina fornisce varie opzioni di configurazione delle 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 negazione 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.

Delegare sottodomini firmati con DNSSEC

Puoi attivare DNSSEC per i sottodomini delegati dopo aver attivato DNSSEC per il tuo dominio principale. Per abilitare DNSSEC per sottodomini delegati, devi prima creare un record DS all'interno di 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 scaricare il record DS da Google Cloud Console o da Google Cloud CLI.

console

  1. In Google Cloud Console, 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, fai clic su Configurazione registrar nell'angolo in alto a destra della pagina Dettagli zona.

  4. Il record DS è disponibile nella pagina Registrar Impostazione.

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

Pagina di configurazione del registrar

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 con delega nel 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, è necessario l'ID della chiave KEY_SIGNING (KSK), generalmente pari a 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 pari a 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 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 del tuo progetto in cui stai creando i record per il sottodominio delegato.

    L'output ha il seguente aspetto:

    Transaction started [transaction.yaml].
    

  5. Successivamente, 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 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 ricevuto 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 i 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 principale nel 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.
    

    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 denial of esistere.

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

Il seguente comando abilita DNSSEC con ECDSA e NSEC a 256 bit per i pacchetti di risposta 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 di chiave KSK o ZSK, devi fornire tutti questi e i relativi argomenti nel comando:

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

Puoi specificare il rifiuto dell'esistenza come NSEC o NSEC3, indipendentemente dagli algoritmi.

Nella tabella seguente sono elencati gli argomenti e le opzioni degli algoritmi supportati. Cloud DNS non consente l'uso di altri algoritmi o parametri.

Algoritmo Vasche KSK ZSK vasche 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 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 (vedi 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 ai sistemi abbastanza recenti. I resolver meno recenti che non possono convalidare le zone con firma ECDSA li considerano non firmati, il che potrebbe non essere sicuro se utilizzi nuovi tipi di record che si basano su DNSSEC. Il supporto del registrar e del registry per ECDSA a 256 bit è comune, ma non universale. Solo pochi registri e ancora meno registrar supportano le funzionalità 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 veloci da calcolare.

Evita di utilizzare algoritmi diversi per KSK e ZSK nelle zone gestite; in questo modo ridurrai la compatibilità e potrebbe compromettere la sicurezza. Alcuni risolutori di convalida DNSSEC potrebbero non riuscire a convalidare per le zone con algoritmi DNSKEY non utilizzati per firmare tutti i record nella zona. Questo vale anche se RFC 6840 afferma "non devono insistere sul fatto che tutti gli algoritmi nel set di chiavi DNS RRset funzionino". Se questo non è un problema (la maggior parte dei resolver convalidanti segue RFC 6840), puoi utilizzare RSASHA256 per KSK ed ECDSA per ZSK se il registrar del tuo dominio o il registry dei domini di primo livello non supporta ECDSA e hai bisogno di dimensioni di risposta ridotte.

NSEC3 è il tipo di denial of service predefinito; offre una protezione limitata contro i camminatori della zona che cercano di scoprire tutti i record nella zona. Le impostazioni NSEC3PARAM sono fisse: NSEC3 opt-out è disattivato per sicurezza e c'è un'iterazione hash aggiuntiva (per un totale di due) con un alt di sale a 64 bit.

Il NSEC ha risposte leggermente più piccole, ma nessuna protezione contro le camminate della zona. L'utilizzo di NSEC può anche ridurre le query per i domini inesistenti. Google Public DNS e molti altri resolver con convalida DNSSEC possono sintetizzare le risposte negative dei record NSEC memorizzati nella cache senza eseguire query sulla zona Cloud DNS.

RFC 8624 contiene ulteriori indicazioni sulla selezione dell'algoritmo.

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

Una volta che il tuo dominio sarà completamente protetto da DNSSEC, puoi iniziare utilizzando diversi nuovi tipi di record DNS che sfruttano le garanzie di autenticità e integrità delle zone con firma 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. In genere i client SSH richiedono l'interazione dell'utente per confermare la chiave pubblica del server sulla 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 del record SSHFP è il seguente:

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

I numeri degli algoritmi per SSH sono i seguenti:

  1. RSA
  2. DSA
  3. ECDSA
  4. 25519 ED

I tipi di impronte digitali sono i seguenti:

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

StackExchange include suggerimenti per la creazione di SSHFP e sono disponibili 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 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 i certificati utilizzati da HTTPS) senza dipendere da uno dei preconfigurati CA (autorità di certificazione) preconfigurati.

In questo modo puoi configurare le tue CA e generare certificati per HTTPS. Questo consente anche la convalida di certificati per protocolli come SMTP che in genere non supportano le applicazioni per le autorità di certificazione attendibili preconfigurate.

DANE (Domain Authentication of Named Entities), come specificato in RFC 6698 e nelle relative RFC, utilizza i record TLSA in modi specifici per proteggere molti protocolli e applicazioni. L'IETF Journal e la Internet Society hanno un utile articolo introduttivo e panoramica DAI.

HTTPS

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

SIDNLabs' Lo strumento di convalida DANE per i server HTTPS è 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 fornisce un modo per impedire questi attacchi.

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

Puoi trovare consigli eccellenti (e uno strumento di convalida del dominio DANE per HTTPS e SMTP) alla pagina Errori comuni. Anche lo Strumento di convalida email verifica il DANE.

Verifica del certificato TLS XMPP (chat di Jabber)

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

Ad esempio, se Alice pubblica un record TXT come il seguente nella zona an.example con firma DNSSEC e ospita una copia della chiave pubblica con intestazione ASCII all'URI specificato, Bob può cercare una chiave OpenPGP in alice@an.example con sicurezza ragionevole (questa non sostituisce la convalida del Web attendibile, 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 versione 1 PKA (così come vengono chiamati nella pagina relativa alla pubblicazione delle chiavi in DNS).

La guida completa alla pubblicazione delle 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 su Keybase.io, non è necessario ospitare la chiave 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 chiave OpenPGP su un server delle chiavi, puoi anche utilizzare un URI hkp: per il server delle chiavi, 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 raggiungerla (alcuni server delle chiavi forniscono la porta 80 URL HTTP).

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 questo non funziona):

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

  • DKIM: pubblica una serie di chiavi pubbliche utilizzate per verificare che l'email venga inviata da un dominio e protegge i messaggi in fase di modifica in transito.

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

Per verificare che il tuo dominio sia configurato correttamente per utilizzare tutti e tre questi tipi di record, puoi utilizzare lo strumento di convalida dell'email. Per suggerimenti utili sulla configurazione dei record SPF, vedi Domande frequenti sugli errori comuni.

Utilizza altri tipi di set di record migliorati da DNSSEC

Oltre a TXT, esistono altri tipi di set di record che possono trarre vantaggio da DNSSEC, anche se non lo richiedono.

CAA

I set di record dell'autorità di certificazione (CAA) ti consentono di controllare quali autorità di certificazione 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 di dominio convalidati (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 best-ca.example CA (e non ad altri CA) di emettere certificati per 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 di utilizzare DNSSEC.

IPSECKEY

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

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

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

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

Passaggi successivi