Podcast: Descargar (52.7MB)
Hoy os traigo audio sobre DNS, ¿sabéis como funciona el DNS?, si escuchastéis el Podcast #8: El viaje de cargar una web empezamos hablando de la petición de DNS, fue una explicación bastante por encima, en el capítulo de hoy hoy vamos a profundizar sobre ese aspecto.
Espero que os guste y cualquier duda, sugerencia, queja o demás ya sabéis donde podéis comentar 😉
Transcripción
En el capítulo 8 de este mismo podcast os estuve contando qué pasos seguía la información desde que se le daba un click en el navegador hasta que la información volvía, pero fue una explicación muy rapidita y por encima para dar una idea global. Hoy vamos a empezar con eso y vamos a ir paso a paso, esto me va a llevar varios audios, pero es la gracia de esto.
Así que hoy vamos a empezar a explicar el funcionamiento de DNS, por cierto, mi nombre es Eduardo y esto es eduardocollado.com, bienvenidos.
—MUSICA—
El otro día comenzamos diciendo que cuando el navegador quiere abrir un dominio, por ejemplo www.google.com, no tiene ni idea de donde está eso y tiene que preguntar al DNS, así que hoy vamos a empezar explicando qué es eso del DNS.
DNS tiene una estructura en árbol, una jerarquía y está estructurado como tal, es una forma de organizar los servidores y servicios.
Por ejemplo tenemos el dominio com, el punto com, o también llamado tld de top level domain, vale, ahí agrupamos todos los hosts comerciales, al menos esa era su definición primigenia.
Luego tenemos las empresas, por ejemplo google, que como es una empresa comercial tendrá el subdominio google.com y esa empresa Google a su vez tendrá subdominios como images, scholar, etc… dando un dominio del tipo scholar.google.com y así para abajo hasta llegar al final de la rama más concreta.
A ese dominio concreto, el de antes, scholar.google.com también lo llamaremos FQDN o Fully Qualified Domain Name.
Los dominios principales son .com, .net, .org, .gov y por spupuesto .es, .pt, .mx, .ar, etc…
Estos dominios son los conocidos como dominios de primer nivel o gTLD (global Top Level Domain).
Y cada gTLD lo gestiona una autoridad, los .com sería IANA y los .es sería Red.es, así con todos los gTLDs y cada autoridad sería la que definiría el uso de TLDs de segundo o tercer nivel. Por ejemplo en España tendríamos los dominios .es que serían los de segundo nivel y los .com.es que serían de tercer nivel y todos estos los genionaría Red.es.
Ahora el control de los dominios lo puede delegar cada autoridad, por ejemplo IANA gestiona .com y google tiene delegado el subdominio google.com y es google quien puede asignar subdominios de mayor profundidad, así pues, podrán crear si quieren todos los dominios de tercer nivel que quieran, como calendar.google.com o mail.google.com.
Esto lo puede hacer cualquier persona u organización que tenga delegada la autoridad de un subdominio, por ejemplo eduardocollado.com y yo mismo podré crear todos los nodos que quiera pues tengo delegada la zona.
Ahora, la zona no es lo mismo que el dominio yo por ejemplo digo que puedo crear todos los nodos que quiera, pero si quisieran nodos de un nivel inferior podría delegárselos a alguien sin problemas y yo ya no podría gestionar esos nodos de ese subdominio.
Por ejemplo podría delegar correo.eduardocollado.com a otro y el nodo servidor1.correo.eduardocollado.com lo gestionaría otro, eso se puede hacer.
—MUSICA—
Vale, ya sabemos lo que es un dominio y lo que es una zona, pero todavía no tenemos ni idea ni sabemos como conseguir una dirección IP a partir de un nombre de dominio que es lo que ponemos en nuestro navegador.
El funcionamiento a muy grandes rasgos consiste en enterarse quien lleva el dominio y preguntarle a él, algo totalmente normal y tiene cierta lógica, así que vamos a ver cómo funciona este proceso.
Lo primero que hará nuestro ordenador cuando el navegador quiera visitar www.google.com es preguntarle al DNS local, al que tenga definido, que puede haber sido definido a mano por el DHCP . Le preguntará por www.google.com y lo normal es que nuestro DNS no reconozca www.google.com como una de las zonas en las que tiene autoridad, es decir de las que gestiona, pero sí sabrá a quien preguntarle por com e irá haciendo peticiones para conseguir resolver google.com y luego para conseguir resolver www.google.com.
Al final obtendremos la dirección del host www.google.com y se almacenará en la caché donde se borrará al finalizar el TTL (Time To Live) del dominio.
—MUSICA—
Ahora vamos a ver cómo configurar una zona de DNS que tengamos delegada, esto podéis hacerlo en vuestro Servidor de DNS que puede ser un bind9 o uno como el del panel de neodigit que es mucho más fácil.
Lo primero es entender que DNS no sólo es para darnos direcciones IP, también nos puede dar otro tipo de informaciones, como campos de texto para cualquier cosa que queramos, voy a contaros los tipos de entradas de DNS que hay.
Tipo A, las entradas de tipo A son las que nos dan una ip, por ejemplo xyz.eduardocollado.com quiero que apunte a la dirección IP 1.2.3.4, en ese caso usaremos una entrada de tipo A
Tipo AAAA, es lo mismo que una entrada de tipo A pero para IPv6, sin más.
Tipo CNAME, este tipo de entradas apuntan a un hostname que hay que resolver a su vez por DNS, por ejemplo podemos decir que entradacname.eduardocollado.com tiene una entrada CNAME a xyz.eduardocollado.com, así que al preguntar al DNS por entradacname.eduardocollado.com le dira que vaya a xyz.eduardocollado.com y en este punto volverá a preguntar al servidor de DNS por xyz.eduardocollado.com y entonces le dirá la dirección IP que será 1.2.3.4.
Esto parece muy absurdo y nada práctico pero pensar en un host con una IP que va a tener 200 entradas más y que esa IP es suceptible de cambiar, pues bien, en ese caso lo que haremos será configurar la primera como tipo A y las otras 199 como tipo CNAME apuntando a la primera, así si se cambia la IP del host sólo tendremos que cambiar una entrada, la primera de tipo A.
Las entradas CNAME tienen la restricción que no es posible apuntar a la entrada canónica, es decir a eduardocollado.com en mi caso.
Ahora las entradas MX, que vienen de Mail eXchanger, estas entradas indican el host donde se recibe el correo, son siempre hostnames, no direcciones IP, como si fuera un CNAME.
Un dominio puede tener varias entradas MX porque puede recibir el correo en varios frontales y a cada entrada MX se le asigna una prioridad para definir el orden de entrega.
En Neodigit por ejemplo usamos siempre dos frontales, dos entradas MX con la misma prioridad para balancear el servicio.
Las entradas NS indican el servidor de DNS del dominio, deberían de conicidir con los NameServers que podemos ver al hacer el whois al dominio, es lo suyo vamos.
Las entradas SPF (Sender Policy Framework) ofrecen una protección ya que indican los servidores de correo autorizados para enviar correos desde el dominio.
Por ejemplo una entrada de SPF que tenga «v=spf1 mx ptr ~all»
v= define la versión usada de SPF (versión 1).
mx autoriza a las máquinas con la IP de los registros MX.
ptr autoriza a las máquinas bajo el dominio midominio.com.
~all desautoriza a las máquinas que no encajen en lo autorizado explícitamente.
Aquí es importante decir que hay servicios viejos como los Plesk hasta la 12 creo recordar, hablo de memoria que no permiten entradas SPF y se utiliza una entrada TXT con este contenido
Ahora, las entras TXT sirven para meter texto, el que quieras, por ejemplo el del SPF cuando no hay posibilidad de añadir registros SPF.
Y ahora vamos a por las entradas de tipo SRV, que son los registros de servicio, en este tipo de entradas se define el hostname y el puerto y protocolo donde el servicio se ejecuta. Esto se utiliza mucho para servicios de VoIP, autoconfiguración de correo, etc..
—MUSICA—
Y ya nos quedaría contar que es eso del SOA y el TTL.
Empezamos con el SOA (Start of Authority), que es un tipo de entrada en la cual definimos el DNS principal para el dominio, luego el email del administrador, pero como en este tipo de entradas no se puede poner @ se pone admin.dominio.com en vez de admin@dominio.com, luego va el número de serie
—MUSICA—
Bueno, después de esta borrachera de tipos de entrada en nuestra zona DNS pasamos a hablar de la resolución inversa, que es una pregunta al revés.
Normalmente tenemos el hostname, por ejemplo www.google.com y el DNS nos da la dirección IP, pero a veces necesitamos conocer el hostname a través de la dirección IP, por ejemplo para validar correos.
Recibimos un correo de mail.correo.com y viene desde la IP 1.2.3.4, y si preguntamos al dominio correo.com vemos que mail.correo.com está en esa IP, perfecto, pero ¿qué pasa si preguntamos a la IP? ¿también nos dice que es mail.correo.com? esta doble comprobación se usa para evitar spam, bueno, es una de las comprobaciones básicas, al menos se comprueba que la IP tenga resolución inversa, al menos eso.
Para las resoluciones inversas se utiliza el dominio in-addr.arpa y se van agregando subdominios que se van delegandose teniendo la forma inversa de la IP, por eso se llaman así.
Por ejemplo, si tenemos la IP 1.2.3.4 la resolución inversa sería 4.3.2.1.in-addr.arpa, para que al tratar como un DNS se puede ir delegando para abajo, siguiendo el arbol.
Para consultar una resolución inversa lo podemos hacer con el comando dig -x y dirección IP.
—MUSICA—
Donde ya no vamos a meternos es en la configuración del servidor, del bind9 por nombrar sólo el más conocido, aunque hay otros programas para hacer esto mismo, es decir, servidores de dns.
Bueno, con esto ya habéis visto una breve introducción a lo que sería el servicio de DNS.
llegados a este punto nuestro navegador una vez pinchado en el enlace de la página web correspondiente ya sería capaz de saber la dirección IP del servidor donde se aloja esa página web.
En el caso de ser un e-mail en vez de una página web nuestra PC lo que haría sería enviar el e-mail a nuestro servidor de correo saliente y este servidor lo que haría sería consultar en el DNS cuál es la IP del servidor destino, y para ello miraría la entrada Mx que hemos comentado antes.
En el caso de la auto configuración de un cliente de correo lo que haría sería mirar una entrada de tipo SRV del dominio y éste le diría dónde encontrar la auto configuración para ese cliente de correo, este servicio es bastante popular y nosotros en Neodigit obviamente lo tenemos funcionando como no podría ser de otra forma.
—MUSICA—
Estupendo, ahora ya sabemos a qué dirección IP tenemos que dirigirnos para conseguir el contenido de la página web.
Para llegar a ese servidor lo primero que tenemos que saber es a quien tenemos que enviarle el paquete y lo haremos por defecto a nuestra puerta de enlace que suele ser el router de la red local.
Para saber cómo llegar al router de la red local utilizaremos el protocolo ARP, el cual nos va a proporcionar una forma de llegar a nuestro router vía ethernet, otras palabras nos va a dar la dirección MAC del router.
El funcionamiento de ARP realmente es muy sencillo y lo único que hace es preguntar por broadcast a todos los nodos de la red quién es el poseedor de la dirección IP que coincide con la puerta de enlace, en ese punto el router normalmente va a contestar con que es el y va a proporcionar cuál es su dirección MAC.
Una vez conocida la dirección MAC de la puerta de enlace lo único que hace es nuestro ordenador es enviarle a esa dirección MAC el primer paquete para ser encaminado al destino.