Introduzione
Il DNS, ovvero il Domain Name System, è spesso una parte molto difficile da imparare quando si tratta di configurare siti web e server. Capire come funziona il DNS ti aiuterà a diagnosticare problemi nella configurazione dell’accesso ai tuoi siti web e ti consentirà di approfondire la comprensione di ciò che succede dietro le quinte.
In questa guida, discuteremo alcuni concetti fondamentali del DNS che ti aiuteranno a iniziare con la configurazione del DNS. Dopo aver affrontato questa guida, dovresti essere pronto per configurare il tuo nome di dominio con DigitalOcean o configurare il tuo server DNS personale.
Prima di passare alla configurazione dei tuoi server per risolvere il tuo dominio o configurare i nostri domini nel pannello di controllo, esaminiamo alcuni concetti di base su come tutto ciò funziona effettivamente.
Terminologia di Dominio
Dovremmo iniziare definendo i nostri termini. Mentre alcuni di questi argomenti sono familiari da altri contesti, ci sono molti termini utilizzati quando si parla di nomi di dominio e DNS che non vengono utilizzati troppo spesso in altre aree dell’informatica.
Iniziamo con il semplice:
Sistema dei nomi di dominio
Il sistema dei nomi di dominio, più comunemente noto come “DNS”, è il sistema di rete in atto che ci consente di risolvere nomi amichevoli per gli esseri umani in indirizzi IP unici.
Nome di dominio
A domain name is the human-friendly name that we are used to associating with an internet resource. For instance, “google.com” is a domain name. Some people will say that the “google” portion is the domain, but we can generally refer to the combined form as the domain name.
L’URL “google.com” è associato ai server di proprietà di Google Inc. Il sistema dei nomi di dominio ci consente di raggiungere i server di Google quando digitiamo “google.com” nel nostro browser.
Indirizzo IP
Un indirizzo IP è ciò che chiamiamo una posizione accessibile in rete. Ogni indirizzo IP deve essere unico all’interno della sua rete. Quando parliamo di siti web, questa rete è l’intera internet.
IPv4, la forma più comune di indirizzi, sono scritti come quattro serie di numeri, ogni serie contenente fino a tre cifre, con ogni serie separata da un punto. Ad esempio, “111.222.111.222” potrebbe essere un indirizzo IP IPv4 valido. Con DNS, mappiamo un nome a quell’indirizzo in modo che tu non debba ricordare un insieme complicato di numeri per ogni posto che desideri visitare su una rete.
Dominio di primo livello
A top-level domain, or TLD, is the most general part of the domain. The top-level domain is the furthest portion to the right (as separated by a dot). Common top-level domains are “com”, “net”, “org”, “gov”, “edu”, and “io”.
I domini di primo livello si trovano alla cima della gerarchia in termini di nomi di dominio. Alcuni soggetti sono posti in controllo amministrativo sui domini di primo livello da ICANN (Internet Corporation for Assigned Names and Numbers). Questi soggetti possono quindi distribuire i nomi di dominio sotto il TLD, di solito attraverso un registrar di domini.
Host
All’interno di un dominio, il proprietario del dominio può definire host individuali, che si riferiscono a computer o servizi separati accessibili attraverso un dominio. Ad esempio, la maggior parte dei proprietari di domini rende accessibili i loro server web sia attraverso il dominio nudo (example.com) che attraverso la definizione di “host” “www” (www.example.com).
Puoi avere altre definizioni di host sotto il dominio generale. Potresti avere accesso API attraverso un host “api” (api.example.com) o potresti avere accesso ftp definendo un host chiamato “ftp” o “files” (ftp.example.com o files.example.com). I nomi host possono essere arbitrari, purché siano unici per il dominio.
Sottodominio
A subject related to hosts are subdomains.
Il DNS funziona in una gerarchia. I TLD possono avere molti domini al di sotto di loro. Ad esempio, il TLD “com” ha sia “google.com” che “ubuntu.com” al di sotto di esso. Un “sottodominio” si riferisce a qualsiasi dominio che fa parte di un dominio più grande. In questo caso, “ubuntu.com” può essere considerato un sottodominio di “com”. Di solito questo è chiamato solo dominio o la parte “ubuntu” è chiamata SLD, il che significa second level domain.
Allo stesso modo, ogni dominio può controllare “sottodomini” che si trovano al di sotto di esso. Questo è generalmente ciò che intendiamo per sottodomini. Ad esempio, potresti avere un sottodominio per il dipartimento di storia della tua scuola all’indirizzo “www.history.school.edu“. La parte “history” è un sottodominio.
La differenza tra un nome host e un sottodominio è che un host definisce un computer o una risorsa, mentre un sottodominio estende il dominio genitore. È un metodo per suddividere il dominio stesso.
Questo significa che specifica ogni dominio genitore incluso il TLD. Un FQDN corretto termina con un punto, indicando la radice della gerarchia DNS. Un esempio di FQDN è “mail.google.com.“. A volte il software che richiede un FQDN non richiede il punto finale, ma il punto di chiusura è necessario per conformarsi agli standard ICANN.
Name Server
A fully qualified domain name, often called FQDN, is what we call an absolute domain name. Domains in the DNS system can be given relative to one another, and as such, can be somewhat ambiguous. A FQDN is an absolute name that specifies its location in relation to the absolute root of the domain name system.
I server dei nomi possono essere “autoritativi”, il che significa che forniscono risposte alle interrogazioni sui domini sotto il loro controllo. Altrimenti, possono puntare ad altri server o servire copie memorizzate nella cache dei dati di altri server dei nomi.
File di zona
A name server is a computer designated to translate domain names into IP addresses. These servers do most of the work in the DNS system. Since the total number of domain translations is too much for any one server, each server may redirect request to other name servers or delegate responsibility for a subset of subdomains they are responsible for.
I file di zona risiedono nei server dei nomi e generalmente definiscono le risorse disponibili sotto un dominio specifico, o il luogo in cui è possibile ottenere tali informazioni.
Record
A zone file is a simple text file that contains the mappings between domain names and IP addresses. This is how the DNS system finally finds out which IP address should be contacted when a user requests a certain domain name.
All’interno di un file di zona, vengono mantenuti i record. Nella sua forma più semplice, un record è essenzialmente un singolo mapping tra una risorsa e un nome. Questi possono mappare un nome di dominio su un indirizzo IP, definire i server dei nomi per il dominio, definire i server di posta per il dominio, ecc.
Registri
All’interno di un file zona, i record vengono mantenuti. Nella sua forma più semplice, un record è fondamentalmente una singola mappatura tra una risorsa e un nome. Queste possono mappare un nome di dominio a un indirizzo IP, definire i server di nome per il dominio, definire i server di posta per il dominio, ecc.
Come funziona DNS
Ora che hai familiarità con alcuni dei termini coinvolti con DNS, come funziona effettivamente il sistema?
Il sistema è molto semplice in una panoramica di alto livello, ma è molto complesso mentre si guarda ai dettagli. Nel complesso, tuttavia, è un’infrastruttura molto affidabile che è stata essenziale per l’adozione di Internet come lo conosciamo oggi.
Server radice
Come abbiamo detto sopra, DNS è, al suo nucleo, un sistema gerarchico. Alla sommità di questo sistema ci sono quelli che sono noti come “server radice”. Questi server sono controllati da varie organizzazioni e sono delegati l’autorità da ICANN (Internet Corporation for Assigned Names and Numbers).
Attualmente ci sono 13 server radice in funzione. Tuttavia, poiché ogni minuto devono risolvere un numero incredibile di nomi, ognuno di questi server è effettivamente duplicato. La cosa interessante di questa configurazione è che ogni duplicato di un singolo server radice condivide la stessa IP address. Quando vengono fatti richieste per un determinato server radice, la richiesta verrà instradata al duplicato più vicino di quel server radice.
Cosa fanno questi server radice? I server radice gestiscono le richieste di informazioni sui domini di primo livello. Quindi, se arriva una richiesta per qualcosa che un server di nome di livello inferiore non può risolvere, viene effettuata una query al server radice per il dominio.
I server radice non sapranno effettivamente dove è ospitato il dominio. Tuttavia, saranno in grado di indirizzare il richiedente ai server di nome che gestiscono il dominio di primo livello specificamente richiesto.
Quindi, se viene fatta una richiesta per “www.wikipedia.org” al server radice, il server radice non troverà il risultato nei suoi record. Controllerà i suoi file di zona per un elenco che corrisponda a “www.wikipedia.org“. Non ne troverà uno.
Troverà invece un record per il dominio di primo livello “org” e fornirà all’entità richiedente l’indirizzo del server di nome responsabile degli indirizzi “org”.
Server TLD
Il richiedente invia quindi una nuova richiesta all’indirizzo IP (dato dal server radice) che è responsabile del dominio di primo livello della richiesta.
Quindi, per continuare il nostro esempio, invierebbe una richiesta al server dei nomi responsabile di sapere qualcosa sui domini “org” per vedere se sa dove si trova “www.wikipedia.org“.
Ancora una volta, il richiedente cercherà “www.wikipedia.org” nei suoi file di zona. Non troverà questa voce nei suoi file.
Tuttavia, troverà una voce che elenca l’indirizzo IP del server dei nomi responsabile di “wikipedia.org“. Questo ci sta avvicinando molto alla risposta che vogliamo.
Server dei nomi a livello di dominio
A questo punto, il richiedente ha l’indirizzo IP del server dei nomi che è responsabile di conoscere l’indirizzo IP effettivo della risorsa. Invia una nuova richiesta al server dei nomi chiedendo, ancora una volta, se può risolvere “www.wikipedia.org“.
Il server dei nomi controlla i suoi file di zona e scopre che ha un file di zona associato a “wikipedia.org“. All’interno di questo file, c’è una voce per l’host “www”. Questa voce indica l’indirizzo IP dove si trova questo host. Il server dei nomi restituisce la risposta finale al richiedente.
Cos’è un server di nomi risolutivo?
Nel scenario descritto sopra, abbiamo fatto riferimento a un “richiedente”. Cos’è il richiedente in questa situazione?
In quasi tutti i casi, il richiedente sarà quello che chiamiamo un “server di risoluzione del nome”. Un server di risoluzione del nome è uno configurato per fare domande ad altri server. È fondamentalmente un intermediario per l’utente che memorizza i risultati delle query precedenti per migliorare la velocità e conosce gli indirizzi dei server radice per essere in grado di “risolvere” le richieste fatte per cose di cui non sa già.
Fondamentalmente, un utente avrà di solito alcuni server di risoluzione del nome configurati sul loro sistema computerizzato. I server di risoluzione del nome sono generalmente forniti da un ISP o da altre organizzazioni. Ad esempio Google fornisce server DNS di risoluzione che puoi interrogare. Questi possono essere configurati sia automaticamente che manualmente sul tuo computer.
Quando digiti un URL nella barra degli indirizzi del tuo browser, il tuo computer prima controlla se può scoprire localmente dove si trova la risorsa. Controlla il file “hosts” sul computer e alcuni altri luoghi. Quindi invia la richiesta al server di risoluzione del nome e aspetta di ricevere l’indirizzo IP della risorsa.
Il server di risoluzione del nome quindi controlla la sua cache per la risposta. Se non la trova, segue i passaggi descritti sopra.
I server di risoluzione del nome fondamentalmente comprimono il processo di richiesta per l’utente finale. I client devono semplicemente sapere di chiedere ai server di risoluzione del nome dove si trova una risorsa e essere sicuri che indagheranno e restituiranno la risposta finale.
File delle zone
Abbiamo menzionato nel processo sopra l’idea di “file delle zone” e “record”.
I file delle zone sono il modo in cui i server dei nomi memorizzano le informazioni sui domini che conoscono. Ogni dominio che un server dei nomi conosce è memorizzato in un file di zona. La maggior parte delle richieste rivolte al server medio dei nomi non sono qualcosa per cui il server avrà file di zona.
Se è configurato per gestire le query ricorsive, come un server dei nomi risolutivo, troverà la risposta e la restituirà. Altrimenti, indicherà alla parte richiedente dove guardare successivamente.
Più file di zona ha un server dei nomi, più richieste potrà rispondere in modo autorevole.
A zone file describes a DNS “zone”, which is basically a subset of the entire DNS naming system. It generally is used to configure just a single domain. It can contain a number of records which define where resources are for the domain in question.
L’$ORIGIN della zona è un parametro uguale al livello più alto di autorità della zona per impostazione predefinita.
Quindi, se un file di zona viene utilizzato per configurare il dominio “example.com.“, l’$ORIGIN sarebbe impostato su example.com..
Questo è configurato all’inizio del file di zona o può essere definito nel file di configurazione del server DNS che fa riferimento al file di zona. In entrambi i casi, questo parametro descrive per cosa la zona sarà autorevole.
Allo stesso modo, il $TTL configura il “tempo di vita” delle informazioni che fornisce. È essenzialmente un timer. Un server dei nomi in cache può utilizzare i risultati delle query precedenti per rispondere alle domande fino a quando il valore TTL non scade.
Tipi di record
All’interno del file di zona, possiamo avere molti tipi di record diversi. Vedremo qui alcuni dei tipi più comuni (o obbligatori).
Record SOA
Il record Start of Authority, o SOA, è un record obbligatorio in tutti i file di zona. Deve essere il primo record reale in un file (anche se le specifiche $ORIGIN o $TTL possono apparire sopra). È anche uno dei più complessi da capire.
Il record di start of authority appare in questo modo:
domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
1h ; negative TTL
)
Spieghiamo a cosa serve ogni parte:
-
domain.com.: Questo è il radice della zona. Specifica che il file di zona è per il dominiodomain.com.. Spesso, vedrai questo sostituito con@, che è solo un segnaposto che sostituisce il contenuto della variabile$ORIGINche abbiamo appreso sopra. -
IN SOA: La parte “IN” significa internet (e sarà presente in molti record). SOA è l’indicatore che si tratta di un record Start of Authority.
-
ns1.domain.com.: Questo definisce il server di nomi primario per questo dominio. I server di nomi possono essere primari o secondari e, se è configurato il DNS dinamico, un server deve essere “primario”, il quale viene inserito qui. Se non hai configurato il DNS dinamico, allora questo è solo uno dei tuoi server di nomi primari. -
admin.domain.com.: Questo è l’indirizzo email dell’amministratore per questa zona. Il simbolo “@” è sostituito con un punto nell’indirizzo email. Se la parte del nome dell’indirizzo email ha normalmente un punto, questo viene sostituito con un “\” in questa parte ([email protected]diventayour\name.domain.com). -
12083: Questo è il numero seriale per il file di zona. Ogni volta che si modifica un file di zona, è necessario incrementare questo numero affinché il file di zona si propaghi correttamente. I server secondari verificheranno se il numero seriale del server primario per una zona è maggiore di quello che hanno nel proprio sistema. Se lo è, richiederanno il nuovo file di zona, altrimenti continueranno a servire il file originale.
-
3h: Questo è l’intervallo di aggiornamento per la zona. Questo è il tempo che il server secondario deve attendere prima di verificare il server primario per le modifiche al file di zona.
-
30m: Questo è l’intervallo di riprova per questa zona. Se il server secondario non riesce a connettersi al primario quando è scaduto il periodo di aggiornamento, attende questo periodo di tempo e riprova a interrogare il primario.
-
3w: Questo è il periodo di scadenza. Se un server di nomi secondario non è stato in grado di contattare il primario per questo periodo di tempo, non restituisce più risposte come fonte autorevole per questa zona.
-
1h: Questo è il periodo di tempo in cui il server di nomi memorizzerà nella cache un errore di nome se non riesce a trovare il nome richiesto in questo file.
A and AAAA Records
Entrambe queste registrazioni mappano un host a un indirizzo IP. Il record “A” viene utilizzato per mappare un host a un indirizzo IP IPv4, mentre i record “AAAA” vengono utilizzati per mappare un host a un indirizzo IPv6.
Il formato generale di queste registrazioni è il seguente:
host IN A IPv4_address
host IN AAAA IPv6_address
Quindi, dal momento che il nostro record SOA indica un server primario a “ns1.domain.com“, dovremmo mapparlo a un indirizzo IP poiché “ns1.domain.com” è all’interno della zona “domain.com” che questo file sta definendo.
Il record potrebbe assomigliare a qualcosa del genere:
ns1 IN A 111.222.111.222
Si noti che non è necessario fornire il nome completo. Possiamo semplicemente fornire l’host, senza il FQDN e il server DNS completerà il resto con il valore $ORIGIN. Tuttavia, potremmo utilizzare l’intero FQDN se vogliamo essere più precisi:
ns1.domain.com. IN A 111.222.111.222
Nella maggior parte dei casi, qui definiremo il nostro server web come “www”:
www IN A 222.222.222.222
Dovremmo anche indicare a quale dominio base risolve. Possiamo farlo così:
domain.com. IN A 222.222.222.222
Avremmo potuto usare “@” per fare riferimento al dominio base:
@ IN A 222.222.222.222
Abbiamo anche l’opzione di risolvere qualsiasi cosa sotto questo dominio che non sia definita esplicitamente su questo server. Possiamo farlo con il carattere jolly “*”:
* IN A 222.222.222.222
Tutti questi funzionano altrettanto bene con i record AAAA per gli indirizzi IPv6.
Record CNAME
I record CNAME definiscono un alias per il nome canonico del tuo server (quello definito da un record A o AAAA).
Ad esempio, potremmo avere un record A che definisce l’host “server1” e poi usare “www” come alias per questo host:
server1 IN A 111.111.111.111
www IN CNAME server1
Sii consapevole che questi alias comportano delle perdite di prestazioni poiché richiedono una query aggiuntiva al server. La maggior parte delle volte, lo stesso risultato potrebbe essere ottenuto utilizzando record A o AAAA aggiuntivi.
Un caso in cui è consigliato utilizzare un CNAME è per fornire un alias per una risorsa al di fuori della zona corrente.
Record MX
I record MX vengono utilizzati per definire gli scambi di posta utilizzati per il dominio. Questo aiuta i messaggi di posta elettronica ad arrivare correttamente al tuo server di posta.
A differenza di molti altri tipi di record, i record di posta di solito non mappano un host su qualcosa, perché si applicano all’intera zona. Di conseguenza, di solito hanno un aspetto del genere:
IN MX 10 mail.domain.com.
Nota che non c’è un nome host all’inizio.
Nota anche che c’è un numero aggiuntivo. Questo è il numero di preferenza che aiuta i computer a decidere a quale server inviare la posta se sono definiti più server di posta. I numeri più bassi hanno una priorità maggiore.
Il record MX dovrebbe generalmente puntare a un host definito da un record A o AAAA, e non a uno definito da un CNAME.
Quindi, diciamo che abbiamo due server di posta. Ci dovrebbero essere record che hanno un aspetto del genere:
IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
In questo esempio, l’host “mail1” è il server di scambio email preferito.
Potremmo anche scriverlo in questo modo:
IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
Record NS
Questo tipo di record definisce i server di nomi utilizzati per questa zona.
Potresti chiederti: “se il file di zona risiede sul server di nomi, perché ha bisogno di fare riferimento a se stesso?”. Una parte di ciò che rende il DNS così efficace è il suo sistema di caching a più livelli. Una ragione per definire i server di nomi all’interno del file di zona è che il file di zona potrebbe essere effettivamente servito da una copia memorizzata su un altro server di nomi. Ci sono altre ragioni per avere i server di nomi definiti sul server di nomi stesso, ma non entreremo in dettaglio qui.
Come i record MX, anche questi sono parametri globali della zona, quindi non prendono host. In generale, assomigliano a questo:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
Dovresti avere almeno due server di nomi definiti in ogni file di zona per funzionare correttamente in caso di problemi con un server. La maggior parte del software del server DNS considera un file di zona non valido se c’è un solo server di nomi.
Come sempre, includi la mappatura per gli host con record A o AAAA:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233
Ci sono molti altri tipi di record che puoi utilizzare, ma questi sono probabilmente i tipi più comuni con cui ti imbatterai.
Record PTR
I record PTR vengono utilizzati per definire un nome associato a un indirizzo IP. I record PTR sono l’inverso di un record A o AAAA. I record PTR sono unici nel senso che iniziano dalla radice .arpa e vengono delegati ai proprietari degli indirizzi IP. I Registri Internet Regionali (RIRs) gestiscono la delega degli indirizzi IP alle organizzazioni e ai fornitori di servizi. I Registri Internet Regionali includono APNIC, ARIN, RIPE NCC, LACNIC e AFRINIC.
Ecco un esempio di un record PTR per 111.222.333.444:
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
Questo esempio di un record PTR per un indirizzo IPv6 mostra il formato nibble dell’inverso del Server DNS IPv6 di Google 2001:4860:4860::8888.
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.
Lo strumento da riga di comando dig con il flag -x può essere utilizzato per cercare il nome DNS inverso di un indirizzo IP.
Ecco un esempio di un comando dig. Il +short è aggiunto per ridurre l’output al nome DNS inverso.
L’output per il comando dig sopra sarà il nome di dominio nel record PTR per l’indirizzo IP:
google-public-dns-b.google.com.
I server su Internet utilizzano i record PTR per inserire i nomi di dominio nelle voci di registro, prendere decisioni informate sulla gestione dello spam e visualizzare dettagli facili da leggere su altri dispositivi.
I server di posta elettronica più comunemente utilizzati cercheranno il record PTR di un indirizzo IP da cui ricevono email. Se l’indirizzo IP di origine non ha un record PTR associato, le email inviate potrebbero essere trattate come spam e respinte. Non è importante che il FQDN nel PTR corrisponda al nome di dominio dell’email inviata. Quello che è importante è che ci sia un valido record PTR con un record A forward corrispondente e coincidente.
Normalmente i router di rete su Internet vengono forniti con record PTR che corrispondono alla loro posizione fisica. Ad esempio, potresti vedere riferimenti a ‘NYC’ o ‘CHI’ per un router a New York City o Chicago. Questo è utile quando si esegue un traceroute o MTR e si revisiona il percorso che il traffico Internet sta percorrendo.
La maggior parte dei fornitori che offrono server dedicati o servizi VPS daranno ai clienti la possibilità di impostare un record PTR per il loro indirizzo IP. DigitalOcean assegnerà automaticamente il record PTR di qualsiasi Droplet quando il Droplet viene denominato con un nome di dominio. Il nome del Droplet viene assegnato durante la creazione e può essere modificato successivamente utilizzando la pagina delle impostazioni del pannello di controllo del Droplet.
Nota: È importante che il FQDN nel record PTR abbia un record A forward corrispondente e coincidente. Esempio: 111.222.333.444 ha un PTR di server.example.com e server.example.com è un record A che punta a 111.222.333.444.
Record CAA
I record CAA vengono utilizzati per specificare quali Autorità di Certificazione (CA) sono autorizzate a rilasciare certificati SSL/TLS per il tuo dominio. A partire dall’8 settembre 2017, tutte le CA sono tenute a controllare questi record prima di rilasciare un certificato. Se non è presente alcun record, qualsiasi CA può rilasciare un certificato. In caso contrario, solo le CA specificate possono emettere certificati. I record CAA possono essere applicati a singoli host o a interi domini.
Ecco un esempio di record CAA:
example.com. IN CAA 0 issue "letsencrypt.org"
L’host, IN, e il tipo di record (CAA) sono campi DNS comuni. Le informazioni specifiche del CAA sopra sono la parte 0 issue "letsencrypt.org". È composto da tre parti: flag (0), tag (issue), e valori ("letsencrypt.org").
- Flags sono un intero che indica come una CA dovrebbe gestire i tag che non comprende. Se il flag è
0, il record verrà ignorato. Se è1, la CA deve rifiutarsi di rilasciare il certificato. - Tags sono stringhe che indicano lo scopo di un record CAA. Attualmente possono essere
issueper autorizzare una CA a creare certificati per un hostname specifico,issuewildper autorizzare certificati wildcard, oiodefper definire un URL dove le CA possono segnalare violazioni di policy. - I Valori sono una stringa associata al tag del record. Per
issueeissuewildquesto sarà tipicamente il dominio del CA a cui stai concedendo il permesso. Periodefpotrebbe essere l’URL di un modulo di contatto, o un linkmailto:per il feedback via email.
Puoi utilizzare dig per recuperare i record CAA utilizzando le seguenti opzioni:
Per informazioni più dettagliate sui record CAA, puoi leggere RFC 6844, o il nostro tutorial Come Creare e Gestire Record CAA Utilizzando DigitalOcean DNS
Conclusione
Dovresti ora avere una buona comprensione di come funziona il DNS. Sebbene l’idea generale sia relativamente facile da comprendere una volta che ti sei familiarizzato con la strategia, questo è comunque qualcosa che può essere difficile da mettere in pratica per gli amministratori inesperti.
Per una panoramica, consulta Come Configurare Domini nel Pannello di Controllo di DigitalOcean.