Uma Introdução à Terminologia, Componentes e Conceitos do DNS

Introdução

O DNS, ou Sistema de Nomes de Domínio, é frequentemente uma parte muito difícil de aprender ao configurar sites e servidores. Entender como o DNS funciona ajudará você a diagnosticar problemas ao configurar o acesso aos seus sites e permitirá que você amplie seu entendimento sobre o que está acontecendo nos bastidores.

Neste guia, discutiremos alguns conceitos fundamentais do DNS que ajudarão você a começar com o pé direito na configuração do DNS. Depois de lidar com este guia, você deverá estar pronto para configurar seu nome de domínio com a DigitalOcean ou configurar seu próprio servidor DNS.

Antes de entrarmos na configuração de seus próprios servidores para resolver seu domínio ou configurar nossos domínios no painel de controle, vamos revisar alguns conceitos básicos sobre como tudo isso realmente funciona.

Terminologia de DomínioDevemos começar definindo nossos termos. Embora alguns desses tópicos sejam familiares em outros contextos, existem muitos termos usados ao falar sobre nomes de domínio e DNS que não são usados com muita frequência em outras áreas da computação.

Devemos começar definindo nossos termos. Embora alguns desses tópicos sejam familiares de outros contextos, existem muitos termos usados ao falar sobre nomes de domínio e DNS que não são usados com muita frequência em outras áreas da computação.

Vamos começar fácil:

Sistema de Nomes de Domínio

O sistema de nomes de domínio, mais comumente conhecido como “DNS”, é o sistema de redes em vigor que nos permite resolver nomes amigáveis ao ser humano em endereços IP únicos.

Nome de Domínio

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.

A URL “google.com” está associada aos servidores pertencentes à Google Inc. O sistema de nomes de domínio nos permite alcançar os servidores da Google quando digitamos “google.com” em nossos navegadores.

Endereço IP

Um endereço IP é o que chamamos de localização endereçável em rede. Cada endereço IP deve ser único dentro de sua rede. Quando estamos falando de sites, essa rede é toda a internet.

IPv4, a forma mais comum de endereços, é escrita como quatro conjuntos de números, cada conjunto com até três dígitos, separados por um ponto. Por exemplo, “111.222.111.222” poderia ser um endereço IP válido IPv4. Com o DNS, nós mapeamos um nome para esse endereço para que você não precise lembrar um conjunto complicado de números para cada lugar que deseja visitar em uma rede.

Domínio de Nível Superior

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”.

Os domínios de nível superior estão no topo da hierarquia em termos de nomes de domínio. Certas partes recebem o controle de gerenciamento sobre os domínios de nível superior pela ICANN (Corporação da Internet para Atribuição de Nomes e Números). Essas partes podem então distribuir nomes de domínio sob o TLD, geralmente por meio de um registrador de domínios.

Hosts

Dentro de um domínio, o proprietário do domínio pode definir hosts individuais, que se referem a computadores ou serviços separados acessíveis por meio de um domínio. Por exemplo, a maioria dos proprietários de domínios torna seus servidores web acessíveis através do domínio simples (exemplo.com) e também através da definição de “host” “www” (www.exemplo.com).

Você pode ter outras definições de host sob o domínio geral. Você poderia ter acesso à API por meio de um host “api” (api.example.com) ou poderia ter acesso ftp definindo um host chamado “ftp” ou “files” (ftp.example.com ou files.example.com). Os nomes de host podem ser arbitrários, desde que sejam únicos para o domínio.

SubDomínio

A subject related to hosts are subdomains.

O DNS funciona em uma hierarquia. Os TLDs podem ter muitos domínios sob eles. Por exemplo, o TLD “com” possui tanto “google.com” quanto “ubuntu.com” sob ele. Um “subdomínio” refere-se a qualquer domínio que faça parte de um domínio maior. Nesse caso, “ubuntu.com” pode ser considerado um subdomínio de “com”. Isso é geralmente chamado de domínio ou a parte “ubuntu” é chamada de SLD, o que significa segundo nível de domínio.

