Source: https://www.blog.binaria.uno/2019/04/05/que-es-dns-y-como-funciona/
Timestamp: 2019-10-17 05:28:21+00:00

Document:
El DNS, o el Sistema de Nombres de Dominio, es a menudo una parte muy difícil de cómo aprender a configurar sitios web y servidores. Comprender cómo funciona el DNS te ayudará a diagnosticar problemas con la configuración del acceso a tus sitios web y te permitirá ampliar tu comprensión de lo que está sucediendo tras bambalinas.
En esta guía, analizaremos algunos conceptos de DNS fundamentales que te ayudarán a comenzar a ejecutar su configuración de DNS. Después de abordar esta guía, debes estar listo para configurar tu nombre de dominio con Binaria o configurar tu propio servidor DNS.
Antes de pasar a configurar 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.
Comencemos fácil:
Domain Name System – Sistema de Nombres de Dominio
El sistema de nombres de dominio, más comúnmente conocido como “DNS” es el sistema de redes en el lugar que nos permite resolver nombres amigables para el hombre en direcciones únicas.
Un nombre de dominio es el nombre amigable para el ser humano 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 el nombre de dominio.
La URL “google.com” está asociada con los servidores propiedad de Google. El sistema de nombres de dominio nos permite acceder a los servidores de Google cuando escribimos “google.com” en nuestros navegadores.
Una dirección IP es lo que llamamos una ubicación direccionable de la red. Cada dirección IP debe ser única dentro de tu red. Cuando hablamos de sitios web, esta red es todo el internet.
IPv4, la forma más común de direcciones, se escriben como cuatro conjuntos de números, cada uno de los cuales tiene hasta tres dígitos y cada conjunto está separado por un punto. Por ejemplo, “111.222.111.222” podría ser una dirección IP válida de IPv4. Con DNS, asignamos un nombre a esa dirección para que no tengas que recordar un conjunto complicado de números para cada lugar que desees visitar en una red.
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 (separado por un punto). Los dominios comunes de nivel superior son “com”, “net”, “org”, “gov”, “edu” e “io”.
Los dominios de nivel superior están 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) otorga a ciertas partes el control de la administración sobre los dominios de nivel superior. Estas partes pueden distribuir nombres de dominio bajo el TLD, generalmente a través de un registrador de dominio.
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).
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 “archivos” (ftp.example.com o files.example.com). Los nombres de host pueden ser arbitrarios siempre que sean únicos para el dominio.
Un tema relacionado con los hosts son subdominios.
El DNS trabaja en una jerarquía. Los TLD pueden tener muchos dominios debajo de 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, se puede decir que “ubuntu.com” es un subdominio de “com”. Por lo general, esto se denomina simplemente dominio o la porción “ubuntu” se denomina SLD, lo que significa un dominio de segundo nivel.
Del mismo modo, cada dominio puede controlar “subdominios” que se encuentran debajo de él. Esto suele ser lo que entendemos por subdominios. Por ejemplo, podría tener un subdominio para el departamento de historia de tu escuela en ” www.history.school.edu”. La parte de “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 principal. Es un método de subdividir el propio dominio.
Ya sea al hablar de subdominios o hosts, puedes comenzar a ver que las partes más a la izquierda de un dominio son las más específicas. Así es como funciona el DNS: de más a menos específico a medida que lees de izquierda a derecha.
Fully Qualified Domain Name – Nombre de dominio completo
Un nombre de dominio completo, a menudo llamado FQDN, es lo que llamamos un nombre de dominio absoluto. Los dominios en el sistema DNS se pueden dar unos en relación con otros, y como tales, pueden ser algo ambiguos. Un FQDN es un nombre absoluto que especifica su ubicación en relación con la raíz absoluta del sistema de nombres de dominio.
Esto significa que especifica cada dominio principal, incluido el TLD. Un FQDN adecuado termina con un punto, que indica la raíz de la jerarquía de DNS. Un ejemplo de un FQDN es “mail.google.com”. A veces, 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.
Name server – servidor de nombres
Un name server es una computadora designada para traducir nombres de dominio a direcciones IP. Estos servidores hacen la mayor parte del trabajo en el sistema DNS. Dado que la cantidad total de traducciones de dominio es demasiado grande para cualquier servidor, cada servidor puede redirigir la solicitud a otros name server o delegar la responsabilidad de un subconjunto de subdominios de los que son responsables.
Los name server pueden ser “autorizados”, lo que significa que dan respuestas a las consultas sobre dominios bajo su control. De lo contrario, pueden apuntar a otros servidores o mostrar copias en caché de los datos de otros name server.
Los archivos de zona residen en name servers y generalmente definen los recursos disponibles bajo un dominio específico, o el lugar al que uno puede ir para obtener esa información.
Dentro de un archivo de zona, los registros se mantienen. En su forma más simple, un registro es básicamente una asignación única entre un recurso y un nombre. Estos pueden asignar un nombre de dominio a una dirección IP, definir los name servers para el dominio, definir los servidores de correo para el dominio, etc.
Ahora que estás familiarizado con algunos de los términos relacionados con DNS, ¿cómo funciona realmente el sistema?
El sistema es muy simple en una visió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 como la conocemos hoy.
Como dijimos anteriormente, el DNS es, en esencia, un sistema jerárquico. En la parte superior de este sistema se encuentran los ” root server – servidores raíz”. Estos servidores están controlados por varias organizaciones y están delegados por la ICANN (Corporación de Internet para Nombres y Números Asignados).
Actualmente hay 13 servidores raíz en operación. Sin embargo, como hay una cantidad increíble de nombres para resolver cada minuto, cada uno de estos servidores está reflejado. Lo interesante de esta configuración es que cada una de las réplicas de un solo servidor raíz comparte la misma dirección IP. Cuando se realizan solicitudes para un determinado servidor raíz, la solicitud se enrutará al espejo más cercano de ese servidor raíz.
Entonces, si se realiza una solicitud de “www.wikipedia.org” al servidor raíz, el servidor raíz 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”.
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 con 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 nombres 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 comprueba 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”. ¿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”. El servicio de resolución de servidor de nombres está configurado para hacer preguntas a otros servidores. Básicamente, es un intermediario para un usuario que almacena en caché los resultados de las consultas anteriores para mejorar la velocidad y conoce las direcciones de los servidores raíz para poder “resolver” las solicitudes de cosas que aún no conoce.
Básicamente, un usuario generalmente tendrá unos pocos servidores de nombres de resolución configurados en su sistema informático. Los servidores de nombres de resolución suelen ser proporcionados por un ISP u otras organizaciones. Por ejemplo, Google proporciona servidores DNS de resolución que puedes consultar. Estos pueden ser configurados en tu computadora automáticamente o manualmente.
Cuando escribes una URL en la barra de direcciones de tu navegador, tu computadora primero ve si puede encontrar localmente dónde se encuentra el recurso. Comprueba el archivo “hosts” en la computadora y algunas otras ubicaciones. Luego envía la solicitud al servidor de nombres de resolución y espera para recibir la dirección IP del recurso.
El servidor de nombres de resolución comprueba su caché para la respuesta. Si no lo encuentra, sigue los pasos descritos anteriormente.
Los servidores de nombres de resolución básicamente comprimen el proceso de solicitud para el usuario final. Los clientes simplemente deben saber preguntar a los servidores de nombres de resolución dónde se encuentra un recurso y tener la confianza de que investigarán y devolverán la respuesta final.
Mencionamos en el proceso anterior la idea de “archivos de zona” y “registros”.
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 dirá a la parte solicitante dónde buscar a continuación.
Un archivo de zona describe una “zona” de DNS, que es básicamente un subconjunto de todo el sistema de nombres de DNS. Generalmente se usa para configurar un solo dominio. Puede contener una serie de registros que definen dónde están los recursos para el dominio en cuestión.
La zona $ORIGIN es un parámetro igual al nivel más alto de autoridad de la zona por defecto.
Por lo tanto, si se usa un archivo de zona para configurar “example.com“, el $ORIGIN se establecería en example.com.
Del mismo modo, $TTL configura el ” time to live (tiempo de vida)” de la información que proporciona. Es básicamente un temporizador. Un servidor de nombres de almacenamiento en caché puede usar los resultados consultados previamente para responder preguntas hasta que se agote el valor TTL.
Dentro del archivo de zona, podemos tener muchos tipos de registros diferentes. Vamos a repasar algunos de los más comunes (o tipos obligatorios) aquí.
El registro Start of Authority o SOA, es un registro obligatorio en todos los archivos de zona. Debe ser el primer registro real en un archivo (aunque las especificaciones de $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 )
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
domain.com.:
Esta es la raíz de la zona. Esto especifica que el archivo de zona es para el dominio domain.com. A menudo, verás que este es reemplazado por @, que es solo un marcador de posición que sustituye el contenido de la variable $ORIGIN que aprendimos anteriormente.
La porción “IN” significa internet (y estará presente en muchos registros). La SOA es el indicador de que este es un registro de Start of Authority.
ns1.dominio.com.:
Esto define el servidor de nombres maestro primario para este dominio. Los servidores de nombres pueden ser maestros o esclavos, y si el DNS dinámico está configurado, un servidor debe ser un “maestro primario”, que se incluye aquí. Si no has configurado el DNS dinámico, este es solo uno de sus servidores de nombres maestros.
admin.dominio.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 un “\” en esta parte (your.name@domain.com convierte en your\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 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, si no, continúa mostrando el archivo original.
Este es el intervalo de actualización para la zona. Esta es la cantidad de tiempo que el esclavo esperará antes de sondear el maestro para los cambios de archivo de zona.
Este es el intervalo de reintento para esta zona. Si el esclavo no puede conectarse al maestro cuando finaliza el período de actualización, esperará esta cantidad de tiempo y volverá a intentar sondear el maestro.
Este es el periodo de expiración. Si un servidor de nombres esclavo no ha podido ponerse en contacto con el maestro durante este período de tiempo, ya no devolverá las respuestas como una fuente autorizada para esta zona.
Esta es la cantidad de tiempo que el servidor de nombres almacenará en la memoria caché un error de nombre si no puede encontrar el nombre solicitado en este archivo.
Ambos registros asignan un host a una dirección IP. El registro “A” se usa para asignar un host a una dirección IP IPv4, mientras que los registros “AAAA” se usan 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
host IN A IPv4_address
Por lo tanto, dado que nuestro registro SOA llamó a un servidor maestro primario en “ns1.domain.com”, tendríamos que asignarlo a una dirección 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 verse algo así:
Es importante tener en cuenta que no tenemos que dar el nombre completo. Solo podemos dar el host, sin el FQDN y el servidor DNS completará el resto con el valor $ORIGIN. Sin embargo, podríamos usar el FQDN completo con la misma facilidad si queremos ser semánticos:
En la mayoría de los casos, aquí es donde definirás tu servidor web como “www”:
Podríamos haber usado la “@” para referirnos al dominio base en su lugar:
También tenemos la opción de resolver cualquier cosa que, bajo este dominio, no esté definida explícitamente para este servidor. Podemos hacer esto con el comodín “*”:
Los registros CNAME definen un alias para el nombre canónico de tu servidor (uno 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
Hay que tomar en consideración que estos alias vienen con algunas pérdidas de rendimiento porque requieren una consulta adicional al servidor. La mayoría de las veces, se puede lograr el mismo resultado utilizando registros A o AAAA adicionales.
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 a tu servidor de correo correctamente.
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, usualmente se ven así:
Debes tener en cuenta que no hay un nombre de host al principio.
También considera 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 correos 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.
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 así:
IN MX 10 mail1 IN MX 50 mail2 mail1 IN A 111.111.111.111 mail2 IN A 222.222.222.222
Quizás 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 el 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 realmente ser mostrado desde una copia en caché en otro servidor de nombres.
Hay otras razones para necesitar que los servidores de nombres se definan en el servidor de nombres en sí, pero no lo veremos aquí.
Al igual que los registros MX, estos son parámetros de toda la zona, por lo que tampoco toman hosts. En general, se ven así:
IN NS ns1.domain.com. IN NS ns2.domain.com.
Debes tener al menos dos servidores de nombres definidos en cada archivo de zona para funcionar correctamente si hay un problema con un servidor. La mayoría del software del servidor DNS considera que un archivo de zona no es válido si solo hay un único servidor de nombres.
Como siempre, tienes que incluir 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 muchos otros tipos de registros que puedes usar, pero estos son probablemente los tipos más comunes con los que te encontrarás.
Los registros PTR que se utilizan definen un nombre asociado con una dirección IP. Estos registros PTR son el inverso de un registro A o AAAA. Dichos registros PTR son únicos, ya que comienzan en la raíz .arpa y se delegan a los propietarios de las direcciones IP. Los Registros Regionales de Internet (RIR por sus siglas en inglés) administran la delegación de direcciones IP a los proveedores de servicios y organización. Los Registros Regionales de Internet incluyen APNIC, ARIN, RIPE NCC, LACNIC y AFRINIC.
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 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.
Aquí hay un ejemplo de un comando dig. Se agrega +short para reducir la salida al nombre DNS inverso.
Los servidores en Internet utilizan los registros PTR para colocar nombres de dominio en las entradas del registro, tomar decisiones informadas sobre el manejo de spam y mostrar detalles fáciles de leer sobre otros dispositivos.
Los servidores de correo electrónico más utilizados buscarán el registro PTR de una dirección IP de la que recibe correo electrónico. Si la dirección IP de origen no tiene un registro PTR asociado, los correos electrónicos que se envíen 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 hay un registro PTR válido con un registro A correspondiente y coincidente.
Normalmente, los enrutadores de red en Internet reciben registros PTR que se corresponden con su ubicación física. Por ejemplo, puedes 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 de VPS, brindan a los clientes la capacidad de establecer un registro PTR para su dirección IP. Estos asignan automáticamente el registro PTR de cualquier Droplet cuando la Droplet tenga un nombre de dominio.
El nombre de 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 de Droplet.
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 server.example.com y server.example.com es un registro A que apunta a 111.222.333.444.
Los registros CAA se utilizan para especificar qué Autoridades de certificado (CA) pueden emitir certificados SSL/TLS para tu dominio. A partir del 8 de septiembre de 2017, todas las CA deben verificar estos registros antes de emitir un certificado. Si no hay registro presente, cualquier CA puede emitir un certificado. De lo contrario, solo las CA especificadas pueden emitir certificados. Los registros de CAA se pueden aplicar a hosts únicos o dominios completos.
Un ejemplo de registro CAA es este:
El host IN y el tipo de registro (CAA) son campos de DNS comunes. La información específica de CAA anterior es la parte 0 issue “letsencrypt.org”. Se compone de tres partes: flags (0), tags(issue) y values (“letsencrypt.org“).
Las flags.
Son un número entero que indica cómo una CA debe manejar las tags que no entiende. Si la bandera es 0, el registro será ignorado. Si 1, la CA debe negarse a emitir el certificado.
Las tags.
son cadenas que denotan el propósito de un registro CAA. Actualmente, pueden ser issue para autorizar a una CA a crear certificados para un nombre de host específico, issuewild para autorizar certificados comodín o iodef para definir una URL donde las CA pueden informar violaciones de políticas.
Los values.
son una cadena asociada con la tag del registro. Por issue y issuewild este será típicamente el dominio de la CA que está otorgando el permiso para. Para iodef esto puede ser la URL de un formulario de contacto, o un enlace mailto: para comentarios por correo electrónico.
Puedes usar dig para obtener registros de CAA usando las siguientes opciones:
$ dig example.com type257
Para obtener información más detallada sobre los registros de CAA, puedes leer RFC 6844
Ahora deberías tener un buen conocimiento de 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 sigue siendo algo que puede ser difícil de poner en práctica para los administradores inexpertos.
que es dns y como funcionaque es dns y como se configuraque es un dominio o dns
Phishing – perspectivas y soluciones de un atacante

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución