Skip to content
> 💻 🧠 Codice 1001 > 📑 Schede Riassuntive > 🖧 Guida completa ed esaustiva sui record DNS: dalle basi a DNSSEC e automazione

🖧 Guida completa ed esaustiva sui record DNS: dalle basi a DNSSEC e automazione

Il DNS (Domain Name System) è il sistema fondamentale su cui si basa l’intero internet moderno. Non è semplicemente una “rubrica telefonica”, ma un database complesso e distribuito che traduce i nomi leggibili dagli esseri umani (ad esempio, google.com) in identificatori tecnici come indirizzi IP, server di posta, politiche di sicurezza e persino coordinate geografiche. Una configurazione DNS errata è una delle cause più frequenti di indisponibilità dei siti web, problemi di consegna della posta e vulnerabilità della sicurezza.

Questa guida combina tutti gli aspetti del DNS: dai record di base utilizzati quotidianamente ai meccanismi complessi come DNSSEC e DANE. Esamineremo ogni tipo di record, il suo scopo, la sintassi, esempi pratici, errori comuni, comandi per la diagnosi e modelli pronti per la distribuzione. Le informazioni sono strutturate in modo da poter utilizzare questo materiale come libro di testo, riferimento per l’amministratore e checklist per gli ambienti di produzione.

In Questo Articolo
  1. 1. Terminologia
  2. 2. Analisi dettagliata di tutti i tipi di record
  3. 3. Raccomandazioni pratiche e sfumature di configurazione
  4. 4. Modelli completi di file di zona (stile BIND)
  5. 5. Configurazione passo-passo del dominio di posta (PTR, SPF, DKIM, DMARC)
  6. 6. Comandi per la verifica e il debug DNS
  7. 7. Sicurezza e best practice
  8. 8. Errori comuni e come evitarli
  9. 9. Checklist prima del rilascio in produzione o migrazione
  10. 10. Esempi aggiuntivi e spiegazioni dei campi
  11. 11. Scenari utili
  12. 12. JSON pronto per l’importazione nel pannello del provider

1. Terminologia

Prima di approfondire i tipi di record, è fondamentale comprendere i termini chiave utilizzati nel DNS. Questo stabilisce una base linguistica comune e aiuta a evitare confusione.

  • DNS (Domain Name System): Il Sistema dei Nomi di Dominio. Un database distribuito globale che traduce i nomi di dominio in indirizzi IP e altre informazioni correlate.
  • Nome di dominio (Domain Name): Un indirizzo leggibile dall’uomo su internet, ad esempio, example.com. È composto da etichette separate da punti.
  • FQDN (Fully Qualified Domain Name): Un nome di dominio completo che identifica in modo univoco un nodo nella gerarchia DNS. Termina sempre con un punto che denota la radice DNS (ad esempio, www.example.com.).
  • Zona (Zone): Un’unità amministrativa nel DNS. Una porzione dello spazio dei nomi gestita da un server autorevole (o un gruppo di server). Di solito corrisponde a un dominio o sottodominio.
  • File di zona (Zone File): Un file di testo memorizzato su un server DNS che contiene tutti i record per una zona specifica. Utilizza la sintassi definita dallo standard BIND.
  • Record (Resource Record, RR): L’unità di base dei dati nel DNS. Ogni record ha un tipo, un nome, un valore e un TTL.
  • Tipo di record (Record Type): Definisce quali informazioni contiene il record (ad esempio, A, MX, TXT). Ogni tipo corrisponde a un codice numerico univoco (ad esempio, 1 per A, 15 per MX).
  • TTL (Time To Live): La durata della vita del record, specificata in secondi. Determina per quanto tempo i resolver e altri server DNS possono memorizzare nella cache il record prima di richiederlo nuovamente al server autorevole.
  • Resolver: Un client o server DNS che riceve una richiesta da un’applicazione (ad esempio, un browser) ed esegue le query necessarie per ottenere una risposta. Può essere ricorsivo (esegue l’intera catena di query) o non ricorsivo.
  • Server autorevole (Authoritative Server): Un server DNS che memorizza i record originali per una zona specifica ed è responsabile di essi. Risponde alle query utilizzando i dati del file di zona.
  • Server ricorsivo (Recursive Server): Un server che riceve una richiesta da un client e, se non ha la risposta nella sua cache, esegue una catena di query, a partire dai server radice, per trovare il server autorevole e ottenere la risposta.
  • Server radice (Root Server): Uno dei 13 gruppi di server (indicati con le lettere da a.root-servers.net. a m.root-servers.net.) che sono il punto di partenza per risolvere qualsiasi nome di dominio. Sanno dove si trovano i server per i domini di primo livello (TLD).
  • TLD (Top-Level Domain): Un dominio di primo livello. L’ultima parte di un nome di dominio (ad esempio, .com, .org, .ru, .io).
  • Registrar: L’azienda attraverso la quale vengono registrati i nomi di dominio. Gestisce le informazioni di delega (quali server NS servono il dominio) nella zona genitore (ad esempio, nella zona .com per il dominio example.com).
  • Registrante (Registrant): Il proprietario del nome di dominio.
  • Delega (Delegation): Il processo di trasferimento del controllo di un sottodominio (o dominio) dalla zona genitore a quella figlia. Viene realizzato utilizzando record NS nella zona genitore.
  • Record Glue (Glue Record): Un record A o AAAA pubblicato dal registrar per un server dei nomi il cui nome di dominio si trova all’interno della zona delegata. Necessario per rompere una dipendenza circolare.
  • SOA (Start of Authority): Un record che contiene informazioni amministrative sulla zona, inclusi il server primario, il contatto dell’amministratore e i parametri che controllano il trasferimento della zona ai server secondari.
  • Numero di serie (Serial Number): Un campo nel record SOA che indica la versione della zona. I server secondari lo utilizzano per determinare se è necessario un aggiornamento.
  • Risoluzione diretta (Forward Resolution): Il processo di conversione di un nome di dominio in un indirizzo IP (ad esempio, example.com → 192.0.2.1).
  • Risoluzione inversa (Reverse Resolution): Il processo di conversione di un indirizzo IP in un nome di dominio (ad esempio, 192.0.2.1 → example.com). Gestito attraverso le zone in-addr.arpa (per IPv4) e ip6.arpa (per IPv6).
  • Cache: Un’archiviazione temporanea per i record DNS su un resolver o un server DNS per accelerare le richieste successive.
  • Memorizzazione nella cache (Caching): Il processo di salvataggio dei record DNS in una cache.
  • Memorizzazione nella cache negativa (Negative Caching): Memorizzazione nella cache delle informazioni che il record richiesto non esiste.
  • RFC (Request for Comments): Un documento ufficiale che descrive standard, protocolli e procedure su internet. Tutti gli aspetti principali del DNS sono descritti in una serie di RFC.
  • BIND (Berkeley Internet Name Domain): L’implementazione più comune di un server DNS. La sintassi dei suoi file di zona è diventata lo standard de facto.
  • MTA (Mail Transfer Agent): Un server di posta responsabile del trasferimento delle email (ad esempio, Postfix, Exim, Sendmail).
  • FCrDNS (Forward-Confirmed Reverse DNS): Un meccanismo di verifica in cui un indirizzo IP ha un record PTR che si risolve in un nome di dominio, e quel nome di dominio, a sua volta, ha un record A che punta all’indirizzo IP originale. Critico per la reputazione del server di posta.
  • DNSSEC (Domain Name System Security Extensions): Un insieme di estensioni che aggiungono firme crittografiche ai record DNS per garantirne autenticità e integrità.
  • DANE (DNS-based Authentication of Named Entities): Uno standard che consente di collegare i certificati TLS ai nomi DNS utilizzando record TLSA. Richiede che DNSSEC sia abilitato.
  • CAA (Certification Authority Authorization): Un meccanismo che consente al proprietario di un dominio di specificare quali autorità di certificazione (CA) sono autorizzate a emettere certificati per esso.
  • SPF (Sender Policy Framework): Un meccanismo che consente al proprietario di un dominio di specificare quali server sono autorizzati a inviare posta a suo nome.
  • DKIM (DomainKeys Identified Mail): Un meccanismo che consente di firmare digitalmente le email in uscita, firma che il destinatario può verificare utilizzando una chiave pubblica pubblicata nel DNS.
  • DMARC (Domain-based Message Authentication, Reporting & Conformance): Una politica che definisce come i server di posta devono gestire le email che non superano i controlli SPF o DKIM e configura l’invio di rapporti al proprietario del dominio.
  • ALIAS / ANAME: Tipi di record non standard offerti da alcuni provider DNS. Consentono di creare alias per il dominio radice (apex), cosa impossibile con un CNAME standard.
  • CNAME Flattening: Una tecnologia utilizzata da alcuni provider DNS. Quando un CNAME viene interrogato per un dominio apex, il server risolve automaticamente la catena CNAME e restituisce i record A/AAAA finali al client, evitando la violazione della RFC.