Da mesma forma, cada domínio pode controlar “subdomínios” que estão localizados sob ele. Geralmente, isso é o que entendemos por subdomínios. Por exemplo, você poderia ter um subdomínio para o departamento de história da sua escola em “www.history.school.edu“. A parte “history” é um subdomínio.

A diferença entre um nome de host e um subdomínio é que um host define um computador ou recurso, enquanto um subdomínio estende o domínio pai. É um método de subdividir o próprio domínio.

Isso significa que especifica cada domínio pai, incluindo o TLD. Um FQDN adequado termina com um ponto, indicando a raiz da hierarquia do DNS. Um exemplo de um FQDN é “mail.google.com.“. Às vezes, o software que solicita um FQDN não exige o ponto final, mas o ponto final é necessário para estar de acordo com os padrões do ICANN.

Servidor de Nomes

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.

Os servidores de nomes podem ser “autoritativos”, o que significa que eles fornecem respostas a consultas sobre domínios sob seu controle. Caso contrário, podem apontar para outros servidores ou servir cópias em cache dos dados de outros servidores de nomes.

Arquivo de 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.

Os arquivos de zona residem nos servidores de nomes e geralmente definem os recursos disponíveis em um domínio específico ou o local onde se pode ir para obter essas informações.

Registros

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.

Dentro de um arquivo de zona, são mantidos registros. Em sua forma mais simples, um registro é basicamente um mapeamento único entre um recurso e um nome. Eles podem mapear um nome de domínio para um endereço IP, definir os servidores de nomes para o domínio, definir os servidores de email para o domínio, etc.

Registros

Dentro de um arquivo de zona, são mantidos registros. Na sua forma mais simples, um registro é basicamente uma única correspondência entre um recurso e um nome. Esses podem mapear um nome de domínio para um endereço IP, definir os servidores de nomes para o domínio, definir os servidores de correio para o domínio, etc.

Como o DNS Funciona

Agora que você está familiarizado com alguns dos termos envolvidos com o DNS, como o sistema realmente funciona?

O sistema é muito simples em uma visão geral de alto nível, mas é muito complexo à medida que você olha os detalhes. No entanto, é uma infraestrutura muito confiável que tem sido essencial para a adoção da internet como a conhecemos hoje.

Servidores Raiz

Como dissemos acima, o DNS é, em seu núcleo, um sistema hierárquico. No topo desse sistema estão o que são conhecidos como “servidores raiz”. Esses servidores são controlados por várias organizações e são delegados autoridade pela ICANN (Corporação da Internet para a Assinatura de Números e Nomes).

Existem atualmente 13 servidores raiz em operação. No entanto, como há um número incrível de nomes a serem resolvidos a cada minuto, cada um desses servidores é, na verdade, espelhado. O interessante sobre essa configuração é que todos os espelhos de um único servidor raiz compartilham o mesmo endereço IP. Quando pedidos são feitos para um determinado servidor raiz, o pedido será encaminhado para o espelho mais próximo desse servidor raiz.

O que fazem esses servidores raiz? Os servidores raiz lidam com pedidos de informações sobre domínios de nível superior. Então, se um pedido chega para algo que um servidor de nome de nível inferior não pode resolver, uma consulta é feita ao servidor raiz para o domínio.

Os servidores raiz não saberão realmente onde o domínio é hospedado. No entanto, serão capazes de direcionar o solicitante aos servidores de nomes que lidam com o domínio de nível superior especificamente solicitado.

Então, se um pedido para “www.wikipedia.org” é feito ao servidor raiz, o servidor raiz não encontrará o resultado em seus registros. Ele verificará seus arquivos de zona para um registro que corresponda a “www.wikipedia.org”. Não encontrará um.

Em vez disso, encontrará um registro para o TLD “org” e fornecerá ao ente solicitante o endereço do servidor de nomes responsável por endereços “org”.

Servidores TLD

O solicitante, então, envia um novo pedido para o endereço IP (fornecido pelo servidor raiz) que é responsável pelo domínio de nível superior do pedido.

