Nuestra empresa espera implementar y mantener su propio DNS público. Describo la actividad de implementación, pero no me confunde dónde registrar el nombre de dominio de mi empresa y cómo asignar mi DNS público. Por favor, alguien explique el flujo de tráfico.
Respuesta1
Solía trabajar para un registro de dominio y era parte de los grupos de trabajo de DNS del IETF, así que les daré una introducción.
El Sistema de Nombres de Dominio está diseñado en una jerarquía. Cuando busca los datos de un nombre de dominio, generalmente va hasta la parte superior y avanza hacia abajo.
En la parte superior está la raíz. Los servidores de nombres raíz son una serie de servidores repartidos por todo el mundo en los que cualquier pregunta siempre comenzará; a menos que los datos estén almacenados en caché, llegaremos a eso más adelante. Como usuario normal, no los verás en un nombre de dominio, pero están ahí.
Los siguientes son los dominios de nivel superior. Se dividen en dominios de nivel superior genéricos (como .com, .net o .movie) y dominios de nivel superior de código de país (como .us para EE. UU., .no para Noruega o .cn para China).
Después de eso están los Dominios de Segundo Nivel. Estos son los que normalmente compra como cliente final. Por ejemplo, si desea poseer example.com, vaya a un registrador, verifique si example.com está disponible y, de ser así, agréguelo al carrito y presione finalizar compra. Luego, hará que el registrador u otra empresa de alojamiento ejecute su DNS por usted, o configurará sus propios servidores DNS y hará que el registrador le delegue el dominio. Delegar significa que registrarán datos que dirán que sus servidores DNS son responsables de este dominio.
Una vez que sea propietario de su dominio, también podrá configurar dominios de tercer nivel o subdominios. Esto agrega otra jerarquía a los servidores DNS. También puede configurar nombres de host, que para el usuario promedio se verán exactamente iguales.
Entonces, echemos un vistazo a una búsqueda de DNS promedio.
Digamos que quieres ir awww.ejemplo.com. Lo primero que hará su servidor DNS es ir a los servidores raíz para buscar quién es responsable de .com. Su servidor DNS ya tiene las direcciones de los servidores raíz integradas, por lo que normalmente no es necesario buscarlas. En lugar de eso, buscamos la información de .com.
Usaré el programa "excavar" aquí, pero agradeceré el resultado para facilitar la lectura.
Primero, solicitamos los servidores de nombres (ns) para com. Esto lo preguntamos directamente desde el servidor a.root-servers.net que es uno de los servidores raíz del sistema DNS.
$ dig ns com. @a.root-servers.net.
El resultado es el siguiente (nuevamente, abreviado)
;; QUESTION SECTION:
;com. IN NS
;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
La SECCIÓN DE PREGUNTAS nos muestra lo que estamos pidiendo, en este caso los registros NS para com.
La SECCIÓN DE AUTORIDAD nos muestra que el servidor raíz no es responsable de .com, pero nos dice quién lo es. En este caso nos dice que a.gtld-servers.net es el responsable.
También nos brinda una SECCIÓN ADICIONAL que contiene registros de direcciones (A para IPv4 y AAAA para IPv6) para a.gtld-servers.net. Esta dirección se llama pegamento y no se considera una respuesta autorizada, pero es una pista que nos indica que esta es la dirección que figura en el sistema. Los registros adhesivos son necesarios cuando necesita una dirección IP de un servidor al que de otro modo solo puede acceder realizando una búsqueda de DNS, para la cual necesita la dirección IP del servidor de nombres. Es todo un poco recursivo.
De todos modos, sigamos buscando los servidores de nombres de example.com. Ahora, esto diferirá un poco de lo que le dirá el DNS del mundo real, pero este es un ejemplo, por lo que usaremos datos de ejemplo.
$ dig ns example.com. @192.5.6.30
Estamos pidiendo la dirección IP de a.gtld-servers.net que obtuvimos arriba. Tienen autoridad para el dominio .com y, por lo tanto, deberían poder decirnos qué servidores de nombres tiene example.com.
;; QUESTION SECTION:
;example.com. IN NS
;; AUTHORITY SECTION:
example.com. 172800 IN NS ns2.example.com.
example.com. 172800 IN NS ns1.example.com.
;; ADDITIONAL SECTION:
ns2.example.com. 172800 IN A 192.0.2.4
ns1.example.com. 172800 IN A 192.0.2.5
Ahora bien, he aquí por qué ese pegamento es importante. Dado que los servidores de nombres de example.com residen en example.com, son administrados por los servidores de nombres de example.com. Básicamente, se le indica que llame a Bob para pedirle el número de Bob, porque sólo Bob sabe cuál es el número de teléfono de Bob. El pegamento es una pista. Es posible que Bob haya cambiado de número, pero esto es lo que saben los servidores de nombres de .com.
Ahora que conocemos la dirección de los servidores de nombres de example.com, finalmente podemos solicitar el nombre de host.
$ dig a www.example.com. @192.0.2.4
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 300 IN A 192.0.2.10
Finalmente tenemos el registro de dirección delwww.ejemplo.comnombre de host. Observe que no hay ninguna SECCIÓN ADICIONAL aquí, porque no es necesaria dicha sección para esta consulta. Hacemos una pregunta sencilla y obtenemos una respuesta precisa de un servidor autorizado para el dominio.
Ahora bien, hacer todas estas búsquedas todo el tiempo es una pérdida de tiempo y recursos, por lo que lo que normalmente se hace es que su servidor DNS local actúe como un caché. ¿Notaste cómo se ven todos los registros DNS? Los campos en un registro DNS son los siguientes: Dominio, Tiempo de vida (TTL), Clase (en nuestro caso IN para Internet), Tipo (A para dirección, NS para servidor de nombres, etc.) y Datos (por ejemplo, una dirección IP para un Un expediente).
El TTL en el registro DNS es durante cuánto tiempo se permite que una caché almacene los datos. Los registros que se espera que no cambien, o que cambien sólo en muy raras ocasiones, tienen TTL largos. Por ejemplo, el TTL de 172800 segundos en los primeros registros que analizamos. Los registros que pueden actualizarse con poca antelación tienen TTL bajos, como el TTL de 300 segundos parawww.ejemplo.com.
Siempre que hacemos una búsqueda de DNS, no necesitamos ir hasta los servidores raíz si los datos que ya estamos buscando están almacenados en caché. Normalmente accedemos a dominios .com todo el tiempo, por lo que los datos casi siempre se almacenan en caché en nuestro servidor DNS local. Sin embargo, esto significa que cada vez que cambie los datos DNS, los cambios pueden tardar un tiempo en propagarse. En términos prácticos, esto significa que deberá cambiar los TTL con anticipación o decirle a su jefe que los cambios tardarán un tiempo en surtir efecto por completo.
Para registrar su dominio, normalmente deberá acudir a un registrador del dominio de nivel superior en el que desea registrarse. La mayoría de las empresas de alojamiento y registradores de dominios podrán registrar dominios en varios dominios de nivel superior diferentes, por lo que puedes elegir prácticamente cualquiera de ellos.
Los Registradores son revendedores del Registro. El Registro es la empresa u organización que realmente administra el dominio de nivel superior en cuestión, pero como usuario final, todo lo que tiene que tratar es el Registrador, o incluso simplemente su empresa de alojamiento.
La mayoría de los registradores tienen interfaces web que manejan muchos de los detalles técnicos de la delegación y los registros DNS, pero aun así comprender los fundamentos del DNS le hará la vida mucho más fácil incluso si confía en la interfaz web de su registrador.
Si desea obtener más información sobre DNS, y si trabaja en TI, realmente debería saber cómo funciona DNS porque es la fuente de muchos problemas potenciales, le recomendaría el libro DNS and Bind de O'Reilly. Es muy completo y te convertirá en un experto en DNS. Si desea ejecutar sus propios servidores DNS, le recomiendo que lea este libro. Cubre el software del servidor DNS Bind, pero los mismos principios se aplican a cualquier software de servidor DNS que exista.