2. Analisi dettagliata di tutti i tipi di record

Tutti gli esempi sono forniti nel formato di file di zona stile BIND. I nomi che terminano con un punto (ad esempio, example.com.) sono FQDN. Il TTL (Time To Live) è specificato in secondi e determina per quanto tempo il record può essere memorizzato nella cache dai resolver.

A — Record di indirizzo (IPv4)

  • Scopo: Collega un nome di dominio a un indirizzo IPv4 a 32 bit. Il record più basilare e frequentemente utilizzato.
  • Formato: nome TTL IN A indirizzo-IPv4
  • Esempio:
    example.com. 3600 IN A 192.0.2.1 www.example.com. 3600 IN A 192.0.2.1
  • Quando utilizzato: Per specificare l’indirizzo IP di un server web, API, server di gioco o qualsiasi altro servizio accessibile tramite IPv4.
  • Verifica: dig +short example.com A
  • Migliori pratiche:
    • L’utilizzo di un record A per il dominio radice (apex, @) è una pratica standard e corretta.
    • Scegliere il TTL in base alla stabilità dell’indirizzo IP. Per indirizzi stabili — 3600 (1 ora) o 86400 (1 giorno). Prima della migrazione — ridurre a 300 (5 minuti).

AAAA — Record di indirizzo IPv6

  • Scopo: Analogico al record A, ma per indirizzi IPv6 a 128 bit. Criticamente importante per il futuro di internet.
  • Formato: nome TTL IN AAAA indirizzo-IPv6
  • Esempio:
    example.com. 3600 IN AAAA 2001:db8::1
  • Quando utilizzato: Per garantire la disponibilità del servizio tramite il protocollo IPv6.
  • Verifica: dig +short example.com AAAA

CNAME — Record di nome canonico

  • Scopo: Crea un alias per un nome di dominio. Qualsiasi richiesta a un CNAME viene automaticamente convertita in una richiesta al suo nome di destinazione (canonico).
  • Formato: nome TTL IN CNAME destinazione.
  • Esempio:
    www.example.com. 3600 IN CNAME example.com. blog.example.com. 3600 IN CNAME blog-hosting.example.net.
  • Restrizioni importanti:
    • Conflitto di record: Non è possibile avere un CNAME e qualsiasi altro record (A, MX, TXT, ecc.) per lo stesso nome. Questa è una violazione della RFC.
    • Dominio Apex: Lo standard RFC vieta l’uso di CNAME per il dominio radice (ad esempio, example.com.) perché contiene già record NS e SOA. Per risolvere questo problema, i provider DNS (Cloudflare, AWS Route 53) offrono estensioni non standard: ALIAS o ANAME, che risolvono l’alias in record A/AAAA al volo.
  • Applicazione pratica: Connessione a un CDN (fare di www un CNAME all’indirizzo del CDN), utilizzo di piattaforme SaaS (blog, negozio).
  • Verifica: dig +short www.example.com CNAME

MX — Record di scambio di posta

  • Scopo: Specifica i server che accettano la posta in entrata per il dominio. Il record contiene una priorità: più piccolo è il numero, più alta è la priorità.
  • Formato: nome TTL IN MX priorità server_di_posta.
  • Esempio:example.com. 3600 IN MX 10 mail1.example.com. example.com. 3600 IN MX 20 mail2.example.com.
    • La posta verrà prima inviata a mail1.example.com.. Se non è disponibile, l’MTA (Mail Transfer Agent) proverà mail2.example.com..
  • Requisiti chiave:
    • Il server di posta (mail1.example.com.) deve avere il proprio record A o AAAA.
    • Un record PTR deve essere configurato per l’indirizzo IP del server di posta, e deve corrispondere al nome del server specificato in MX. Questo è critico per la reputazione del server e la consegna della posta.
  • Verifica: dig +short example.com MX