Então, continuando nosso exemplo, ele enviaria uma solicitação ao servidor de nomes responsável por saber sobre “org” domínios para ver se ele sabe onde “www.wikipedia.org” está localizado.

Mais uma vez, o solicitante procurará “www.wikipedia.org” em seus arquivos de zona. Não encontrará este registro em seus arquivos.

No entanto, encontrará um registro listando o endereço IP do servidor de nomes responsável por “wikipedia.org“. Estamos nos aproximando muito mais da resposta que queremos.

Servidores de Nomes de Nível de Domínio

Neste ponto, o solicitante tem o endereço IP do servidor de nomes que é responsável por saber o endereço IP real do recurso. Ele envia uma nova solicitação ao servidor de nomes perguntando, mais uma vez, se pode resolver “www.wikipedia.org“.

O servidor de nomes verifica seus arquivos de zona e descobre que tem um arquivo de zona associado a “wikipedia.org“. Dentro deste arquivo, há um registro para o host “www”. Este registro informa o endereço IP onde este host está localizado. O servidor de nomes retorna a resposta final ao solicitante.

O que é um Servidor de Nomes Resolvedor?

No cenário acima, nos referimos a um “solicitante”. O que é o solicitante nesta situação?

Na maioria dos casos, o solicitante será o que chamamos de “servidor de nomes de resolução”. Um servidor de nomes de resolução é aquele configurado para fazer perguntas a outros servidores. Basicamente, é um intermediário para um usuário que armazena resultados de consultas anteriores para melhorar a velocidade e conhece os endereços dos servidores raiz para poder “resolver” solicitações feitas para coisas que ele ainda não sabe.

Basicamente, um usuário geralmente terá alguns servidores de nomes de resolução configurados em seu sistema de computador. Os servidores de nomes de resolução são geralmente fornecidos por um ISP ou outras organizações. Por exemplo, a Google fornece servidores DNS de resolução que você pode consultar. Estes podem ser configurados em seu computador automaticamente ou manualmente.

Quando você digita um URL na barra de endereço do seu navegador, o computador primeiro verifica se pode descobrir localmente onde o recurso está localizado. Ele verifica o arquivo “hosts” no computador e algumas outras localizações. Em seguida, envia a solicitação ao servidor de nomes de resolução e aguarda para receber o endereço IP do recurso.

O servidor de nomes de resolução, então, verifica sua cache para a resposta. Se não a encontrar, segue os passos descritos acima.

Os servidores de nomes de resolução basicamente comprimem o processo de solicitação para o usuário final. Os clientes simplesmente precisam saber perguntar aos servidores de nomes de resolução onde um recurso está localizado e ter certeza de que eles investigarão e retornarão a resposta final.

Arquivos de Zona

Mencionamos no processo acima a ideia de “arquivos de zona” e “registros”.

Arquivos de zona são a maneira como os servidores de nomes armazenam informações sobre os domínios que conhecem. Cada domínio que um servidor de nomes conhece é armazenado em um arquivo de zona. A maioria das solicitações feitas para um servidor de nomes médio não é algo para o qual o servidor terá arquivos de zona.

Se estiver configurado para lidar com consultas recursivas, como um servidor de nomes resolutivo, ele descobrirá a resposta e a retornará. Caso contrário, ele informará à parte solicitante para onde procurar em seguida.

Quanto mais arquivos de zona um servidor de nomes tiver, mais solicitações ele poderá responder de forma autoritativa.

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.

O $ORIGIN da zona é um parâmetro igual à autoridade de mais alto nível da zona por padrão.

Portanto, se um arquivo de zona for usado para configurar o domínio “example.com.“, o $ORIGIN será definido como example.com..

Isso é configurado no topo do arquivo de zona ou pode ser definido no arquivo de configuração do servidor DNS que referencia o arquivo de zona. De qualquer forma, esse parâmetro descreve para o que a zona será autoritária.

Da mesma forma, o $TTL configura o “tempo de vida” das informações que ele fornece. Basicamente, é um temporizador. Um servidor de nomes em cache pode usar resultados previamente consultados para responder perguntas até que o valor TTL expire.

