Componentes y Conceptos de DNS. Introducción a la Terminología
Introducción
Componentes y Conceptos de DNS. Introducción a la Terminología. DNS, o el Sistema de nombres de dominio, a menudo es una parte muy difícil de aprender cómo configurar sitios web y servidores. Comprender cómo funciona el DNS lo ayudará a diagnosticar problemas al configurar el acceso a sus sitios web y le permitirá ampliar su comprensión.
En este tutorial, discutiremos algunos conceptos fundamentales de DNS que te ayudarán a comenzar a ejecutar con tu configuración de DNS. Después de abordar esta tutorial, debe estar preparado para configurar su propio servidor DNS
Antes de saltar a la configuración de sus propios servidores para resolver su dominio o configurar nuestros propios dominios en el panel de control, repasemos algunos conceptos básicos sobre cómo funciona todo esto.
Terminología de Dominio
Deberíamos comenzar por definir nuestros términos. Si bien algunos de estos temas son familiares desde otros contextos, hay muchos términos que se usan cuando se habla de nombres de dominio y DNS que no se utilizan con demasiada frecuencia en otras áreas de la informática.
Empecemos, es muy fácil:
Sistema de Nombres de Dominio
El sistema de nombre de dominio, más comúnmente conocido como "DNS" es el sistema de red que permite resolver los nombres y dar direcciones únicas.
Nombre de Dominio
Un nombre de dominio es el nombre amigable para los humanos que estamos acostumbrados a asociar con un recurso de Internet. Por ejemplo, "google.com" es un nombre de dominio. Algunas personas dirán que la parte "google" es el dominio, pero generalmente podemos referirnos a la forma combinada como nombre de dominio.
La URL "google.com" está asociada a los servidores propiedad de Google Inc. El sistema de nombre 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 de red. Cada dirección IP debe ser única dentro de su red. Cuando hablamos de sitios web, esta red es toda la Internet.
IPv4, la forma más común de direcciones, se escribe como cuatro conjuntos de números, cada conjunto tiene hasta tres dígitos, con cada conjunto separado por un punto. Por ejemplo, "111.222.111.222" podría ser una dirección IP IPv4 válida. Con DNS, asignamos un nombre a esa dirección para que no tenga que recordar un conjunto complicado de números para cada lugar que desea visitar en una red.
Dominio de Nivel Superior
Un dominio de nivel superior o TLD es la parte más general del dominio. El dominio de nivel superior es la parte más alejada a la derecha (separada por un punto). Los dominios comunes de nivel superior son "com", "net", "org", "gov", "edu" e "io".
Los dominios de nivel superior se encuentran en la parte superior de la jerarquía en términos de nombres de dominio. La ICANN (Corporación de Internet para Nombres y Números Asignados) confiere a ciertas partes control de gestión sobre los dominios de nivel superior. Estas partes pueden luego distribuir nombres de dominio bajo el TLD, generalmente a través de un registrador de dominio.
Gestores
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 simple (example.com) y también a través de la definición de "host" "www" ( www.example.com ).
Puede tener otras definiciones de host bajo el dominio general. Puede tener acceso a la API a través de un host "api" (api.example.com) o puede tener acceso ftp definiendo un host llamado "ftp" o "archivos" (ftp.example.com o files.example.com). Los nombres de host pueden ser arbitrarios siempre que sean únicos para el dominio.
Subdominio:
Un tema relacionado con hosts son subdominios.
DNS funciona en una jerarquía. Los TLD pueden tener muchos dominios debajo de ellos. Por ejemplo, el TLD "com" tiene debajo "google.com" y "ubuntu.com". Un "subdominio" se refiere a cualquier dominio que sea parte de un dominio más grande. En este caso, se puede decir que "ubuntu.com" es un subdominio de "com". Esto normalmente se llama dominio o la porción "ubuntu" se llama SLD, lo que significa dominio de segundo nivel.
Del mismo modo, cada dominio puede controlar los "subdominios" que se encuentran debajo de él. Esto es generalmente lo que queremos decir con subdominios. Por ejemplo, podría tener un subdominio para el departamento de historia de su escuela en " www.history.school.edu ". La porción de "historia" es un subdominio.
La diferencia entre un nombre de host y un subdominio es que un host define una computadora o un recurso, mientras que un subdominio extiende el dominio principal. Es un método de subdividir el dominio en sí mismo.
Ya sea que hablemos de subdominios o hosts, puede comenzar a ver que las porciones más a la izquierda de un dominio son las más específicas. Así es como funciona el DNS: de mayor a menor específico a medida que lee de izquierda a derecha.
Nombre de Dominio Completo
Un nombre de dominio completamente calificado, a menudo llamado FQDN, es lo que llamamos un nombre de dominio absoluto. Los dominios en el sistema DNS se pueden dar en relación uno con el otro, y como tal, pueden ser algo ambiguos. Un FQDN es un nombre absoluto que especifica su ubicación en relación con la root absoluta del sistema de nombre de dominio.
Esto significa que especifica cada dominio principal, incluido el TLD. Un FQDN apropiado finaliza con un punto, que indica la root de la jerarquía DNS. Un ejemplo de un FQDN es "mail.google.com". En ocasiones, el software que requiere FQDN no requiere el punto final, pero se requiere que el punto final se ajuste a los estándares de la ICANN.
Nombre del Servidor
Un servidor de nombres es una computadora designada para traducir nombres de dominio en direcciones IP. Estos servidores hacen la mayor parte del trabajo en el sistema DNS. Dado que el número total de traducciones de dominio es demasiado para un solo servidor, cada servidor puede redirigir la solicitud a otros servidores de nombres o delegar la responsabilidad de un subconjunto de subdominios de los que son responsables.
Los servidores de nombres pueden ser "autorizados", lo que significa que dan respuestas a consultas sobre dominios bajo su control. De lo contrario, pueden señalar a otros servidores o servir copias en caché de los datos de otros servidores de nombres.
Archivo de Zona
Un archivo de zona es un archivo de texto simple que contiene las asignaciones entre nombres de dominio y direcciones IP. Así es como el sistema DNS finalmente descubre con qué dirección IP se debe contactar cuando un usuario solicita un determinado nombre de dominio.
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 acceder para obtener esa información.
Archivos
Dentro de un archivo de zona, se guardan los registros. En su forma más simple, un registro es básicamente una sola asignación entre un recurso y un nombre. Estos pueden asignar 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 el DNS?
Ahora que está familiarizado con parte de la terminología relacionada con DNS, ¿cómo funciona realmente el sistema?
El sistema es muy simple en una descripción general de alto nivel, pero es muy complejo al mirar los detalles. Sin embargo, en general, es una infraestructura muy confiable que ha sido esencial para la adopción de Internet tal como la conocemos hoy.
Servidores Root
Como dijimos anteriormente, el DNS es, en esencia, un sistema jerárquico. En la parte superior de este sistema se encuentran los llamados "servidores root". Estos servidores están controlados por diversas organizaciones y ICANN (Corporación de Internet para Nombres y Números Asignados) delega autoridad.
Actualmente hay 13 servidores root en operación. Sin embargo, como hay una increíble cantidad de nombres para resolver cada minuto, cada uno de estos servidores se duplica. Lo interesante de esta configuración es que cada uno de los duplicadores de un único servidor root comparte la misma dirección IP. Cuando se realizan solicitudes para un determinado servidor root, la solicitud se enrutará al servidor reflejado más cercano de ese servidor root.
¿Qué hacen estos servidores root? Los servidores root manejan las solicitudes de información sobre los dominios de nivel superior. Por lo tanto, si una solicitud entra para algo que un servidor de nombres de nivel inferior no puede resolver, se realiza una consulta al servidor root para el dominio.
Los servidores root en realidad no sabrán dónde está alojado el dominio. Sin embargo, podrán dirigir al solicitante a los servidores de nombres que manejan el dominio de nivel superior específicamente solicitado.
Por lo tanto, si se realiza una solicitud de " www.wikipedia.org " en el servidor root, el servidor root no encontrará el resultado en sus registros. Verificará sus archivos de zona para una lista que coincida con " www.wikipedia.org ". No encontrará uno.
En su lugar, 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
A continuación, el solicitante envía una nueva solicitud a la dirección IP (que le asigna el servidor root) 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.wikipdia.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 se está acercando mucho más a la respuesta que queremos.
Servidores de Nombre de 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 descubre que tiene un archivo de zona asociado con "wikipedia.org". Dentro de este archivo, hay un registro para el host "www". Este registro le dice a 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". ¿Cuál es el solicitante en esta situación?
En casi todos los casos, el solicitante será lo que llamamos "servidor de nombres de resolución". Un servidor de nombres de resolución está configurado para hacer preguntas a otros servidores. Básicamente es un intermediario para un usuario que guarda en caché los resultados de consultas anteriores para mejorar la velocidad y conoce las direcciones de los servidores root para poder "resolver" las solicitudes hechas para cosas que aún no conoce.
Básicamente, un usuario generalmente tendrá algunos servidores de nombres de resolución configurados en su sistema informático. Los servidores de nombres de resolución generalmente son proporcionados por un ISP u otras organizaciones. Por ejemplo, Google ofrece la resolución de servidores DNS que puede consultar. Estos pueden ser configurados en su computadora de forma automática o manual.
Cuando escribe una URL en la barra de direcciones de su navegador, su computadora primero busca para ver si puede encontrar localmente dónde se encuentra el recurso. Comprueba el archivo "hosts" en la computadora y en algunas otras ubicaciones. A continuación, envía la solicitud al servidor de nombres de resolución y espera a recibir la dirección IP del recurso.
El servidor de nombres de resolución luego verifica su caché en busca de la respuesta. Si no lo encuentra, sigue los pasos descritos anteriormente.
La resolución de servidores de nombres básicamente comprime el proceso de solicitud para el usuario final. Los clientes simplemente tienen que saber para preguntar a los servidores de nombres de resolución dónde se encuentra un recurso y tener la seguridad 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. Todos los dominios que conoce un servidor de nombres se almacenan en un archivo de zona. La mayoría de las solicitudes que llegan al servidor de nombres promedio no son algo para lo que el servidor tendrá archivos de zona.
Si está configurado para manejar consultas recursivas, como un servidor de nombres de resolución, encontrará la respuesta y la devolverá. De lo contrario, le indicará a la parte solicitante a dónde mirar a continuación.
Cuantos más archivos de zona tenga un servidor de nombres, más solicitudes podrá responder autoritativamente.
Un archivo de zona describe una "zona" de DNS, que básicamente es un subconjunto de todo el sistema de nombres de DNS. Generalmente se usa para configurar solo un dominio. Puede contener varios registros que definen dónde están los recursos para el dominio en cuestión.
El $ORIGIN es un parámetro igual al nivel de autoridad más alto de la zona de manera predeterminada.
Entonces, si un archivo de zona se usa para configurar el "ejemplo.com". dominio, $ORIGIN se establecerá 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 forma, este parámetro describe para qué va a ser autorizada la zona.
Del mismo modo, el $TTL configura el "tiempo de vida" de la información que proporciona. Básicamente es un temporizador. Un servidor de nombre de almacenamiento en caché puede usar los resultados consultados anteriormente para responder
preguntas hasta que se agote el valor de TTL.
Tipos de Registro
Dentro del archivo de zona, podemos tener muchos tipos de registros diferentes. Vamos a repasar algunos de los tipos más comunes (u obligatorios) aquí.
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 inicio del registro de autoridad se ve así:
dominio.com.;
EN SOA ns1.domain.com.;
admin.domain.com.;
12083. Número de serie;
3h. Intervalo de renovación;
30m. Intervalo de reintento;
3w. Período de caducidad;
1h. TTL Negativo.
Vamos a explicar para qué es cada parte:
-
dominio.com. Esta es la root de la zona. Esto especifica que el archivo de zona es para
domain.com.dominio. A menudo, verá esto reemplazado por@, que es solo un marcador de posición que sustituye el contenido de la variable$ORIGINque aprendimos anteriormente. -
EN SOA. La porción "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 principal de nombres principal para este dominio. Los servidores de nombres pueden ser maestros o esclavos, y si el DNS dinámico está configurado, un servidor necesita ser un "maestro principal", que va aquí. Si no ha configurado el DNS dinámico, este es solo uno de sus servidores de nombres maestros.
-
admin.domain.com. Esta es la dirección de correo electrónico del administrador de esta zona. La "@" 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, se reemplaza con una "\" en esta parte ( Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo. convierte en su \ nombre.domain.com).
-
12083. Este es el número de serie para el archivo de zona. Cada vez que edite un archivo de zona, debe incrementar este número para que el archivo de zona se propague correctamente. Los servidores esclavos verificarán si el número de serie del servidor maestro para una zona es más grande que el que tienen en su sistema. Si es así, solicita el nuevo archivo de zona, de lo contrario, continúa sirviendo el archivo original.
-
3h. Es el intervalo de actualización para la zona. Esta es la cantidad de tiempo que el esclavo esperará antes de interrogar al maestro por los cambios en el archivo de zona.
-
30m. Es el intervalo de reintento para esta zona. Si el esclavo no se puede conectar al maestro cuando el período de actualización está activo, esperará este período de tiempo y volverá a intentar sondear el maestro.
-
3w. Este es el período de vencimiento. Si un servidor de nombres esclavo no ha podido contactar al maestro durante este período de tiempo, ya no devuelve las respuestas como una fuente autorizada para esta zona.
-
1h. Esta es la cantidad de tiempo que el servidor de nombres guardará en caché un error de nombre si no puede encontrar el nombre solicitado en este archivo.
A y Registros AAAA
Ambos 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 llamó a un servidor principal maestro en "ns1.domain.com", tendríamos que asignarlo a una dirección de IP ya que "ns1.domain.com" está dentro de la zona "domain.com" que este archivo está definiendo.
El registro podría verse más o menos así:
ns1 IN A 111.222.111.222
Tenga en cuenta que no tenemos que dar el nombre completo. Podemos simplemente dar el host, sin el FQDN y el servidor DNS completará el resto con el valor $ ORIGIN. Sin embargo, podríamos usar fácilmente el FQDN completo si queremos ser semánticos:
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 deberíamos decir dónde se resuelve el dominio base. Podemos hacer esto así:
domain.com. IN A 222.222.222.222
Podríamos haber usado la "@" para referirnos al dominio base en su lugar:
@ IN A 222.222.222.222
También tenemos la opción de resolver cualquier cosa que esté bajo este dominio que no esté explícitamente definida en este servidor también. Podemos hacer esto con el comodín "*":
* IN A 222.222.222.222
Todos estos funcionan igual de bien con los registros AAAA para direcciones IPv6.
Registros CNAME
Los registros CNAME definen un alias para el nombre canónico de su servidor (uno definido por un registro A o AAAA).
Por ejemplo, podríamos tener un registro de nombre A definiendo el servidor "servidor1" y luego usar el "www" como un alias para este host:
server1 IN A 111.111.111.111
www IN CNAME server1
Tenga en cuenta que estos alias vienen con algunas pérdidas de rendimiento porque requieren una consulta adicional al servidor. La mayoría de las veces, el mismo resultado se puede lograr mediante el uso de registros adicionales A o AAAA.
Un caso cuando se recomienda un CNAME es 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 lleguen correctamente a su servidor de correo.
A diferencia de muchos otros tipos de registros, los registros de correo generalmente no asignan un host a algo, porque se aplican a toda la zona. Como tal, 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 adicional allí. Este es el número de preferencia que ayuda a las computadoras a decidir a qué servidor enviar correo si hay varios servidores de correo definidos. Los números más bajos tienen una prioridad más alta.
El registro MX generalmente debe apuntar a un host definido por un registro A o AAAA, y no uno definido por un CNAME.
Entonces, digamos que tenemos dos servidores de correo. Tendría que haber registros que se parezcan a 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 electrónico 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 usan para esta zona.
Es posible que se pregunte si "si el archivo de zona reside en el servidor de nombres, ¿por qué necesita referenciarse a sí mismo?". Parte de lo que hace que DNS sea tan exitoso son sus múltiples niveles de almacenamiento en caché. Una razón para definir los servidores de nombres dentro del archivo de zona es que el archivo de zona puede ser realmente servido desde una copia en caché en otro servidor de nombres. Existen otros motivos para necesitar los servidores de nombres definidos en el servidor de nombres, pero no veremos eso aquí.
Al igual que los registros MX, estos son parámetros de toda la zona, por lo que tampoco aceptan hosts. En general, se ven así:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
Debería 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 no es válido si solo hay un único servidor de nombres.
Como siempre, incluya la asignación 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 puede usar, pero estos son probablemente los tipos más comunes que encontrará.
Registros PTR
Los registros PTR utilizados definen un nombre asociado a una dirección IP. Los registros PTR son el inverso de un registro A o AAAA. Los registros PTR son únicos ya que comienzan en la root .arpa y se delegan a los propietarios de las direcciones
IP. Los Registros Regionales de Internet (RIR) gestionan la delegación de la dirección IP a la organización y los proveedores de servicios. Los Registros Regionales de Internet incluyen APNIC, ARIN, RIPE NCC, LACNIC y AFRINIC.
Aquí hay un ejemplo de un registro PTR para 111.222.333.444 que se vería así:
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 del reverso 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 comando dig con el indicador -x se puede utilizar para buscar el nombre DNS inverso de una dirección IP.
Aquí hay un ejemplo de un comando de excavación. El +short se agrega para reducir la salida al nombre DNS inverso.
dig -x 8.8.4.4 +short
La salida para el comando dig arriba será el nombre de dominio en el registro PTR para la dirección IP:
google-public-dns-b.google.com.
Los servidores en Internet usan registros PTR para colocar nombres de dominio dentro de las entradas de registro, tomar decisiones informadas sobre el manejo de correo no deseado y mostrar detalles fáciles de leer sobre otros dispositivos.
La mayoría de los servidores de correo electrónico de uso común buscarán el registro PTR de una dirección IP desde la que recibe el correo electrónico. Si la dirección IP de origen no tiene un registro PTR asociado, los correos electrónicos que se envían pueden tratarse como correo no deseado y rechazarse. No es importante que el FQDN en el PTR coincida con el nombre de dominio del correo electrónico que se envía. Lo que es importante es que haya un registro PTR válido con un registro correspondiente A correspondiente.
Normalmente los enrutadores de red en Internet reciben registros PTR que se corresponden con su ubicación física. Por ejemplo, puede ver referencias a 'NYC' o 'CHI' para un enrutador en la ciudad de Nueva York o Chicago. Esto es útil cuando se ejecuta un traceroute o MTR y se revisa la ruta que está tomando el tráfico de Internet.
La mayoría de los proveedores que ofrecen servidores dedicados o servicios VPS le darán a los clientes la capacidad de establecer un registro PTR para su dirección IP.
Nota: Es importante que el FQDN en el registro PTR tenga un registro correspondiente A correspondiente. Ejemplo: 111.222.333.444 tiene un PTR de server.example.com y server.example.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 (CA) pueden emitir certificados SSL / TLS para su dominio. A partir del 8 de septiembre de 2017, todas las CA deben verificar estos registros antes de emitir un certificado. Si no hay registros, cualquier CA puede emitir un certificado. De lo contrario, solo las CA especificadas pueden emitir certificados. Los registros CAA se pueden aplicar a hosts únicos o dominios completos.
Un ejemplo de registro de CAA sigue:
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 de 0 issue "letsencrypt.org" . Está compuesto por tres partes: flags ( 0 ), tags
( issue ) y values ( "letsencrypt.org" ).
- Los indicadores son un número entero que indica cómo una CA debe manejar las etiquetas que no comprende. Si el indicador es
0, el registro será ignorado. Si es1, la CA debe negarse a emitir el certificado. - Las etiquetas son cadenas que denotan el propósito de un registro de CAA. Actualmente pueden
issuepara autorizar a una CA para que cree certificados para un nombre de host específico,issuewildpara autorizar certificados comodín oiodefpara definir una URL donde las CA puedan informar infracciones de políticas. - Los valores son una cadena asociada con la etiqueta del registro. Para el
issuey laissuewildeste será el dominio de la CA al que usted otorga el permiso. Paraiodefeste puede ser el URL de un formulario de contacto, o unamailto:vínculo de retroalimentación de correo electrónico.
Puede usar dig para buscar registros CAA usando las siguientes opciones:
- dig example.com type257
Para obtener información más detallada sobre los registros de CAA, puede leer el RFC 6844
Conclusión
Ahora debería tener una buena idea del ¿cómo funciona el DNS? Si bien la idea general es relativamente fácil de entender una vez que está familiarizado con la estrategia, esto todavía es algo que puede ser difícil de poner en práctica para los administradores inexpertos.
Fuente. Artículo traducido y con muy ligeras modificaciones de: https://www.digitalocean.com/community/tutorials/an-introduction-to-dns-terminology-components-and-concepts