TXT — Record di testo

  • Scopo: Memorizza dati di testo arbitrari. Ampiamente utilizzato per le politiche di sicurezza della posta elettronica (SPF, DKIM, DMARC), la verifica della proprietà del dominio (Google, Microsoft, Yandex) e altri scopi.
  • Formato: nome TTL IN TXT "testo"
  • Esempi:
    • SPF (Sender Policy Framework): Definisce quali server sono autorizzati a inviare posta a nome del dominio. example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all"
      • ip4:192.0.2.0/24 — consente l’intera sottorete.
      • include:_spf.google.com — include le regole della zona di Google (per Gmail).
      • ~all — “fallimento morbido” per tutti gli altri (softfail). -all — fallimento rigoroso (fail).
    • DKIM (DomainKeys Identified Mail): Pubblica la chiave pubblica per verificare la firma digitale aggiunta alle email in uscita. Generalmente creato per un sottodominio come selettore._domainkey.dominio. default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
      • v=DKIM1 — versione.
      • k=rsa — tipo di chiave.
      • p=... — la chiave pubblica stessa in formato base64.
    • DMARC (Domain-based Message Authentication, Reporting & Conformance): Imposta la politica per gestire le email che non superano i controlli SPF o DKIM e configura l’invio di rapporti. _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
      • p=reject — rifiutare le email che non superano la verifica.
      • rua=mailto:... — indirizzo per i rapporti aggregati.
      • ruf=mailto:... — indirizzo per i rapporti forensi (fallimenti specifici).
      • pct=100 — applicare la politica al 100% delle email.
    • Verifica: example.com. 3600 IN TXT "google-site-verification=abc123..."
  • Note:
    • Se una stringa di testo è più lunga di 255 byte, può essere divisa in più parti nel file di zona, con ogni parte racchiusa tra virgolette. Il server DNS le concatenerà automaticamente.
      example.com. IN TXT ("v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; " "pct=100; fo=1")
  • Verifica: dig +short example.com TXT

NS — Record del server dei nomi

  • Scopo: Specifica i server DNS che sono autorevoli per la zona. Questi record sono la base per delegare la gestione del dominio.
  • Formato: nome TTL IN NS nome_del_server.
  • Esempio:
    example.com. 3600 IN NS ns1.example.net. example.com. 3600 IN NS ns2.example.net.
  • Punti importanti:
    • I record NS nella zona devono corrispondere esattamente ai server dei nomi specificati con il registrar del dominio.
    • Record Glue: Se il server dei nomi (ad esempio, ns1.example.com.) si trova all’interno della stessa zona che serve (example.com.), si verifica una dipendenza circolare. Per romperla, aggiungere record “glue” — record A o AAAA per questi server dei nomi — con il registrar.
  • Verifica: dig +short example.com NS

SOA — Record di inizio autorità

  • Scopo: Il record amministrativo principale di una zona DNS. Contiene informazioni sul server primario, l’amministratore e i parametri che controllano la sincronizzazione tra il server primario e quelli secondari.
  • Formato:
    nome TTL IN SOA server_primario. email_amministratore. ( numero_di_serie ; Serial intervallo_di_aggiornamento ; Refresh intervallo_di_ritentativo ; Retry tempo_di_scadenza ; Expire ttl_minimo ) ; Minimum TTL
  • Esempio:
    example.com. 3600 IN SOA ns1.example.net. admin.example.com. ( 2025092201 ; Serial (YYYYMMDDNN) 7200 ; Refresh (2 ore) 3600 ; Retry (1 ora) 1209600 ; Expire (14 giorni) 86400 ) ; Minimum TTL (1 giorno)
  • Spiegazioni dei campi:
    • Serial: Versione della zona. È estremamente importante incrementare questo numero ad ogni modifica della zona. I server secondari confrontano il loro Serial con il Serial sul server primario e, se è più piccolo, richiedono un aggiornamento. Formato consigliato: YYYYMMDDNN (anno, mese, giorno, numero di revisione del giorno).
    • Refresh: Intervallo (in secondi) dopo il quale i server secondari devono verificare il server primario per gli aggiornamenti.
    • Retry: Intervallo dopo il quale un server secondario deve riprovare se il primo tentativo di aggiornamento fallisce.
    • Expire: Tempo (in secondi) dopo il quale un server secondario smetterà di rispondere alle query se non può contattare il server primario. La zona è considerata “scaduta”.
    • Minimum TTL: Inizialmente impostava il TTL minimo per tutti i record nella zona. Ora spesso utilizzato come TTL per la memorizzazione nella cache negativa (per quanto tempo memorizzare nella cache una risposta “record non trovato”).
  • Verifica: dig +short example.com SOA

PTR — Record puntatore (DNS inverso)

  • Scopo: Fornisce risoluzione inversa — converte un indirizzo IP in un nome di dominio. Gestito dal proprietario dell’indirizzo IP (ISP, provider di hosting), non dal proprietario del dominio.
  • Formato per IPv4: L’indirizzo IP è scritto in ordine inverso, e viene aggiunto il suffisso .in-addr.arpa..
    • IP 192.0.2.5 → 5.2.0.192.in-addr.arpa.
  • Formato per IPv6: Ogni parte di 4 bit (nibble) dell’indirizzo è scritta in ordine inverso, e viene aggiunto il suffisso .ip6.arpa..
    • IPv6 2001:db8::1 → 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
  • Esempio (IPv4):
    5.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.
  • Significato pratico: Criticamente importante per i server di posta. La maggior parte dei sistemi di posta verifica che il record PTR per l’indirizzo IP del mittente corrisponda al nome che il server presenta nel comando HELO/EHLO. Una discrepanza è una ragione frequente per cui le email vengono contrassegnate come spam.
  • Verifica: dig -x 192.0.2.5 +short o host 192.0.2.5

SRV — Record di servizio

  • Scopo: Specifica la posizione dei server per servizi specifici, inclusi protocollo e porta. Consente ai client di trovare automaticamente il server necessario.
  • Formato del nome:_servizio._protocollo.dominio.
    • Servizio: sip, xmpp-server, _minecraft, ecc.
    • Protocollo: tcp, udp.
  • Formato del record: nome TTL IN SRV priorità peso porta destinazione.
  • Esempio:
    _sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com. _minecraft._tcp.example.com. 3600 IN SRV 5 0 25565 mc1.example.com.
  • Spiegazioni dei campi:
    • Priority (Priorità): Più piccolo è il numero, più alta è la priorità. Il client proverà prima a connettersi al server con la priorità più bassa.
    • Weight (Peso): Utilizzato per il bilanciamento del carico tra server con la stessa priorità. La probabilità di selezionare un server è proporzionale al suo peso. Se tutti i pesi sono uguali, la selezione è casuale.
    • Port (Porta): La porta su cui il servizio è in esecuzione.
    • Target (Destinazione): Il FQDN del server a cui deve essere diretta la richiesta. Questo server deve avere un record A o AAAA.
  • Applicazione: VoIP (SIP), messaggistica istantanea (XMPP), giochi (Minecraft), directory (LDAP).
  • Verifica: dig +short _sip._tcp.example.com SRV