Tipos de Registro

Dentro do arquivo de zona, podemos ter muitos tipos diferentes de registros. Aqui vamos abordar alguns dos tipos mais comuns (ou obrigatórios).

Registros SOA

O Registro de Início de Autoridade, ou SOA, é um registro obrigatório em todos os arquivos de zona. Deve ser o primeiro registro real em um arquivo (embora as especificações $ORIGIN ou $TTL possam aparecer acima). Também é um dos mais complexos de entender.

O registro de início de autoridade se parece com isso:

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
                          )

Vamos explicar para que serve cada parte:

• dominio.com.: Este é o domínio raiz da zona. Isso especifica que o arquivo de zona é para o domínio dominio.com.. Frequentemente, você verá isso substituído por @, que é apenas um espaço reservado que substitui o conteúdo da variável $ORIGIN que aprendemos acima.

• EM SOA: A parte “EM” significa internet (e estará presente em muitos registros). SOA é o indicador de que este é um registro de Início de Autoridade.

• ns1.domain.com.: Isso define o servidor de nome primário para este domínio. Os servidores de nome podem ser primários ou secundários e, se o DNS dinâmico estiver configurado, um servidor precisa ser um “primário”, que é especificado aqui. Se você não configurou o DNS dinâmico, então este é apenas um dos seus servidores de nome primário.

• admin.domain.com.: Este é o endereço de e-mail do administrador para esta zona. O “@” é substituído por um ponto no endereço de e-mail. Se a parte do nome do endereço de e-mail normalmente tiver um ponto, isso é substituído por um “” nesta parte ([email protected] torna-se seu\nome.domain.com).

• 12083: Este é o número de série para o arquivo de zona. Sempre que você editar um arquivo de zona, você deve incrementar este número para que o arquivo de zona se propague corretamente. Servidores secundários verificarão se o número de série do servidor primário para uma zona é maior do que o que eles têm em seu sistema. Se for, solicita o novo arquivo de zona, se não, continua servindo o arquivo original.

• 3h: Este é o intervalo de atualização para a zona. Este é o tempo que o secundário aguardará antes de consultar o primário para alterações no arquivo de zona.

• 30m: Este é o intervalo de tentativa para esta zona. Se o secundário não puder se conectar ao primário quando o período de atualização estiver completo, ele aguardará este tempo e tentará novamente se conectar ao primário.

• 3w: Este é o período de expiração. Se um servidor de nomes secundário não conseguir contatar o primário por este tempo, ele não retornará mais respostas como uma fonte autoritativa para esta zona.

• 1h: Este é o tempo que o servidor de nomes irá armazenar em cache um erro de nome se não puder encontrar o nome solicitado neste arquivo.

A and AAAA Records

Ambos esses registros mapeiam um host para um endereço IP. O registro “A” é usado para mapear um host para um endereço IP IPv4, enquanto os registros “AAAA” são usados para mapear um host para um endereço IPv6.

O formato geral desses registros é este:

host     IN      A       IPv4_address
host     IN      AAAA    IPv6_address

Então, como nosso registro SOA mencionou um servidor primário em “ns1.domain.com”, teríamos que mapear isso para um endereço de IP, já que “ns1.domain.com” está dentro da zona “domain.com” que este arquivo está definindo.

O registro poderia ser algo assim:

ns1     IN  A       111.222.111.222

Observe que não precisamos fornecer o nome completo. Podemos simplesmente fornecer o host, sem o FQDN, e o servidor DNS preencherá o restante com o valor $ORIGIN. No entanto, poderíamos igualmente usar o FQDN completo se quisermos ser semânticos:

ns1.domain.com.     IN  A       111.222.111.222

Na maioria dos casos, é aqui que você definirá seu servidor web como “www”:

www     IN  A       222.222.222.222

Também devemos indicar para onde o domínio base deve ser resolvido. Podemos fazer isso assim:

domain.com.     IN  A       222.222.222.222

Poderíamos ter usado o “@” para se referir ao domínio base também:

