Uma Introdução à Terminologia, Componentes e Conceitos de 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. Compreender como o DNS funciona ajudará você a diagnosticar problemas ao configurar o acesso aos seus sites e permitirá que você amplie sua compreensão do que está acontecendo nos bastidores.

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

Antes de avançarmos para configurar 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ínioPrecisamos 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 rede 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 na rede. Cada endereço IP deve ser único dentro de sua rede. Ao falarmos 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, mapeamos um nome para esse endereço para que você não precise lembrar de 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 Assigned Names and Numbers). 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 puro (example.com) e também através da definição de “host” “www” (www.example.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 você poderia ter acesso via FTP, definindo um host chamado “ftp” ou “files” (ftp.example.com ou files.example.com). Os nomes dos hosts 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” tem 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. Neste 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. Isso geralmente é 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 ele 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 requer o ponto final, mas o ponto de fechamento é necessário para conformidade com os padrões da 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.

Servidores de nomes podem ser “autoritários”, o que significa que eles fornecem respostas a consultas sobre domínios sob seu controle. Caso contrário, eles 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 em servidores de nomes e geralmente definem os recursos disponíveis sob 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 único mapeamento entre um recurso e um nome. Estes 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. Em 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ê analisa 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 têm autoridade delegada pela ICANN (Internet Corporation for Assigned Names and Numbers).

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 cada um dos espelhos para um único servidor raiz compartilha o mesmo endereço IP. Quando são feitas solicitações para um determinado servidor raiz, a solicitação será encaminhada para o espelho mais próximo desse servidor raiz.

O que fazem esses servidores raiz? Servidores raiz lidam com solicitações de informações sobre domínios de nível superior. Então, se uma solicitação 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 está hospedado. Eles, 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 uma solicitação para “www.wikipedia.org” for feita ao servidor raiz, o servidor raiz não encontrará o resultado em seus registros. Ele verificará seus arquivos de zona para uma listagem 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 uma nova solicitação para o endereço IP (fornecido pelo servidor raiz) que é responsável pelo domínio de nível superior da solicitação.

Então, continuando com nosso exemplo, ele enviaria uma solicitação ao servidor de nomes responsável por saber sobre os domínios “org” 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 que lista o endereço IP do servidor de nomes responsável por “wikipedia.org”. Estamos chegando muito mais perto 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 percebe 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 Resolvente?

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

Em quase todos os 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 em cache 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 não sabe ainda.

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 geralmente são 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 alguns outros locais. Em seguida, envia a solicitação para o 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 para onde perguntar aos servidores de nomes de resolução onde um recurso está localizado e ter a 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. Todo domínio que um servidor de nomes conhece é armazenado em um arquivo de zona. A maioria das solicitações feitas aos servidores de nomes comuns não são para domínios que o servidor tenha arquivos de zona.

Se estiver configurado para lidar com consultas recursivas, como um servidor de nomes de resolução, ele encontrará a resposta e a retornará. Caso contrário, ele informará à parte solicitante 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 nível mais alto 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á autoritativa.

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

Tipos de Registros

Dentro do arquivo de zona, podemos ter muitos tipos diferentes de registros. Vamos examinar alguns dos mais comuns (ou tipos obrigatórios) aqui.

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:

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

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

• ns1.domain.com.: Isso define o servidor de nomes primário para este domínio. Os servidores de nomes 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 nomes primários.

• 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] se torna your\name.domain.com).

• 12083: Este é o número de série do arquivo de zona. Sempre que você editar um arquivo de zona, deve incrementar este número para que o arquivo de zona seja propagado corretamente. Os servidores secundários verificarão se o número de série do servidor primário para uma zona é maior do que aquele que eles têm em seu sistema. Se for, solicitará o novo arquivo de zona; caso contrário, continuará servindo o arquivo original.

• 3h: Este é o intervalo de atualização para a zona. Este é o tempo que o secundário aguardará antes de verificar 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 conseguir conectar-se ao primário quando o período de atualização expirar, ele aguardará esse tempo e tentará novamente consultar o 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 esse período de 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 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, dado que nosso registro SOA chamava um servidor primário em “ns1.domain.com“, teríamos que mapear isso para um endereço IP, já que “ns1.domain.com” está dentro da zona “domain.com” que este arquivo está definindo.

O registro poderia se parecer com algo assim:

ns1     IN  A       111.222.111.222

Observe que não precisamos fornecer o nome completo. Podemos apenas 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 é onde você definirá seu servidor web como “www”:

www     IN  A       222.222.222.222

Também devemos informar para onde o domínio base resolve. 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

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

*       IN  A       222.222.222.222

Todos esses funcionam tão bem com registros AAAA para endereços IPv6.

Registros CNAME

Registros CNAME definem um alias para o nome canônico do 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 “www” como um alias para este host:

server1     IN  A       111.111.111.111
www         IN  CNAME   server1

Esteja ciente de que esses aliases vêm com algumas perdas de desempenho porque requerem 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 é fornecer um alias para um recurso fora da zona atual.

Registros MX

Os registros MX são usados para definir as trocas de correio usadas para o domínio. Isso ajuda as mensagens de e-mail a chegarem 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, porque se aplicam à zona inteira. Como tal, eles geralmente se parecem com isto:

        IN  MX  10   mail.domain.com.

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

Também observe que há um número extra lá. Este é o número de preferência que ajuda os computadores a decidirem para qual servidor enviar o correio se houver múltiplos servidores de correio definidos. Números menores têm uma prioridade maior.

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

Então, digamos que tenhamos dois servidores de correio. Teria que haver registros que se parecem 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.

Também poderíamos escrever isso da seguinte forma:

        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 usados para esta zona.

Você pode estar se perguntando: “se o arquivo de zona reside no servidor de nomes, por que ele precisa se referenciar a si mesmo?”. Parte do que torna o DNS tão bem-sucedido são seus múltiplos níveis de cache. Uma razão para definir servidores de nomes dentro do arquivo de zona é que o arquivo de zona pode estar sendo servido na verdade 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 entraremos nisso aqui.

Assim como os registros MX, estes são parâmetros de toda a zona, então eles não recebem 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 único 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 que você encontrará.

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 pois começam na raiz .arpa e são delegados aos proprietários dos endereços IP. Os Registros Regionais de Internet (RIRs) gerenciam a delegação de endereços IP para organizações e provedores de serviços. Os Registros Regionais de 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 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 opção -x pode ser usada para buscar o nome DNS reverso de um endereço IP.

Aqui está um exemplo de um comando dig. O +short é acrescentado 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 colocar nomes de domínio em entradas de log, tomar decisões informadas sobre tratamento de spam e exibir detalhes fáceis de ler sobre outros dispositivos.

Os servidores de email mais comumente utilizados irão procurar o registro PTR de um endereço IP do qual recebem email. Se o endereço IP de origem não tiver um registro PTR associado a ele, os emails enviados podem ser tratados como spam e rejeitados. Não é importante que o FQDN no PTR corresponda ao nome de domínio do email 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ão aos clientes a capacidade de definir um registro PTR para seu endereço IP. A 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 a domínios inteiros.

Um exemplo de registro CAA segue abaixo:

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

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

• Flags são um número inteiro que indica como uma CA deve lidar com tags que ela não entende. Se a flag for 0, o registro será ignorado. Se for 1, a CA deve recusar a emissão do 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 com curingas ou iodef para definir um URL onde as CAs podem relatar violações de política.
• Os valores são uma string associada à tag do registro. Para issue e issuewild, isso normalmente 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 compreensão bastante boa de como o DNS funciona. Embora a ideia geral seja relativamente fácil de entender uma vez que você esteja 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.