CAA — Autorizzazione dell’autorità di certificazione

  • Scopo: Consente al proprietario del dominio di specificare quali autorità di certificazione (CA) sono autorizzate a emettere certificati SSL/TLS per questo dominio. Questo è un meccanismo di sicurezza importante per prevenire l’emissione non autorizzata di certificati.
  • Formato: nome TTL IN CAA flag tag valore
  • Esempio:
    example.com. 3600 IN CAA 0 issue "letsencrypt.org" example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
  • Spiegazioni:
    • Flags: Generalmente 0. Il flag 128 (critico) significa che una CA che non comprende questo tag deve rifiutare di emettere il certificato.
    • Tags:
      • issue: Consente alla CA specificata di emettere certificati. Un valore vuoto (;) vieta l’emissione da parte di chiunque.
      • issuewild: Consente l’emissione di certificati wildcard (*.example.com).
      • iodef: URL (generalmente mailto: o http(s):) per inviare rapporti sui tentativi di violazione della politica CAA.
  • Verifica: dig +short example.com CAA

NAPTR — Record puntatore dell’autorità dei nomi

  • Scopo: Utilizzato per regole complesse di riscrittura di nomi e URI. Più spesso applicato nei sistemi di telecomunicazione (ENUM per convertire i numeri di telefono in URI SIP) e per la scoperta dinamica dei servizi.
  • Formato: nome TTL IN NAPTR ordine preferenza flag servizio espressione_regolare sostituzione.
  • Esempio (semplificato per ENUM):
    4.3.2.1.5.5.5.1.e164.arpa. IN NAPTR 100 10 "U" "E2U+sip" "!^.*$!sip:info@example.com!" .
  • Spiegazioni:
    • Order (Ordine): Elaborato dal più piccolo al più grande.
    • Preference (Preferenza): Analogico al weight in SRV per record con lo stesso order.
    • Flags: U significa che il risultato è un URI (ad esempio, sip:).
    • Service: Tipo di servizio (ad esempio, E2U+sip — conversione in URI SIP).
    • Regexp: Espressione regolare per trasformare la stringa di input.
    • Replacement: Alternativa all’espressione regolare (generalmente vuota se si usa regexp).
  • Applicazione: Scenari di routing complessi in VoIP, ENUM.

TLSA — Record di associazione certificato TLSA (DANE)

  • Scopo: Collega un certificato TLS (o parte di esso) a un nome DNS utilizzando un record DNS. Questo fa parte dello standard DANE (Autenticazione Basata su DNS di Entità Nominate). Richiede che DNSSEC sia abilitato per garantire la fiducia; altrimenti, il record può essere falsificato.
  • Formato del nome: _porta._protocollo.nome.
  • Formato del record: nome TTL IN TLSA utilizzo selettore tipo_di_corrispondenza dati
  • Esempio:
    _443._tcp.www.example.com. 3600 IN TLSA 3 1 1 d2abde...f21
  • Spiegazioni dei campi:
    • Usage (Utilizzo):
      • 3 (DANE-EE): Certificato entità finale. Il più comune.
      • 1 (PKIX-EE): Certificato entità finale, deve essere firmato da una CA attendibile.
      • 2 (DANE-TA): Certificato dell’autorità di certificazione attendibile.
      • 0 (PKIX-TA): Certificato CA, deve essere nella catena di fiducia.
    • Selector (Selettore):
      • 0: Certificato completo.
      • 1: Solo la chiave pubblica del certificato.
    • Matching Type (Tipo di corrispondenza):
      • 0: Dati esatti (non utilizzato).
      • 1: Hash SHA-256.
      • 2: Hash SHA-512.
    • Data: Hash del certificato o della sua chiave pubblica in formato esadecimale.
  • Applicazione: Miglioramento della sicurezza TLS, specialmente negli ambienti in cui non ci si può fidare delle CA pubbliche.
  • Verifica: dig +short _443._tcp.www.example.com. TLSA

Record DNSSEC (DNSKEY, DS, RRSIG, NSEC, NSEC3)

DNSSEC (Estensioni di Sicurezza del Sistema dei Nomi di Dominio) è un insieme di estensioni che aggiungono firme crittografiche ai record DNS per proteggere contro la falsificazione (spoofing) e gli attacchi di avvelenamento della cache.

  • Principio generale: La zona è firmata con una chiave privata. La chiave pubblica è pubblicata in un record DNSKEY. Per creare una catena di fiducia, l’hash di questa chiave (DS record) è pubblicato nella zona genitore (ad esempio, per example.com — nella zona .com). I client che supportano DNSSEC possono verificare la firma (RRSIG) di ogni record utilizzando la chiave pubblica e assicurarsi della sua autenticità.
  • DNSKEY: La chiave pubblica della zona.
    • Esempio:example.com. 3600 IN DNSKEY 257 3 13 AwEAAa3d...9QAB
      • 257 — flag (257 = KSK, 256 = ZSK).
      • 3 — protocollo (sempre 3).
      • 13 — algoritmo (13 = ECDSA/SHA256).
      • Ultimo campo — chiave in base64.
  • DS (Delegation Signer): Hash della chiave pubblica (DNSKEY) della zona figlia, pubblicato nella zona genitore per creare una catena di fiducia.
    • Esempio:example.com. 3600 IN DS 54517 13 2 84C8...D34F
      • 54517 — Key Tag (identificatore chiave).
      • 13 — Algoritmo.
      • 2 — Tipo di digest (SHA-256).
      • Ultimo campo — hash in esadecimale.
  • RRSIG (Resource Record Signature): Firma digitale per un insieme di record DNS.
    • Esempio (firma per record A):example.com. 3600 IN RRSIG A 13 2 3600 20251001000000 20250901000000 54517 example.com. oNvL...7Q==
      • A — tipo di record firmati.
      • 13 — algoritmo.
      • 2 — numero di etichette nel nome.
      • 3600 — TTL originale.
      • 20251001000000 — tempo di scadenza della firma.
      • 20250901000000 — tempo di inizio della firma.
      • 54517 — Key Tag della chiave di firma.
      • example.com. — nome del firmatario.
      • Ultimo campo — firma in base64.
  • NSEC / NSEC3: Utilizzati per autenticare risposte negative (prova che un record con tale nome o tipo non esiste). NSEC3 applica inoltre l’hash ai nomi per proteggere contro le “passeggiate di zona”.
  • Abilitazione di DNSSEC: Questo è un processo separato e complesso:
    1. Generare coppie di chiavi (KSK e ZSK) sul server DNS.
    2. Pubblicare record DNSKEY nella zona.
    3. Generare un record DS dal KSK.
    4. Pubblicare il record DS con il registrar del dominio (nella zona genitore).
    5. Abilitare la firma della zona sul server DNS (generazione automatica di RRSIG, NSEC/NSEC3).
    6. Testare utilizzando dig +dnssec e strumenti online (ad esempio, Verisign DNSSEC Debugger).
  • Verifica:
    • dig +dnssec example.com A (mostrerà RRSIG per il record A se DNSSEC è abilitato e funzionante).
    • dig +short example.com DNSKEY
    • dig +short example.com DS