@       IN  A       222.222.222.222

Também temos a opção de resolver qualquer coisa sob este domínio que não esteja explicitamente definida para este servidor também. Podemos fazer isso com o coringa “*”:

*       IN  A       222.222.222.222

Todas essas opções funcionam igualmente bem com registros AAAA para endereços IPv6.

Registros CNAME

Os registros CNAME definem um alias para um nome canônico para seu servidor (um definido por um registro A ou AAAA).

Por exemplo, poderíamos ter um registro de nome A definindo o host “server1” e depois usar o “www” como um alias para este host:

server1     IN  A       111.111.111.111
www         IN  CNAME   server1

Tenha em mente que esses apelidos vêm com algumas perdas de desempenho, pois exigem uma consulta adicional ao servidor. Na maioria das vezes, o mesmo resultado poderia ser alcançado usando registros A ou AAAA adicionais.

Um caso em que um CNAME é recomendado é para fornecer um apelido para um recurso fora da zona atual.

Registros MX

Os registros MX são usados para definir as trocas de correio que são usadas para o domínio. Isso ajuda a garantir que as mensagens de e-mail cheguem corretamente ao seu servidor de correio.

Ao contrário de muitos outros tipos de registros, os registros de correio geralmente não mapeiam um host para algo, pois se aplicam à zona inteira. Dessa forma, eles geralmente se parecem com isso:

        IN  MX  10   mail.domain.com.

Observe que não há um nome de host no início.

Além disso, note que há um número extra ali. Esse é o número de preferência que ajuda os computadores a decidir para qual servidor enviar o e-mail, caso sejam definidos vários servidores de correio. Números menores têm prioridade maior.

O registro MX deve geralmente apontar para um host definido por um registro A ou AAAA, e não por um CNAME.

Então, digamos que temos dois servidores de correio. Teríamos que ter registros que se parecessem com algo assim:

        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

Neste exemplo, o host “mail1” é o servidor de troca de e-mail preferido.

Poderíamos também escrever isso assim:

        IN  MX  10  mail1
        IN  MX  50  mail2
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

Registros NS

Este tipo de registro define os servidores de nomes que são utilizados para esta zona.

Você pode estar se perguntando: “se o arquivo de zona reside no servidor de nomes, por que ele precisa fazer referência a si mesmo?”. Parte do que torna o DNS tão bem-sucedido são seus múltiplos níveis de armazenamento em cache. Uma razão para definir servidores de nomes dentro do arquivo de zona é que o arquivo de zona pode estar sendo servido a partir de uma cópia em cache em outro servidor de nomes. Existem outras razões para precisar dos servidores de nomes definidos no próprio servidor de nomes, mas não vamos entrar nisso aqui.

Assim como os registros MX, estes são parâmetros de toda a zona, então eles não aceitam hosts. Em geral, eles se parecem com isso:

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.

Você deve ter pelo menos dois servidores de nomes definidos em cada arquivo de zona para operar corretamente se houver um problema com um servidor. A maioria do software de servidor DNS considera um arquivo de zona inválido se houver apenas um servidor de nomes.

Como sempre, inclua o mapeamento para os hosts com registros A ou 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

Há vários outros tipos de registros que você pode usar, mas estes são provavelmente os tipos mais comuns com os quais você irá se deparar.

Registros PTR

Os registros PTR são usados para definir um nome associado a um endereço IP. Os registros PTR são o inverso de um registro A ou AAAA. Os registros PTR são únicos porque começam na raiz .arpa e são delegados aos proprietários dos endereços IP. Os Registros Regionais da Internet (RIRs) gerenciam a delegação de endereços IP para organizações e provedores de serviços. Os Registros Regionais da Internet incluem APNIC, ARIN, RIPE NCC, LACNIC e AFRINIC.

Aqui está um exemplo de um registro PTR para 111.222.333.444:

444.333.222.111.in-addr.arpa.	33692	IN	PTR	host.example.com.

Este exemplo de um registro PTR para um endereço IPv6 mostra o formato de nibble do reverso do Servidor DNS IPv6 do 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.

