Introducción
El DNS, o Sistema de Nombres de Dominio, suele ser una parte muy difícil de aprender al configurar sitios web y servidores. Comprender cómo funciona el DNS te ayudará a diagnosticar problemas al configurar el acceso a tus sitios web y te permitirá ampliar tu comprensión de lo que está sucediendo detrás de escena.
En esta guía, discutiremos algunos conceptos fundamentales de DNS que te ayudarán a empezar con tu configuración de DNS. Después de abordar esta guía, deberías estar listo para configurar tu nombre de dominio con DigitalOcean o configurar tu propio servidor DNS.
Antes de adentrarnos en la configuración de tus propios servidores para resolver tu dominio o configurar nuestros dominios en el panel de control, repasemos algunos conceptos básicos sobre cómo funciona todo esto en realidad.
Terminología de Dominios
Deberíamos comenzar definiendo nuestros términos. Mientras que algunos de estos temas son familiares en otros contextos, hay muchos términos utilizados al hablar de nombres de dominio y DNS que no se usan demasiado en otras áreas de la informática.
Empecemos por lo básico:
Sistema de Nombres de Dominio
El sistema de nombres de dominio, más comúnmente conocido como “DNS”, es el sistema de redes en su lugar que nos permite resolver nombres amigables para el ser humano a direcciones IP únicas.
Nombre de 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.
La URL “google.com” está asociada con los servidores propiedad de Google Inc. El sistema de nombres de dominio nos permite llegar a los servidores de Google cuando escribimos “google.com” en nuestros navegadores.
Dirección IP
Una dirección IP es lo que llamamos una ubicación direccionable en la red. Cada dirección IP debe ser única dentro de su red. Cuando hablamos de sitios web, esta red es todo Internet.
IPv4, la forma más común de direcciones, se escribe como cuatro conjuntos de números, cada conjunto con hasta tres dígitos, separados por un punto. Por ejemplo, “111.222.111.222” podría ser una dirección IP IPv4 válida. Con DNS, mapiamos un nombre a esa dirección para que no tenga que recordar un conjunto complicado de números para cada lugar que desee visitar en una red.
Dominio de nivel 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”.
Los dominios de nivel superior están en la cima de la jerarquía en términos de nombres de dominio. Ciertas partes reciben el control de gestión sobre los dominios de nivel superior por parte de ICANN (Internet Corporation for Assigned Names and Numbers). Estas partes pueden luego distribuir nombres de dominio bajo el TLD, generalmente a través de un registrador de dominios.
Hosts
Dentro de un dominio, el propietario del dominio puede definir hosts individuales, que se refieren a computadoras o servicios separados accesibles a través de un dominio. Por ejemplo, la mayoría de los propietarios de dominios hacen que sus servidores web sean accesibles a través del dominio en sí (example.com) y también a través de la definición de “host” “www” (www.example.com).
Puedes tener otras definiciones de host bajo el dominio general. Podrías tener acceso a la API a través de un host “api” (api.example.com) o podrías tener acceso ftp definiendo un host llamado “ftp” o “files” (ftp.example.com o files.example.com). Los nombres de host pueden ser arbitrarios siempre que sean únicos para el dominio.
Subdominio
A subject related to hosts are subdomains.
El DNS funciona en una jerarquía. Los TLD pueden tener muchos dominios bajo ellos. Por ejemplo, el TLD “com” tiene tanto “google.com” como “ubuntu.com” debajo de él. Un “subdominio” se refiere a cualquier dominio que sea parte de un dominio más grande. En este caso, “ubuntu.com” se puede decir que es un subdominio de “com”. Esto generalmente se llama el dominio o la parte “ubuntu” se llama SLD, lo que significa segundo nivel de dominio.
Del mismo modo, cada dominio puede controlar “subdominios” que se encuentran bajo él. Esto es lo que normalmente entendemos por subdominios. Por ejemplo, podrías tener un subdominio para el departamento de historia de tu escuela en “www.history.school.edu“. La parte “history” es un subdominio.
La diferencia entre un nombre de host y un subdominio es que un host define una computadora o recurso, mientras que un subdominio extiende el dominio padre. Es un método de subdividir el dominio en sí.
Esto significa que especifica cada dominio padre, incluido el TLD. Un FQDN adecuado termina con un punto, indicando la raíz de la jerarquía DNS. Un ejemplo de un FQDN es “mail.google.com.“. A veces, el software que solicita un FQDN no requiere el punto final, pero el punto final es necesario para cumplir con los estándares de ICANN.
Servidor de nombres
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.
Los servidores de nombres pueden ser “autorizados”, lo que significa que dan respuestas a consultas sobre dominios bajo su control. De lo contrario, pueden apuntar a otros servidores o servir copias en caché de los datos de otros servidores de nombres.
Archivo 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.
Los archivos de zona residen en servidores de nombres y generalmente definen los recursos disponibles bajo un dominio específico, o el lugar al que se puede ir para obtener esa información.
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 un archivo de zona, se mantienen registros. En su forma más simple, un registro es básicamente un mapeo único entre un recurso y un nombre. Estos pueden mapear un nombre de dominio a una dirección IP, definir los servidores de nombres para el dominio, definir los servidores de correo para el dominio, etc.
Registros
Dentro de un archivo de zona, se mantienen los registros. En su forma más simple, un registro es básicamente una única asignación entre un recurso y un nombre. Estos pueden mapear un nombre de dominio a una dirección IP, definir los servidores de nombres para el dominio, definir los servidores de correo para el dominio, etc.
Cómo funciona DNS
Ahora que estás familiarizado con algunos de los términos involucrados con DNS, ¿cómo funciona realmente el sistema?
El sistema es muy simple desde una visión de alto nivel, pero es muy complejo a medida que se observan los detalles. Sin embargo, es una infraestructura muy confiable que ha sido esencial para la adopción de Internet tal como la conocemos hoy en día.
Servidores raíz
Como dijimos anteriormente, DNS es, en su núcleo, un sistema jerárquico. En la cima de este sistema están lo que se conocen como “servidores raíz”. Estos servidores son controlados por diversas organizaciones y tienen la autoridad delegada por ICANN (Internet Corporation for Assigned Names and Numbers).
Actualmente hay 13 servidores raíz en operación. Sin embargo, dado que hay un número increíble de nombres para resolver cada minuto, cada uno de estos servidores en realidad está replicado. Lo interesante de esta configuración es que cada uno de los espejos de un solo servidor raíz comparte la misma dirección IP. Cuando se realizan solicitudes para un servidor raíz determinado, la solicitud se dirigirá al espejo más cercano de ese servidor raíz.
¿Qué hacen estos servidores raíz? Los servidores raíz manejan solicitudes de información sobre dominios de nivel superior. Entonces, si llega una solicitud para algo que un servidor de nombres de nivel inferior no puede resolver, se hace una consulta al servidor raíz para el dominio.
Los servidores raíz en realidad no sabrán dónde se aloja el dominio. Sin embargo, podrán dirigir al solicitante a los servidores de nombres que manejan el dominio de nivel superior específicamente solicitado.
Entonces, si se realiza una solicitud para “www.wikipedia.org” al servidor raíz, el servidor raíz no encontrará el resultado en sus registros. Revisará sus archivos de zona para una lista que coincida con “www.wikipedia.org“. No lo encontrará.
En cambio, encontrará un registro para el TLD “org” y le dará a la entidad solicitante la dirección del servidor de nombres responsable de las direcciones “org”.
Servidores TLD
El solicitante luego envía una nueva solicitud a la dirección IP (dada por el servidor raíz) que es responsable del dominio de nivel superior de la solicitud.
Entonces, para continuar con nuestro ejemplo, enviaría una solicitud al servidor de nombres responsable de conocer los dominios “org” para ver si sabe dónde se encuentra “www.wikipedia.org“.
Una vez más, el solicitante buscará “www.wikipedia.org” en sus archivos de zona. No encontrará este registro en sus archivos.
Sin embargo, encontrará un registro que enumera la dirección IP del servidor de nombres responsable de “wikipedia.org“. Esto nos acerca mucho más a la respuesta que queremos.
Servidores de nombres a nivel de dominio
En este punto, el solicitante tiene la dirección IP del servidor de nombres que es responsable de conocer la dirección IP real del recurso. Envía una nueva solicitud al servidor de nombres preguntando, una vez más, si puede resolver “www.wikipedia.org“.
El servidor de nombres verifica sus archivos de zona y encuentra que tiene un archivo de zona asociado con “wikipedia.org“. Dentro de este archivo, hay un registro para el host “www”. Este registro indica la dirección IP donde se encuentra este host. El servidor de nombres devuelve la respuesta final al solicitante.
¿Qué es un servidor de nombres de resolución?
En el escenario anterior, nos referimos a un “solicitante”. ¿Qué es el solicitante en esta situación?
En casi todos los casos, el solicitante será lo que llamamos un “servidor de nombres resolutivo”. Un servidor de nombres resolutivo es uno configurado para hacer preguntas a otros servidores. Es básicamente un intermediario para un usuario que guarda resultados de consultas anteriores para mejorar la velocidad y conoce las direcciones de los servidores raíz para poder “resolver” solicitudes realizadas para cosas que no sabe ya.
Básicamente, un usuario normalmente tendrá unos cuantos servidores de nombres resolutivos configurados en su sistema informático. Los servidores de nombres resolutivos suelen ser proporcionados por un ISP u otras organizaciones. Por ejemplo, Google proporciona servidores DNS resolutivos que puedes consultar. Estos pueden estar configurados automáticamente o manualmente en tu computadora.
Cuando escribes una URL en la barra de direcciones de tu navegador, tu computadora primero busca si puede averiguar localmente dónde se encuentra el recurso. Busca el archivo “hosts” en la computadora y algunas otras ubicaciones. Luego envía la solicitud al servidor de nombres resolutivo y espera recibir la dirección IP del recurso.
El servidor de nombres resolutivo luego busca la respuesta en su caché. Si no la encuentra, pasa por los pasos descritos anteriormente.
Los servidores de nombres resolutivos básicamente comprimen el proceso de solicitud para el usuario final. Los clientes simplemente tienen que saber preguntar a los servidores de nombres resolutivos dónde se encuentra un recurso y tener la confianza de que investigarán y devolverán la respuesta final.
Archivos de zona
Mencionamos en el proceso anterior la idea de “archivos de zona” y “registros”.
Los archivos de zona son la forma en que los servidores de nombres almacenan información sobre los dominios que conocen. Cada dominio que un servidor de nombres conoce se guarda en un archivo de zona. La mayoría de las solicitudes que llegan al servidor de nombres promedio no son para las cuales el servidor tenga archivos de zona.
Si está configurado para manejar consultas recursivas, como un servidor de nombres resolvente, averiguará la respuesta y la devolverá. De lo contrario, le dirá a la parte solicitante dónde buscar a continuación.
Cuantos más archivos de zona tenga un servidor de nombres, más solicitudes podrá responder de manera 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.
El $ORIGIN de la zona es un parámetro igual a la autoridad de nivel más alto de la zona de forma predeterminada.
Entonces, si se utiliza un archivo de zona para configurar el dominio “example.com.“, el $ORIGIN se establecería en example.com..
Esto se configura en la parte superior del archivo de zona o se puede definir en el archivo de configuración del servidor DNS que hace referencia al archivo de zona. De cualquier manera, este parámetro describe para qué será autoritaria la zona.
De manera similar, el $TTL configura el “tiempo de vida” de la información que proporciona. Básicamente es un temporizador. Un servidor de nombres en caché puede usar resultados consultados previamente para responder preguntas hasta que el valor TTL se agote.
Tipos de registros
Dentro del archivo de zona, podemos tener muchos tipos de registros diferentes. Aquí repasaremos algunos de los más comunes (o tipos obligatorios).
Registros SOA
El registro de Inicio de Autoridad, o SOA, es un registro obligatorio en todos los archivos de zona. Debe ser el primer registro real en un archivo (aunque las especificaciones $ORIGIN o $TTL pueden aparecer arriba). También es uno de los más complejos de entender.
El registro de inicio de autoridad se ve algo así:
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
)
Explicaremos para qué sirve cada parte:
-
domain.com.: Este es el origen de la zona. Esto especifica que el archivo de zona es para el dominiodomain.com.. A menudo, verás esto reemplazado con@, que es solo un marcador de posición que sustituye el contenido de la variable$ORIGINque aprendimos anteriormente. -
IN SOA: La parte “IN” significa internet (y estará presente en muchos registros). SOA es el indicador de que este es un registro de Inicio de Autoridad.
-
ns1.domain.com.: Esto define el servidor de nombres primario para este dominio. Los servidores de nombres pueden ser primarios o secundarios, y si se configura DNS dinámico, un servidor debe ser “primario”, que va aquí. Si no ha configurado DNS dinámico, entonces este es solo uno de sus servidores de nombres primarios. -
admin.domain.com.: Esta es la dirección de correo electrónico del administrador para esta zona. El “@” se reemplaza con un punto en la dirección de correo electrónico. Si la parte del nombre de la dirección de correo electrónico normalmente tiene un punto, esto se reemplaza por un “” en esta parte ([email protected]se convierte enyour\name.domain.com). -
12083: Este es el número de serie del archivo de zona. Cada vez que edites un archivo de zona, debes incrementar este número para que el archivo de zona se propague correctamente. Los servidores secundarios verificarán si el número de serie del servidor primario para una zona es mayor que el que tienen en su sistema. Si lo es, solicitará el nuevo archivo de zona, si no, continuará sirviendo el archivo original.
-
3h: Este es el intervalo de actualización para la zona. Este es el tiempo que el secundario esperará antes de solicitar al primario los cambios en el archivo de zona.
-
30m: Este es el intervalo de reintento para esta zona. Si el secundario no puede conectarse al primario cuando ha transcurrido el período de actualización, esperará este tiempo y volverá a intentar solicitar al primario.
-
3w: Este es el período de expiración. Si un servidor de nombres secundario no ha podido contactar al primario durante este tiempo, ya no devuelve respuestas como una fuente autorizada para esta zona.
-
1h: Este es el tiempo durante el cual el servidor de nombres almacenará en caché un error de nombre si no puede encontrar el nombre solicitado en este archivo.
A and AAAA Records
Ambos de estos registros asignan un host a una dirección IP. El registro “A” se utiliza para asignar un host a una dirección IP IPv4, mientras que los registros “AAAA” se utilizan para asignar un host a una dirección IPv6.
El formato general de estos registros es este:
host IN A IPv4_address
host IN AAAA IPv6_address
Entonces, dado que nuestro registro SOA menciona un servidor primario en “ns1.domain.com”, tendríamos que mapearlo a una dirección IP, ya que “ns1.domain.com” está dentro de la zona “domain.com” que este archivo está definiendo.
El registro podría lucir así:
ns1 IN A 111.222.111.222
Fíjate que no tenemos que proporcionar el nombre completo. Podemos simplemente dar el host, sin el FQDN, y el servidor DNS completará el resto con el valor $ORIGIN. Sin embargo, también podríamos usar el FQDN completo si queremos ser precisos:
ns1.domain.com. IN A 111.222.111.222
En la mayoría de los casos, aquí es donde definirás tu servidor web como “www”:
www IN A 222.222.222.222
También debemos indicar dónde se resuelve el dominio base. Podemos hacerlo así:
domain.com. IN A 222.222.222.222
Podríamos haber utilizado “@” para referirnos al dominio base en lugar de escribirlo completo:
@ IN A 222.222.222.222
También tenemos la opción de resolver cualquier cosa bajo este dominio que no esté definida explícitamente a este servidor. Podemos hacerlo con el comodín “*”:
* IN A 222.222.222.222
Todos estos funcionan igual de bien con registros AAAA para direcciones IPv6.
Registros CNAME
Los registros CNAME definen un alias para el nombre canónico de tu servidor (definido por un registro A o AAAA).
Por ejemplo, podríamos tener un registro de nombre A que defina el host “server1” y luego usar “www” como un alias para este host:
server1 IN A 111.111.111.111
www IN CNAME server1
Tenga en cuenta que estos alias conllevan algunas pérdidas de rendimiento porque requieren una consulta adicional al servidor. La mayoría de las veces, se podría lograr el mismo resultado utilizando registros A o AAAA adicionales.
Un caso en el que se recomienda un CNAME es para proporcionar un alias para un recurso fuera de la zona actual.
Registros MX
Los registros MX se utilizan para definir los intercambios de correo que se utilizan para el dominio. Esto ayuda a que los mensajes de correo electrónico lleguen correctamente a su servidor de correo.
A diferencia de muchos otros tipos de registros, los registros de correo generalmente no mapean un host a algo, porque se aplican a toda la zona. Por lo tanto, generalmente se ven así:
IN MX 10 mail.domain.com.
Tenga en cuenta que no hay un nombre de host al principio.
También tenga en cuenta que hay un número extra allí. Este es el número de preferencia que ayuda a los equipos a decidir a qué servidor enviar correo si se definen múltiples servidores de correo. Los números más bajos tienen una prioridad más alta.
El registro MX generalmente debería apuntar a un host definido por un registro A o AAAA, y no a uno definido por un CNAME.
Entonces, digamos que tenemos dos servidores de correo. Deberían haber registros que se parezcan a algo como esto:
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
En este ejemplo, el host “mail1” es el servidor de intercambio de correo preferido.
También podríamos escribir eso así:
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 los servidores de nombres que se utilizan para esta zona.
Puede que te estés preguntando: “si el archivo de zona reside en el servidor de nombres, ¿por qué necesita hacer referencia a sí mismo?”. Parte de lo que hace que DNS sea tan exitoso es su múltiples niveles de almacenamiento en caché. Una razón para definir servidores de nombres dentro del archivo de zona es que el archivo de zona puede estar siendo servido realmente desde una copia en caché en otro servidor de nombres. Hay otras razones para necesitar que los servidores de nombres estén definidos en el propio servidor de nombres, pero no entraremos en eso aquí.
Al igual que los registros MX, estos son parámetros de toda la zona, por lo que no toman hosts. En general, se ven así:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
Deberías tener al menos dos servidores de nombres definidos en cada archivo de zona para operar correctamente si hay un problema con un servidor. La mayoría del software de servidor DNS considera que un archivo de zona es inválido si solo hay un único servidor de nombres.
Como siempre, incluye el mapeo para los hosts con registros 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
Hay bastantes otros tipos de registros que puedes usar, pero estos son probablemente los tipos más comunes con los que te encontrarás.
Registros PTR
Los registros PTR se utilizan para definir un nombre asociado con una dirección IP. Los registros PTR son el inverso de un registro A o AAAA. Los registros PTR son únicos en que comienzan en la raíz .arpa y se delegan a los propietarios de las direcciones IP. Los Registros Regionales de Internet (RIRs) gestionan la delegación de direcciones IP a organizaciones y proveedores de servicios. Los Registros Regionales de Internet incluyen APNIC, ARIN, RIPE NCC, LACNIC y AFRINIC.
Aquí hay un ejemplo de cómo se vería un registro PTR para 111.222.333.444:
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
Este ejemplo de un registro PTR para una dirección IPv6 muestra el formato de nibble inverso del Servidor DNS IPv6 de 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.
La herramienta de línea de comandos dig con la bandera -x se puede utilizar para buscar el nombre DNS inverso de una dirección IP.
Aquí hay un ejemplo de un comando dig. El +short se agrega para reducir la salida al nombre DNS inverso.
La salida del comando dig anterior será el nombre de dominio en el registro PTR para la dirección IP:
google-public-dns-b.google.com.
Los servidores en Internet utilizan registros PTR para colocar nombres de dominio dentro de entradas de registro, tomar decisiones informadas sobre el manejo de spam y mostrar detalles fáciles de leer sobre otros dispositivos.
La mayoría de los servidores de correo electrónico más utilizados buscarán el registro PTR de una dirección IP de la que reciban correo electrónico. Si la dirección IP de origen no tiene asociado un registro PTR, es posible que los correos electrónicos enviados sean tratados como spam y rechazados. No es importante que el FQDN en el PTR coincida con el nombre de dominio del correo electrónico que se está enviando. Lo importante es que haya un registro PTR válido con un correspondiente y coincidente registro A hacia adelante.
Normalmente, a los enrutadores de red en Internet se les asignan registros PTR que corresponden con su ubicación física. Por ejemplo, es posible que veas referencias a ‘NYC’ o ‘CHI’ para un enrutador en la ciudad de Nueva York o Chicago. Esto es útil al ejecutar un traceroute o MTR y revisar la ruta que está tomando el tráfico de Internet.
La mayoría de los proveedores que ofrecen servidores dedicados o servicios VPS darán a los clientes la capacidad de establecer un registro PTR para su dirección IP. DigitalOcean asignará automáticamente el registro PTR de cualquier Droplet cuando el Droplet tenga un nombre de dominio. El nombre del Droplet se asigna durante la creación y se puede editar más tarde utilizando la página de configuración del panel de control del Droplet.
Nota: Es importante que el FQDN en el registro PTR tenga un registro A correspondiente y coincidente. Ejemplo: 111.222.333.444 tiene un PTR de servidor.ejemplo.com y servidor.ejemplo.com es un registro A que apunta a 111.222.333.444.
Registros CAA
Los registros CAA se utilizan para especificar qué Autoridades de Certificación (CAs) tienen permiso para emitir certificados SSL/TLS para tu dominio. A partir del 8 de septiembre de 2017, todas las CAs están obligadas a verificar estos registros antes de emitir un certificado. Si no hay ningún registro presente, cualquier CA puede emitir un certificado. De lo contrario, solo las CAs especificadas pueden emitir certificados. Los registros CAA se pueden aplicar a hosts individuales o a dominios enteros.
A continuación, se muestra un ejemplo de registro CAA:
example.com. IN CAA 0 issue "letsencrypt.org"
El host, IN, y el tipo de registro (CAA) son campos DNS comunes. La información específica de CAA anterior es la parte 0 issue "letsencrypt.org". Está compuesta por tres partes: flags (0), tags (issue), y valores ("letsencrypt.org").
- Los flags son enteros que indican cómo una CA debe manejar las etiquetas que no entiende. Si el flag es
0, el registro será ignorado. Si es1, la CA debe rechazar emitir el certificado. - Las etiquetas son cadenas que indican el propósito de un registro CAA. Actualmente pueden ser
issuepara autorizar a una CA a crear certificados para un nombre de host específico,issuewildpara autorizar certificados comodín, oiodefpara definir una URL donde las CAs pueden informar sobre violaciones de políticas. - Los valores son una cadena asociada con la etiqueta de registro. Para
issueyissuewild, esto típicamente será el dominio de la AC a la que estás otorgando el permiso. Paraiodef, esto puede ser la URL de un formulario de contacto o un enlacemailto:para comentarios por correo electrónico.
Puedes usar dig para obtener registros CAA usando las siguientes opciones:
Para obtener información más detallada sobre los registros CAA, puedes leer RFC 6844, o nuestro tutorial Cómo crear y gestionar registros CAA utilizando el DNS de DigitalOcean
Conclusión
Ahora deberías tener una buena comprensión de cómo funciona el DNS. Aunque la idea general es relativamente fácil de entender una vez que estás familiarizado con la estrategia, esto aún puede ser difícil para administradores inexpertos ponerlo en práctica.
Para obtener una visión general, consulta Cómo configurar dominios dentro del Panel de Control de DigitalOcean.