SSHFP — Impronta digitale della chiave pubblica SSH

  • Scopo: Pubblica l’hash (impronta digitale) della chiave SSH dell’host nel DNS. I client SSH possono utilizzare questo record per verificare automaticamente l’autenticità del server al primo collegamento, prevenendo gli attacchi “man-in-the-middle” (MITM). Si consiglia di utilizzarlo con DNSSEC per garantire l’autenticità del record.
  • Formato: nome TTL IN SSHFP algoritmo tipo_di_digest impronta_digitale
  • Esempio:
    example.com. 3600 IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
  • Spiegazioni:
    • Algorithm (Algoritmo):
      • 1 — RSA
      • 2 — DSA
      • 3 — ECDSA
      • 4 — ED25519
    • Digest Type (Tipo di digest):
      • 1 — SHA-1
      • 2 — SHA-256
    • Fingerprint: Hash della chiave pubblica in formato esadecimale.
  • Generazione: Sul server, è possibile generare il record con il comando: ssh-keygen -r example.com
  • Verifica: dig +short example.com SSHFP

Record rari e di servizio

  • HINFO (Informazioni sull’host): Memorizza informazioni sul tipo di CPU e sistema operativo dell’host. Non consigliato per l’uso poiché rivela informazioni potenzialmente sensibili sul sistema.
    • Esempio: server1.example.com. 3600 IN HINFO "Intel Xeon" "Ubuntu 22.04"
  • LOC (Posizione): Memorizza le coordinate geografiche (latitudine, longitudine, altitudine) dell’host.
    • Esempio: example.com. 3600 IN LOC 55 45 21.000 N 37 37 03.000 E 15m
  • RP (Persona responsabile): Specifica la persona di contatto responsabile della zona. L’email è specificata nel formato hostname (punto invece di @).
    • Esempio: example.com. 3600 IN RP admin.example.com. txt-record.example.com.
  • SPF (obsoleto): Esisteva precedentemente come tipo di record separato ma ora è completamente sostituito da TXT. Non deve essere utilizzato.
    • Esempio (non utilizzare): example.com. IN SPF "v=spf1 ..."

3. Raccomandazioni pratiche e sfumature di configurazione

  • Gestione del TTL:
    • Valore standard: 3600 secondi (1 ora) — un buon equilibrio tra prestazioni (cache) e flessibilità.
    • Prima della migrazione: Ridurre il TTL per i record pertinenti (ad esempio, A/AAAA per il proprio sito web) a 300 secondi (5 minuti) 24-72 ore prima del cambiamento previsto. Questo riduce il tempo di propagazione dei cambiamenti.
    • Dopo la migrazione: Una volta che i cambiamenti si sono stabilizzati, aumentare il TTL a un valore ottimale (ad esempio, 3600 o 86400) per ridurre il carico sui server DNS.
  • SOA Serial:
    • Incrementare sempre il numero di serie dopo ogni modifica della zona. Se non lo si fa, i server secondari non saranno informati degli aggiornamenti.
    • Formato consigliato: YYYYMMDDNN (ad esempio, 2024051701). Questo è chiaro e consente di tenere traccia facilmente di quando è stata effettuata l’ultima modifica.
  • CNAME su Apex (Dominio radice):
    • Problema: Lo standard RFC vieta CNAME sul dominio apex (ad esempio, example.com.) perché entra in conflitto con altri record obbligatori (NS, SOA).
    • Soluzione: Utilizzare le funzionalità fornite dal proprio provider DNS:
      • ALIAS/ANAME: Tipi di record non standard che si comportano come CNAME ma vengono risolti dal server DNS del provider in record A/AAAA per la risposta del client. Questo consente di utilizzare alias sull’apex.
      • CNAME Flattening: Una tecnologia (ad esempio, in Cloudflare) in cui un CNAME sull’apex viene “appiattito” automaticamente — il server DNS restituisce i record A/AAAA dell’host di destinazione invece del CNAME.
  • Record Glue:
    • Quando necessari: Se i propri server dei nomi (ad esempio, ns1.example.com.) si trovano all’interno della stessa zona che servono (example.com.).
    • Cosa fare: Trovare la sezione di configurazione dei record glue con il proprio registrar di dominio e aggiungere record A (e/o AAAA) per i propri server dei nomi. Questo rompe la dipendenza circolare.
  • Configurazione di PTR per la posta:
    • Requisito: L’indirizzo IP del proprio server di posta deve avere un record PTR che si risolva nel suo nome di dominio completamente qualificato (FQDN, ad esempio, mail.example.com.).
    • Coerenza: Il nome che il server di posta invia nel comando HELO/EHLO deve corrispondere al nome del record PTR, e quel nome, a sua volta, deve avere un record A che punta allo stesso indirizzo IP. Questo si chiama “Forward-Confirmed Reverse DNS” (FCrDNS) ed è critico per la reputazione.
    • Dove configurare: Con il proprio provider di hosting o proprietario dell’indirizzo IP, non nella zona DNS del proprio dominio.
  • Divisione di record TXT lunghi:
    • Se una stringa in un record TXT supera i 255 byte, deve essere divisa in più parti nel file di zona. Ogni parte è racchiusa tra virgolette, e il server DNS le concatena automaticamente.
    • Esempio:
      example.com. IN TXT ( "v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:dmarc@thirdparty.com; " "ruf=mailto:forensics@example.com; fo=1; adkim=s; aspf=s; pct=100" )

4. Modelli completi di file di zona (stile BIND)

Di seguito sono riportati modelli pronti per tre scenari comuni. Sostituire example.com, example.net, indirizzi IP e chiavi con i propri valori.

a) Sito web semplice (statico, senza posta)

$TTL 3600
@   IN SOA ns1.hosting.net. hostmaster.example.com. (
        2025092201 ; serial (YYYYMMDDNN)
        7200       ; refresh (2 hours)
        3600       ; retry (1 hour)
        1209600    ; expire (14 days)
        86400 )    ; minimum TTL (1 day)

; Authoritative Name Servers
@       IN NS   ns1.hosting.net.
@       IN NS   ns2.hosting.net.

; Web Server (IPv4 and IPv6)
@       IN A    192.0.2.10
@       IN AAAA 2001:db8::10

; WWW subdomain (alias to apex)
www     IN CNAME @

; Security: Restrict Certificate Authorities
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

b) Sito web + server di posta proprio

$TTL 3600
@   IN SOA ns1.example.net. admin.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        86400 )    ; minimum

; Name Servers
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Web Section ---
@       IN A    192.0.2.10
www     IN CNAME @

; --- Mail Section ---
; A record for the mail server
mail    IN A    192.0.2.20

; MX record pointing to the mail server
@       IN MX   10 mail.example.com.

; --- Email Authentication ---
; SPF: Allow mail server IP and Google Workspace
@       IN TXT  "v=spf1 ip4:192.0.2.20 include:_spf.google.com ~all"