A ferramenta de linha de comando dig com a flag -x pode ser usada para procurar o nome DNS reverso de um endereço IP.

Aqui está um exemplo de um comando dig. O +short é adicionado para reduzir a saída para o nome DNS reverso.

dig -x 8.8.4.4 +short

A saída para o comando dig acima será o nome de domínio no registro PTR para o endereço IP:

google-public-dns-b.google.com.

Servidores na Internet usam registros PTR para inserir nomes de domínio em entradas de log, tomar decisões informadas sobre o tratamento de spam e exibir detalhes fáceis de ler sobre outros dispositivos.

Os servidores de e-mail mais comumente usados irão procurar o registro PTR de um endereço IP do qual recebem e-mails. Se o endereço IP de origem não tiver um registro PTR associado a ele, os e-mails enviados podem ser tratados como spam e rejeitados. Não é importante que o FQDN no PTR corresponda ao nome de domínio do e-mail sendo enviado. O que é importante é que haja um registro PTR válido com um registro A correspondente e correspondente.

Normalmente, os roteadores de rede na Internet recebem registros PTR que correspondem à sua localização física. Por exemplo, você pode ver referências a ‘NYC’ ou ‘CHI’ para um roteador em Nova York ou Chicago. Isso é útil ao executar um traceroute ou MTR e revisar o caminho que o tráfego da Internet está seguindo.

A maioria dos provedores que oferecem servidores dedicados ou serviços VPS dará aos clientes a capacidade de definir um registro PTR para seu endereço IP. O DigitalOcean atribuirá automaticamente o registro PTR de qualquer Droplet quando o Droplet for nomeado com um nome de domínio. O nome do Droplet é atribuído durante a criação e pode ser editado posteriormente usando a página de configurações do painel de controle do Droplet.

Registros CAA

Os registros CAA são usados para especificar quais Autoridades de Certificação (CAs) estão autorizadas a emitir certificados SSL/TLS para seu domínio. A partir de 8 de setembro de 2017, todas as CAs são obrigadas a verificar esses registros antes de emitir um certificado. Se nenhum registro estiver presente, qualquer CA pode emitir um certificado. Caso contrário, apenas as CAs especificadas podem emitir certificados. Os registros CAA podem ser aplicados a hosts individuais ou domínios inteiros.

Segue um exemplo de registro CAA:

example.com.	IN	CAA	0 issue "letsencrypt.org"

O host, IN, e o tipo de registro (CAA) são campos DNS comuns. A informação específica do CAA acima é a parte 0 issue "letsencrypt.org". Ela é composta por três partes: flags (0), tags (issue) e valores ("letsencrypt.org").

• Flags são inteiros que indicam como uma CA deve lidar com tags que não compreende. Se a flag for 0, o registro será ignorado. Se for 1, a CA deve recusar-se a emitir o certificado.
• Tags são strings que denotam o propósito de um registro CAA. Atualmente, elas podem ser issue para autorizar uma CA a criar certificados para um nome de host específico, issuewild para autorizar certificados curinga ou iodef para definir uma URL onde as CAs podem relatar violações de política.
• Os Valores são uma sequência associada à tag do registro. Para issue e issuewild, isso geralmente será o domínio da CA à qual você está concedendo permissão. Para iodef, isso pode ser o URL de um formulário de contato ou um link mailto: para feedback por e-mail.

Você pode usar o dig para buscar registros CAA usando as seguintes opções:

dig example.com type257

Para obter informações mais detalhadas sobre registros CAA, você pode ler o RFC 6844, ou nosso tutorial Como Criar e Gerenciar Registros CAA Usando o DNS da DigitalOcean

Conclusão

Agora você deve ter uma boa compreensão de como o DNS funciona. Embora a ideia geral seja relativamente fácil de entender quando você está familiarizado com a estratégia, isso ainda pode ser difícil para administradores inexperientes colocarem em prática.

Para uma visão geral, confira Como Configurar Domínios no Painel de Controle da DigitalOcean.