Source: https://cadascu.wordpress.com/2014/11/09/introduccion-al-dns-terminologia-componentes-y-conceptos/
Timestamp: 2018-03-17 04:37:38+00:00

Document:
Introducción al DNS. Terminología, componentes y Conceptos | Un lugar de Esparcimiento
← Instalar una pila LAMP ( Linux, Apache, MySQL, PHP ) en Ubuntu. Configuración de un servidor Dhcp.
Servidor DNS. Forwarding DNS Server →
Introducción al DNS. Terminología, componentes y Conceptos
Publicado el 9 noviembre, 2014	por Rafael Quintana
DNS o Domain Name System, es a menudo una parte muy difícil de aprender a configurar sitios web y servidores. Entender cómo funciona un servidor DNS nos ayudará a diagnosticar problemas con la configuración de acceso a tus sitios web y le permitirán ampliar su comprensión de lo que está pasando, de cuál es el problema.
En esta guía, vamos a discutir algunos de los conceptos fundamentales de DNS que le ayudarán a comenzar a trabajar con la configuración de DNS. Después de hacer frente a esta guía, usted seguro que estará listo para configurar su domain server o configurar su propio servidor DNS.
Antes de saltar a la creación de sus propios servidores para resolver su dominio o la creación de nuestros dominios en el panel de control, vamos a repasar algunos conceptos básicos acerca de cómo funciona todo esto en realidad.
Debemos empezar por definir nuestros términos. Mientras que algunos de estos temas son familiares de otros contextos, hay muchos términos que se utilizan cuando se habla de nombres de dominio y DNS y que no se utilizan con demasiada frecuencia en otros ámbitos.
El sistema de nombres de dominio, más comúnmente conocido como “DNS” es el sistema de red en el lugar que nos permite resolver los nombres “amigables” y comprensibles para los humanos en direcciones únicas.
Un nombre de dominio es el nombre por el que estamos acostumbrados a asociar un recurso de Internet. Por ejemplo, “google.com” es un nombre de dominio. Algunas personas dicen que la parte de “google” es el dominio, pero en general se puede referir a la forma combinada como el nombre de dominio.
La dirección URL “google.com” se asocia con los servidores propiedad de Google Inc. El sistema de nombres de dominio nos permite llegar a los servidores de Google cuando tecleamos “google.com” en nuestros navegadores.
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 estamos hablando de sitios web, esta red es la totalidad de Internet.
IPv4, la forma más común de direcciones, se escriben como cuatro grupos de números, cada conjunto que tienen hasta tres dígitos, con cada conjunto separado por un punto. Por ejemplo, “111.222.111.222” podrían ser una dirección IPv4 IP válida. Con DNS, asigna un nombre a esa dirección de manera que usted no tiene que recordar un complicado conjunto de números para cada lugar que desea 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 a la derecha (como separados por un punto). Dominios comunes de alto nivel son “com”, “net”, “org”, “gov”, “edu”, y “io”.
Dominios de nivel superior están en la cima de la jerarquía en cuanto a los nombres de dominio. Algunas partes se les dan el control sobre la gestión de dominios de nivel superior por la ICANN (Corporación de Internet para Nombres y Números Asignados). Estas partes pueden entonces distribuir los nombres de dominio bajo el dominio de nivel superior, por lo general a través de un registrador de dominios.
Dentro de un dominio, el propietario de dominio puede definir hosts individuales, que se refieren a separar los equipos o servicios accesibles a través de un dominio. Por ejemplo, la mayoría de los propietarios de dominio hacen que sus servidores web sean accesibles a través del dominio directo (example.com) y también a través de “www”, (www.example.com).
Usted puede tener otras definiciones de equipo
Un tema relacionado con los Host son los subdominios.
DNS funciona de una forma jerarquía. TLD (Un dominio de nivel superior o TLD (del inglés top-level domain) puede tener muchos dominios debajo de ellos. Por ejemplo, el dominio de nivel superior “com” tiene tanto “google.com” y “ubuntu.com” por debajo de ella. A “subdominio” se refiere a cualquier dominio que es parte de un dominio más grande. En este caso, “ubuntu.com” se puede decir que sea un subdominio de “com”. Normalmente, esto se acaba de llamar el dominio o la parte de “ubuntu” se llama un SLD, lo que significa dominio de segundo nivel.
Del mismo modo, cada dominio puede controlar “subdominios” que se encuentran debajo de ella. Esto es por lo general lo que entendemos por subdominios. Por ejemplo, podría tener un subdominio para el departamento de informática de nuestra escuela, en “www.informatica.iescamp.es”. La “informática” es parte de un subdominio.
La diferencia entre un nombre de host y un subdominio es que un anfitrión define un ordenador o de recursos, mientras que un subdominio se extiende al dominio principal, en relaciones es como si habláramos de un hijo del dominio. Es un método de subdividir el propio dominio.
Ya sea hablando de subdominios o hosts, puede comenzar a ver que a la izquierda-la mayoría de las partes de un dominio son los más específicos. Así es como funciona DNS: de más a menos.
Un nombre de dominio completo, a menudo llamado FQDN, es lo que llamamos un nombre de dominio absoluto. Los dominios en el sistema de DNS se pueden dar respecto a los otros, y como tal, pueden ser algo ambiguo. 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 se especifica cada dominio principal que incluye el dominio de nivel superior. Un FQDN adecuado termina con un punto, lo que indica la raíz de la jerarquía 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 el punto de salida para ajustarse a las normas de la ICANN.
Un servidor de nombres es un equipo designado para traducir los nombres de dominio en direcciones IP. Estos servidores realizan la mayor parte del trabajo en el sistema DNS. Dado que el número total de traducciones de dominio es demasiado para cualquier servidor, cada servidor puede redirigir la solicitud a otros servidores de nombres o delegar la responsabilidad de un subconjunto de los subdominios que son responsables.
Los servidores de nombres pueden ser “autoritarios”, lo que significa que dan respuestas a las preguntas acerca de los 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.
Un archivo de zona es un simple archivo de texto que contiene las asignaciones entre nombres de dominio y direcciones IP. Así es como el sistema DNS finalmente se entera de que la dirección IP debe ser contactado cuando un usuario solicita un determinado nombre de dominio.
Los archivos de zona residen en los servidores de nombres y, en general definen los recursos disponibles en un dominio específico, o el lugar que uno puede ir a conseguir esa información.
Dentro de un archivo de zona, se están 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.
Ahora que estamos familiarizados con algunos de los términos involucrados con el DNS, ¿cómo funciona el sistema realmente?
El sistema es muy simple en el nivel alto, pero es muy complejo a medida que profundizamos en los detalles, bajamos de nivel. En general, se trata de una infraestructura muy fiable que ha sido esencial para la adopción de la Internet como la conocemos hoy en día.
Como dijimos anteriormente, el DNS es, en su esencia, un sistema jerárquico. En la parte superior de este sistema es lo que se conoce como “servidores raíz”. Estos servidores son controlados por varias organizaciones y se delegan autoridad por la ICANN (Corporación de Internet para Nombres y Números Asignados).
En este momento hay 13 servidores raíz en funcionamiento. Sin embargo, ya que hay un número increíble de nombres para resolver cada minuto, cada uno de estos servidores es realmente reflejado. Cuando las solicitudes se hacen para un determinado servidor raíz, la solicitud se dirigirá a la réplica más cercana de ese servidor raíz.
¿Qué hacen estos servidores raíz? Los servidores raíz manejan las solicitudes de información acerca de los dominios de nivel superior. Así que si llega una petición para algo un servidor de nombres de nivel inferior no puede resolver, se realiza una consulta al servidor raíz para el dominio.
Los servidores raíz realmente no saben dónde se encuentra alojado el dominio. Ellos, sin embargo, son capaces de dirigir al solicitante a los servidores de nombres que manejan el dominio de nivel superior específicamente solicitado.
Así que si se hace una solicitud de “www.wikipedia.org” al servidor raíz, el servidor raíz le dirá que no ha podido encontrar el resultado en sus registros. Comprobará sus archivos de zona para obtener una lista que coincida con “www.wikipedia.org”…
Buscaría si no encuentra un registro para el dominio de nivel superior “org” y daría a la entidad que solicita la dirección del servidor de nombres de responsables de direcciones “org”.
El solicitante envía una nueva solicitud a la dirección IP (que se le da por el servidor raíz) que es el responsable del dominio de nivel superior de la solicitud.
Así que, para seguir nuestro ejemplo, sería enviar una solicitud al servidor de nombres responsable de conocer acerca de los dominios “org” para ver si se sabe dónde se encuentra “www.wikipedia.org”.
Una vez más, el solicitante buscará “www.wikipdia.org” en sus archivos de zona. No va a encontrar este registro en sus archivos.
Sin embargo, encontrará una lista de registro de la dirección IP del servidor responsable de “wikipedia.org”.
Servidores de nombres de dominio de nivel
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. Se envía una nueva solicitud al servidor de nombres que pide, una vez más, si se puede resolver “www.wikipedia.org”.
El servidor de nombres comprueba sus archivos de zona y se considera que tiene un archivo de zona asociada con “wikipedia.org”. Dentro de este archivo, hay un registro para el host “www”. Este registro le dice la dirección IP donde se encuentra este alojamiento. El servidor de nombres devuelve la respuesta final al solicitante.
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 una “resolución de servidor de nombres” Un servidor de resolución de nombres está configurado para preguntar a otros servidores. Se trata básicamente de un intermediario para un usuario que almacena en caché los resultados de consultas anteriores para mejorar la velocidad y conoce las direcciones de los servidores raíz para poder “resolver” las solicitudes formuladas por las cosas que aún no conocemos.
Básicamente, un usuario por lo general tiene un par de servidores de nombres configurador para resolver en su sistema informático. Los servidores de nombres son generalmente instalados por un proveedor de Internet o de otras organizaciones. Por ejemplo Google proporciona la resolución de los servidores DNS que se pueden consultar. Éstos se pueden configurar ya sea en su ordenador de forma automática o manual.
Cuando escribe una dirección URL en la barra de direcciones de su navegador, el ordenador busca primero para ver si puede encontrar a nivel local donde se encuentra el recurso. Se comprueba el archivo “hosts” en el equipo y algunos otros lugares. Posteriormente, envía la petición al servidor de resolución de nombres y espera volver a recibir la dirección IP del recurso.
El servidor de resolución de nombres a continuación, comprueba su caché para la respuesta. Si no lo encuentra, va a través de los pasos descritos anteriormente.
Resolución de servidores de nombres, básicamente, comprimen el proceso solicitante para el usuario final. Los clientes simplemente tienen que saber preguntar a los servidores de nombres donde se encuentra un recurso.
Hemos mencionado en el proceso someramente la idea de los “archivos de zona” y “registros”.
Los archivos de zona son la forma en que los servidores de nombres almacenan información acerca de los dominios que se conocen. Cada dominio que un servidor de nombres sabe se almacena en un archivo de zona. La mayoría de las peticiones que llegan al servidor de media no son algo que el servidor tendrá para los archivos de esa zona.
Si se configura para manejar consultas recursivas, como un servidor de resolución de nombres, encontrará la respuesta y lo devuelve. De lo contrario, le dirá a la parte solicitante dónde buscar siguiente.
Un archivo de zona describe una “zona” DNS, que es básicamente un subconjunto de la totalidad del sistema de nombres DNS. En general, se utiliza para configurar sólo un único dominio. Puede contener un número de registros que definen donde están os recursos para el dominio en cuestión.
De la zona de $ ORIGIN es un parámetro igual al nivel más alto de la zona de la autoridad de forma predeterminada.
Así que si un archivo de zona se utiliza para configurar el “example.com”. , el $ ORIGIN se establecería en example.com. .
Esto se configura ya sea en la parte superior del archivo de zona o puede ser definido en el archivo de configuración del servidor DNS que hace referencia al archivo de zona. De cualquier manera, este parámetro se describe lo que la zona va a ser autorizado para.
Del mismo modo, el $ TTL configura el “tiempo de vida” de la información que proporciona. Se trata básicamente de un temporizador. Un servidor de nombres caché puede utilizar los resultados previamente consultadas a responder a las preguntas hasta que el valor TTL se agote.
Dentro del archivo de zona, podemos tener muchos tipos de registro diferentes. Vamos a repasar algunos de los (tipos u obligatorias) más comunes aquí.
El inicio de autoridad, o SOA, es un registro obligatorio de todos los archivos de zona. Debe ser el primer registro real en un archivo (aunque $ ORIGIN o $ TTL pueden aparecer más arriba). Es también uno de los más complejos de entender.
El inicio del registro de autoridad se ve algo como esto:
Vamos a explicar lo que cada parte es para:
domain.com.: Esta es la raíz de la zona. Especifica que el archivo de zona es para domain.com. Dominio.
A menudo, podemos ver este reemplazado por @, que es sólo un marcador de posición que sustituye el contenido del $ ORIGIN variables nos enteramos de arriba.
EN SOA: La parte “IN” significa Internet (y estará presente en muchos registros). El SOA es el indicador de que se trata de un registro de inicio de autoridad.
ns1.domain.com.: Esto define el servidor de nombres maestro primario para este dominio. Los servidores de nombres pueden ser tanto maestro o esclavos, y si se ha configurado un servidor DNS dinámico tiene que ser un “maestro primario”, que va aquí. Si no ha configurado DNS dinámico, entonces este es sólo uno de sus servidores de nombres maestro.
admin.domain.com.: Esta es la dirección de correo electrónico del administrador para esta zona. La “@” se sustituye 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 en ella, esto se reemplace con un “\” en esta parte (your.name@domain.com se convierte en su \ name.domain.com).
12083: Este es el número de serie del archivo de zona. Cada vez que se edita un archivo de zona, debe incrementar este número para el archivo de zona para propagarse correctamente. Los servidores esclavos verificarán si el número de serie del servidor maestro para una zona es más grande que la que tienen en su sistema. Si lo es, se pide al nuevo archivo de zona, si no, continúa sirviendo el archivo original.
3h: Este es el intervalo de actualización de la zona. Esta es la cantidad de tiempo que el esclavo esperará antes de la solicitud de actualización al maestro para cambios en los archivos de zona.
30m: Este es el intervalo de reintento para esta zona. Si el esclavo no puede conectar con el maestro cuando el período de actualización se ha terminado, se va a esperar esta cantidad de tiempo y vuelva a intentar sondear el maestro.
3w: Este es el período de caducidad. Si un servidor de nombres esclavo no ha sido capaz de ponerse en contacto con el maestro para esta cantidad 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 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 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 la siguiente:
Así que ya que nuestro registro SOA llamó un servidor maestro primario en “ns1.domain.com”, habría que asignar esta 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 ser algo como esto:
Tenga en cuenta que nosotros no tenemos que dar el nombre completo. Sólo podemos dar el anfitrión, sin el nombre completo y el servidor DNS a rellenar el resto con el valor $ ORIGIN. Sin embargo, podríamos tan fácilmente utilizar todo el FQDN si nos sentimos mejor con esta semántica:
En la mayoría de los casos, este es el lugar donde se define el servidor web como “www”:
También hay que decir que resuelve el dominio base. Podemos hacer esto de esta manera:
Podríamos haber utilizado el “@” para referirse a la base en lugar de dominio:
También tenemos la opción de resolver cualquier cosa bajo este dominio que no está definido de forma explícita a este servidor también. Podemos hacer esto con el “*” comodín:
Todos ellos funcionan igual de bien con registros AAAA para direcciones IPv6.
Registros CNAME definir un alias de nombre canónico para el servidor (que se define por una A o registro AAAA).
Por ejemplo, podríamos tener un registro de un nombre que define el host “server1” y luego usar el “www” como un alias para este host:
Tenga en cuenta que estos alias vienen con algunas pérdidas de rendimiento debido a que requieren una consulta adicional con el servidor. La mayoría de las veces, el mismo resultado se puede lograr mediante el uso de registros adicionales A o AAAA.
Un caso en el que se recomienda un CNAME es proporcionar un alias para un recurso fuera de la zona actual.
Registros MX se utilizan para definir los intercambios de correo que se utilizan para el dominio. Esto ayuda a los mensajes de correo electrónico llegar a su servidor de correo correctamente.
A diferencia de muchos otros tipos de registros, los registros de correo generalmente no asignan una gran cantidad de algo, porque se aplican a toda la zona. Por lo general se ven así:
Tenga en cuenta que no hay ningún nombre de host en el comienzo.
También tenga en cuenta que hay un número extra allí. Este es el número de preferencia que ayuda a los ordenadores decidir qué servidor se utiliza para enviar el correo si hay varios servidores de correo definidos. Los números más bajos tienen una prioridad más alta.
El registro MX en general, debe apuntar a una serie definida por una A o AAAA registro, y no uno definido por un CNAME.
Así que, vamos a decir que tenemos dos servidores de correo. Tendría que haber registros que se ven algo como esto:
En este ejemplo, el anfitrión “mail1” es el servidor de intercambio de correo electrónico preferido.
También podríamos escribir que de esta manera:
Usted se estará preguntando, “si el archivo de la zona reside en el servidor de nombres, ¿por qué necesita hacer referencia a sí mismo?”. Parte de lo que hace que el DNS tenga tanto éxito es sus múltiples niveles de almacenamiento en caché. Una de las razones para la definición de los servidores de nombres en el archivo de la zona es que el archivo de zona puede ser que en realidad se sirva a partir de una copia en caché en otro servidor de nombres. Hay otras razones para necesitar los servidores de nombres definidos en el propio servidor de nombres, pero no vamos a entrar en eso aquí.
Al igual que los registros MX, estos son los parámetros de la zona, por lo que no se toman anfitriones tampoco. En general, se ven así:
Usted debe tener al menos dos servidores de nombres definidos en cada archivo de zona con el fin de funcionar correctamente si hay un problema con un servidor. La mayoría del software de servidor DNS considera un archivo de zona para ser inválida si sólo hay un único servidor de nombres.
Como siempre, incluir la asignación para los anfitriones con los registros A o AAAA:
Hay algunos otros tipos de registro que puede utilizar, pero estos son probablemente los tipos más comunes que se encontrará.
Podemos tener una buena comprensión de cómo funciona DNS.
Si bien la idea general es relativamente fácil de entender una vez que estás familiarizado con la semántica, esto sigue siendo algo que puede ser difícil para los administradores sin experiencia.

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

Resolución 
 resolución