; DKIM: Public key for 'default' selector
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

; DMARC: Policy to quarantine failures and send reports
_dmarc  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

; --- Security ---
@       IN CAA  0 issue "letsencrypt.org"

c) Sito web + CDN + Posta + DNSSEC (esempio complesso)

$TTL 300 ; Lower TTL for flexibility with CDN
@   IN SOA ns1.example.net. hostmaster.example.com. (
        2025092201 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        3600 )     ; minimum (also used for negative caching)

; Name Servers
@       IN NS   ns1.example.net.
@       IN NS   ns2.example.net.

; --- Web Section (with CDN) ---
; Apex domain: Use ALIAS/ANAME (provider-specific) to point to origin or CDN edge
; If your provider supports ALIAS:
; @     IN ALIAS origin.examplehost.net.
; If using CNAME flattening for apex (e.g., Cloudflare):
@       IN A    192.0.2.10 ; Temporary or fallback IP, often managed by provider

; WWW subdomain: CNAME to CDN provider
www     IN CNAME cdn-provider.example.net.

; --- Mail Section ---
mail    IN A    192.0.2.20
@       IN MX   10 mail.example.com.

; --- Email Authentication ---
@       IN TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."
_dmarc  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:abuse@example.com; pct=100"

; --- Security ---
@       IN CAA  0 issue "letsencrypt.org"
@       IN CAA  0 issuewild "letsencrypt.org"
@       IN CAA  0 iodef "mailto:security@example.com"

; --- DNSSEC (Example keys - REPLACE WITH YOURS) ---
; DNSKEY records (usually auto-generated by DNS server when signing is enabled)
@       IN DNSKEY 257 3 13 ( ; KSK
        AwEAAbOv...QAB )
@       IN DNSKEY 256 3 13 ( ; ZSK
        AwEAAa3d...9QAB )

; RRSIG records are automatically generated by the DNS server during signing and are not manually added to the zone file.
; NSEC/NSEC3 records are also automatically generated.

; --- Additional Services (Example) ---
; SRV record for SIP service
_sip._tcp IN SRV 10 50 5060 sip1.example.com.

5. Configurazione passo-passo del dominio di posta (PTR, SPF, DKIM, DMARC)

La configurazione della posta è un compito complesso. Seguire questi passaggi per garantire la massima consegna e protezione dallo spam.

Passo 1: Configurare A/AAAA per il server di posta
Assicurarsi che il proprio server di posta abbia un record A (e preferibilmente AAAA).

mail.example.com. 3600 IN A 192.0.2.20

Passo 2: Configurare i record MX
Specificare che la posta per example.com deve essere consegnata a mail.example.com..

example.com. 3600 IN MX 10 mail.example.com.

Passo 3: Configurare PTR (DNS inverso)
Questo è il passo più importante e spesso trascurato. Contattare il proprio provider di hosting o proprietario dell’indirizzo IP (192.0.2.20) e richiedere un record PTR che punti a mail.example.com..

  • Verifica: dig -x 192.0.2.20 +short dovrebbe restituire mail.example.com..

Passo 4: Configurare SPF (tramite TXT)
Definire quali server sono autorizzati a inviare posta a nome di example.com. Includere il proprio server e qualsiasi servizio di terze parti (Gmail, SendGrid, ecc.).

example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.20 include:_spf.google.com -all"
  • Iniziare con ~all (fallimento morbido) per i test, quindi passare a -all (fallimento rigoroso).

Passo 5: Configurare DKIM

  1. Generare una coppia di chiavi (privata e pubblica) sul proprio server di posta (MTA). Scegliere un “selettore” (ad esempio, default, 202405).
  2. Configurare l’MTA per firmare le email in uscita utilizzando la chiave privata e il selettore scelto.
  3. Pubblicare la chiave pubblica nel DNS come record TXT per il sottodominio selettore._domainkey.example.com..
    default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

Passo 6: Configurare DMARC
Definire la politica per gestire le email che non superano i controlli SPF/DKIM e configurare l’invio di rapporti.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; pct=100"
  • Strategia di implementazione:
    1. Iniziare con p=none — le email non vengono bloccate, si ricevono solo rapporti.
    2. Analizzare i rapporti, correggere gli errori in SPF/DKIM.
    3. Passare a p=quarantine — le email sospette vanno nello spam.
    4. Passare a p=reject — le email sospette vengono rifiutate.

Suggerimenti aggiuntivi:

  • Assicurarsi che il nome che il proprio server di posta invia nel comando HELO/EHLO corrisponda al nome del record PTR (mail.example.com.).
  • Utilizzare strumenti online per verificare la configurazione: mail-tester.com, mxtoolbox.com, dmarcian.com.

6. Comandi per la verifica e il debug DNS

Gli strumenti da riga di comando sono indispensabili per gli amministratori.

  • dig (Domain Information Groper) — lo strumento più potente e consigliato.
    • Query di base:
      • dig +short example.com A — ottenere solo l’indirizzo IPv4.
      • dig +short example.com AAAA — ottenere solo l’indirizzo IPv6.
      • dig +short example.com MX — ottenere i record MX.
      • dig +short example.com TXT — ottenere i record TXT (SPF, DKIM, DMARC).
      • dig +short www.example.com CNAME — ottenere CNAME.
      • dig +short _sip._tcp.example.com SRV — ottenere il record SRV.
    • DNS inverso:
      • dig -x 192.0.2.1 +short — ottenere PTR per IP.
    • Tracciamento della delega:
      • dig +trace example.com — mostra l’intero percorso dai server radice ai server autorevoli della propria zona. Ottimo per diagnosticare i problemi di delega.
    • Query a server specifico:
      • dig @ns1.example.net example.com SOA — richiedere il record SOA a un server dei nomi specifico.
    • Verifica DNSSEC:
      • dig +dnssec example.com A — eseguire una query con il flag DO (DNSSEC OK) e mostrare i record RRSIG se esistono.
      • dig +short example.com DNSKEY — ottenere i record DNSKEY.
      • dig +short example.com DS — ottenere il record DS (dalla zona genitore).
    • Verifica TLSA (DANE):
      • dig +short _443._tcp.www.example.com. TLSA
    • Verifica SSHFP:
      • dig +short example.com SSHFP
  • nslookup — strumento vecchio ma ancora incontrato.
    • nslookup -type=MX example.com
    • nslookup -type=TXT example.com
    • nslookup 192.0.2.1 (per PTR)
  • host — semplice e conveniente per query di base.
    • host -t A example.com
    • host -t MX example.com
    • host -t TXT example.com
    • host 192.0.2.1 (per PTR)
    • host -t sshfp example.com

7. Sicurezza e best practice

  • DNSSEC: Abilitare DNSSEC per domini critici. Questo protegge gli utenti da risposte DNS false. Iniziare con un dominio di prova per padroneggiare la procedura (generazione chiavi, pubblicazione DS con il registrar). Utilizzare validatori online per verificare.
  • CAA: Configurare sempre i record CAA. Questo è un modo semplice ed efficace per prevenire l’emissione non autorizzata di certificati per il proprio dominio. Specificare solo le CA che si utilizzano (ad esempio, letsencrypt.org).
  • Gestione delle chiavi DKIM: Generare regolarmente (ad esempio, annualmente) nuove coppie di chiavi DKIM. Pubblicare la nuova chiave pubblica nel DNS, configurare l’MTA per utilizzare il nuovo selettore e, dopo alcune settimane (assicurandosi che tutte le vecchie email firmate con la vecchia chiave siano state elaborate), eliminare il vecchio record TXT.
  • Privacy: Non pubblicare i record HINFO poiché rivelano informazioni su hardware e software che potrebbero essere utili agli attaccanti.
  • Query ANY: Molti resolver DNS pubblici (ad esempio, Google Public DNS, Cloudflare) non elaborano più le query ANY a causa del loro utilizzo negli attacchi DDoS. Non fare affidamento su di esse.

8. Errori comuni e come evitarli

  1. CNAME entra in conflitto con altri record: Non è possibile avere un CNAME e, ad esempio, un A o MX per lo stesso nome. Soluzione: Rivedere la struttura della propria zona. Utilizzare record A o ALIAS/ANAME per l’apex.
  2. Mancanza di PTR per il server di posta: Questa è la ragione principale per cui la posta finisce nello spam. Soluzione: Configurare sempre PTR con il proprio provider di hosting.
  3. Numero di serie SOA non modificato: Se non si incrementa il numero di serie, i server secondari non saranno informati degli aggiornamenti. Soluzione: Incrementare sempre Serial dopo qualsiasi modifica della zona. Automatizzare questo processo se possibile.
  4. Formattazione errata di record TXT lunghi: Se una stringa è più lunga di 255 byte e non è divisa in parti, può essere troncata o causare un errore. Soluzione: Dividere sempre le stringhe lunghe nei record TXT, racchiudendo ogni parte tra virgolette.
  5. DS errato durante l’abilitazione di DNSSEC: Se il record DS pubblicato con il registrar non corrisponde al proprio DNSKEY, la zona diventerà “non attendibile”, e i client con DNSSEC abilitato non potranno ottenere record da essa. Soluzione: Seguire attentamente le istruzioni del proprio server DNS e registrar. Verificare due volte gli hash.
  6. TTL elevato prima della migrazione: Se il TTL è elevato (ad esempio, 86400), dopo aver cambiato l’indirizzo IP, gli utenti raggiungeranno l’indirizzo vecchio per un giorno. Soluzione: Ridurre sempre il TTL uno o due giorni prima di una migrazione pianificata.
  7. CNAME sul dominio apex: L’uso diretto di CNAME per example.com. viola la RFC e può causare un comportamento imprevedibile. Soluzione: Utilizzare ALIAS/ANAME o CNAME flattening fornito dal proprio provider DNS.

9. Checklist prima del rilascio in produzione o migrazione

Utilizzare questo elenco per verifiche finali prima di lanciare o spostare un sito/servizio.

  • [ ] Record di base: A/AAAA per tutti gli host chiave (web, posta) sono configurati e puntano agli indirizzi IP corretti.
  • [ ] Posta: I record MX sono configurati e puntano a host con record A/AAAA.
  • [ ] DNS inverso: I record PTR per tutti gli indirizzi IP dei server di posta sono configurati e corretti (verificato tramite dig -x).
  • [ ] SPF: Il record TXT SPF è configurato, include tutte le fonti consentite e ha il meccanismo di terminazione corretto (-all o ~all).
  • [ ] DKIM: La chiave pubblica è pubblicata nel DNS, l’MTA è configurato per firmare le email. La firma è verificata su un’email di prova.
  • [ ] DMARC: Il record TXT DMARC è pubblicato. Per i nuovi deployment, si consiglia di iniziare con p=none.
  • [ ] Server dei nomi: I record NS nella zona corrispondono ai server specificati con il registrar. I record glue sono configurati se necessario.
  • [ ] Numero di serie SOA: Il numero di serie è stato incrementato dopo tutte le modifiche recenti.
  • [ ] CAA: I record CAA sono configurati per limitare l’emissione di certificati.
  • [ ] TTL: Il TTL è stato ridotto in anticipo (se era pianificata una migrazione).
  • [ ] Verifica: Verifiche eseguite utilizzando dig +trace, dig MX, dig TXT e strumenti online (ad esempio, MXToolbox).
  • [ ] DNSSEC (se abilitato): Il record DS è correttamente aggiunto con il registrar, le verifiche DNSSEC passano con successo.
  • [ ] Backup: L’esportazione della zona corrente è salvata.
  • [ ] Piano di rollback: I passaggi per annullare le modifiche in caso di fallimento sono chiaramente scritti.
  • [ ] Monitoraggio: I sistemi di monitoraggio sono configurati per tracciare la disponibilità dei server DNS e i cambiamenti nella zona.

10. Esempi aggiuntivi e spiegazioni dei campi

  • SRV — Approfondimento:_xmpp-client._tcp.example.com. 3600 IN SRV 5 20 5222 xmpp1.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 5 30 5222 xmpp2.example.com. _xmpp-client._tcp.example.com. 3600 IN SRV 10 100 5222 backup.example.com.
    • Il client contatterà prima i server con priorità 5 (xmpp1 e xmpp2).
    • Tra xmpp1 e xmpp2, la selezione sarà proporzionale al loro peso: xmpp1 ha il 40% di probabilità (20/(20+30)), xmpp2 — 60% (30/(20+30)).
    • Il server backup.example.com. (priorità 10) verrà utilizzato solo se entrambi i server con priorità 5 sono non disponibili.
  • TLSA — Decodifica dell’esempio:_443._tcp.www.example.com. IN TLSA 3 1 1 d2abde...f21
    • 3 (DANE-EE): Il client deve utilizzare questo certificato esatto (o la sua chiave pubblica), indipendentemente dalla catena di fiducia della CA.
    • 1 (Selettore): Il record memorizza l’hash non dell’intero certificato, ma solo della sua chiave pubblica. Questo è più conveniente perché quando si rilascia un certificato con la stessa chiave, non è necessario modificare il record TLSA.
    • 1 (Tipo di corrispondenza): Viene utilizzato l’hash SHA-256.
  • SSHFP — Decodifica dell’esempio:
    example.com. IN SSHFP 4 2 356a192b7913b04c54574d18c28d46e6395428ab
    • 4: Algoritmo — ED25519 (moderno e sicuro).
    • 2: Tipo di digest — SHA-256.
    • 356a19...28ab: Hash SHA-256 della chiave pubblica ED25519.

11. Scenari utili

  • Connessione di un sito web a un CDN:
    1. Generalmente, il provider CDN chiede di fare un CNAME per un sottodominio (ad esempio, www) al loro indirizzo (ad esempio, example.cdnprovider.com).
    2. Se si desidera utilizzare il CDN per il dominio radice (example.com), utilizzare la funzionalità ALIAS/ANAME o CNAME flattening del proprio provider DNS.
    3. Assicurarsi che il CDN sia correttamente configurato per funzionare con il proprio certificato SSL (spesso il CDN si occupa della terminazione SSL). Tenere conto dei record CAA è importante in questo caso.
  • Spostamento di un host (migrazione):
    1. 48-72 ore prima della migrazione: Ridurre il TTL per i record A/AAAA del proprio sito a 300 secondi.
    2. Attendere: Attendere che il vecchio TTL si “propaghi” (attendere un periodo pari al vecchio TTL, ad esempio, 3600 secondi).
    3. Il giorno della migrazione: Modificare i record A/AAAA per puntare ai nuovi indirizzi IP.
    4. Verifica: Utilizzare dig +short example.com A con diversi DNS pubblici (Google 8.8.8.8, Cloudflare 1.1.1.1) per verificare la propagazione dei cambiamenti.
    5. Dopo la stabilizzazione (dopo 24-48 ore): Aumentare il TTL a un valore ottimale (ad esempio, 3600).

12. JSON pronto per l’importazione nel pannello del provider

Di seguito è riportato un modello JSON esteso che contiene quasi tutti i tipi di record trattati in questa guida. Questo formato è generalizzato e potrebbe richiedere adattamenti all’API specifica del proprio provider DNS (Cloudflare, AWS Route 53, DigitalOcean, ecc.).

{
  "zone": "example.com",
  "records": [
    {
      "type": "A",
      "name": "@",
      "value": "192.0.2.10",
      "ttl": 3600
    },
    {
      "type": "AAAA",
      "name": "@",
      "value": "2001:db8::10",
      "ttl": 3600
    },
    {
      "type": "CNAME",
      "name": "www",
      "value": "example.com.",
      "ttl": 3600
    },
    {
      "type": "MX",
      "name": "@",
      "value": "mail.example.com.",
      "priority": 10,
      "ttl": 3600
    },
    {
      "type": "MX",
      "name": "@",
      "value": "backup-mail.example.com.",
      "priority": 20,
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "@",
      "value": "v=spf1 ip4:192.0.2.20 include:_spf.google.com -all",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "default._domainkey",
      "value": "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQA...",
      "ttl": 3600
    },
    {
      "type": "TXT",
      "name": "_dmarc",
      "value": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "value": "ns1.example.net.",
      "ttl": 3600
    },
    {
      "type": "NS",
      "name": "@",
      "value": "ns2.example.net.",
      "ttl": 3600
    },
    {
      "type": "SOA",
      "name": "@",
      "primary_ns": "ns1.example.net.",
      "admin_email": "admin.example.com.",
      "serial": 2025092201,
      "refresh": 7200,
      "retry": 3600,
      "expire": 1209600,
      "minimum": 86400,
      "ttl": 3600
    },
    {
      "type": "PTR",
      "name": "20.2.0.192.in-addr.arpa.",
      "value": "mail.example.com.",
      "ttl": 3600
    },
    {
      "type": "SRV",
      "name": "_sip._tcp",
      "target": "sipserver.example.com.",
      "port": 5060,
      "priority": 10,
      "weight": 60,
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "value": "letsencrypt.org",
      "flags": 0,
      "tag": "issue",
      "ttl": 3600
    },
    {
      "type": "CAA",
      "name": "@",
      "value": "mailto:security@example.com",
      "flags": 0,
      "tag": "iodef",
      "ttl": 3600
    },
    {
      "type": "TLSA",
      "name": "_443._tcp.www",
      "usage": 3,
      "selector": 1,
      "matching_type": 1,
      "value": "d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971",
      "ttl": 3600
    },
    {
      "type": "SSHFP",
      "name": "@",
      "algorithm": 4,
      "digest_type": 2,
      "value": "356a192b7913b04c54574d18c28d46e6395428ab",
      "ttl": 3600
    },
    {
      "type": "HINFO",
      "name": "server1",
      "cpu": "Intel Xeon",
      "os": "Ubuntu 22.04 LTS",
      "ttl": 3600
    },
    {
      "type": "LOC",
      "name": "@",
      "latitude": "55.7558 N",
      "longitude": "37.6176 E",
      "altitude": 150,
      "ttl": 3600
    },
    {
      "type": "RP",
      "name": "@",
      "mbox": "admin.example.com.",
      "txt": "Technical Support",
      "ttl": 3600
    },
    {
      "type": "NAPTR",
      "name": "4.3.2.1.5.5.5.1.e164.arpa.",
      "order": 100,
      "preference": 10,
      "flags": "U",
      "service": "E2U+sip",
      "regexp": "!^.*$!sip:info@example.com!",
      "replacement": ".",
      "ttl": 3600
    },
    {
      "type": "DS",
      "name": "@",
      "key_tag": 54517,
      "algorithm": 13,
      "digest_type": 2,
      "digest": "84C84478D00A57973FC5D3E32F7E2BF539FB697D2660874C6D33A3313872D34F",
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "flags": 257,
      "protocol": 3,
      "algorithm": 13,
      "public_key": "AwEAAbOv...QAB",
      "ttl": 3600
    },
    {
      "type": "DNSKEY",
      "name": "@",
      "flags": 256,
      "protocol": 3,
      "algorithm": 13,
      "public_key": "AwEAAa3d...9QAB",
      "ttl": 3600
    }
  ]
}

Il DNS è un sistema potente e flessibile, e la conoscenza di esso è di importanza critica per chiunque gestisca progetti web, sistemi di posta o infrastrutture di rete. Questa guida copre tutti gli aspetti — dai semplici record A ai meccanismi di sicurezza complessi come DNSSEC e DANE.

Conclusioni chiave:

  • Pianificare i cambiamenti: Ridurre sempre il TTL prima della migrazione.
  • Testare: Utilizzare dig, nslookup e strumenti online per verificare ogni configurazione.
  • Sicurezza prima di tutto: Configurare SPF, DKIM, DMARC per la posta. Abilitare CAA per controllare i certificati. Considerare l’uso di DNSSEC per domini critici.
  • Documentare: Mantenere checklist e salvare backup delle zone.

Questo materiale è progettato per essere il proprio riferimento universale. Salvarlo, e aiuterà a risolvere qualsiasi compito relativo al DNS.

Leave a Reply

Your email address will not be published. Required fields are marked *