Lo que voy a contar hoy es algo de "cultura general", pero también es cierto que muchas personas lo desconocen todavía, sobre todo si están comenzando en el mundo de la programación web.
Empezaré repasando cómo es el funcionamiento básico desde el momento en el que escribimos una dirección web en un navegador y hasta que empieza a solicitarse la página de verdad, y luego explicaré un sencillo proceso que te permite simular que cualquier dominio de internet, exista o no, está en cualquier servidor que tu quieras. Por ejemplo, si te interesara por el motivo que fuese, podrías hacer que cuando escribas en un navegador www.google.com en vez de ir a Google vaya a, por ejemplo, una página de prueba en tu servidor local de desarrollo.
Quizá lo de Google no sea muy útil, claro, pero sí que puede resultar de gran ayuda para poder probar de la manera más realista posible una web o aplicación, utilizando para el desarrollo o las pruebas no solo el mismo código, incluso el mismo dominio que usaríamos en la realidad.
Por ejemplo, vamos a suponer que tenemos una aplicación web funcionando en el dominio misuperapp.com y que en nuestra máquina local queremos seguir trabajando en ella para aumentar sus características, y utilizar directamente ese dominio en lugar de localhost o 127.0.0.1 (que es siempre la dirección de la máquina actual).
Cómo funciona la resolución de nombres de dominio
No quiero extenderme demasiado con esto, porque además da para mucho, pero es importante que cualquiera que se dedique a la programación (y no solo a la programación Web) conozca el funcionamiento básico de Internet. Así que ahí va una pequeña explicación...
Cada máquina conectada a Internet dispone de una o varias direcciones IP asignadas que la identifican de manera única. Estas direcciones pueden ser de dos tipos IPv4 o IPv6. Las direcciones IPv4 son cuatro numeritos entre 0 y 255 separados por puntos y son las más comunes. Cuando se empezaron a usar hace unas décadas parecía suficientes para que duraran siempre. Sin embargo hay tantas máquinas conectadas a Internet que empiezan a escasear y es uno de los motivos de que hace tiempo se diseñasen las direcciones IPv6, que son una cadena larga e ininteligible que designa de manera única también a un dispositivo conectado a Internet.
De este modo, a través de su dirección IP, es posible encontrar cualquier dispositivo que esté conectado a la Red de redes.
Cuando un usuario abre su navegador y escribe la dirección de una web o aplicación, lo que ocurre por debajo es que el nombre de dominio (por ejemplo misuperapp.com) se transforma en la dirección IP del servidor encargado de servir las páginas web correspondientes a esa web o aplicación. De este modo el navegador sabe a qué servidor debe conectarse y solicitarle la página.
¿Cómo se sabe cuál es esa dirección IP? Gracias a un protocolo específico que se llama DNS (Domain Name System, Sistema de Nombres de Dominio). Un servidor DNS es un dispositivo especial conectado a Internet y que es responsable de almacenar un base de datos de parejas "dominio / IP" de modo que sabe encontrar uno a partir del otro y viceversa. De este modo si buscas un dominio te sabe decir su IP y si buscas una IP te sabe decir qué dominio o dominios tiene asociados.
Nota: en realidad a un dominio o subdominio se le pueden asignar muchos más registros que el que devuelve su dirección IP, y se utiliza también para crear alias entre dominios, entradas para saber cómo enviar y recibir correo electrónico, datos textuales de diversa utilidad (como la validación de dominios ante terceros o firma digital de correo), y muchas cosas más. Pero a os efectos de lo que quiero explicar hoy, lo anterior es suficiente.
La resolución de nombres con DNS es jerárquica. Existen unos servidores DNS raíz que contienen una base de datos con todos los dominios de primer nivel (TLD: Top Level Domain) del mundo y los servidors DNS que son a su vez responsables de las entradas para cada uno de ellos.
Tu operador de acceso a Internet también dispone de unos servidores DNS que se encargan de intermediar entre tu máquina y la jerarquía de servidores DNS para averiguar la dirección IP final al a que debes conectarte. Esto es algo a lo que no se le da mucha importancia habitualmente, pero que es crítica por varios motivos:
- Si el servidor DNS de tu proveedor fuese hackeado podrían hacer que, por ejemplo, al introducir la dirección de tu banco fueses a parar al servidor de un ladrón que simula ser tu banco, y no podrías enterarte.
- La resolución de nombres puede llevar bastante tiempo, por lo que si el servidor DNS de tu proveedor es lento esto lo acabarás notando en la velocidad aparente de conexión que tienes a la web.
- El que controla tu servidor DNS controla también exactamente a qué sitios web te conectas, y esto es información muy valiosa.
De hecho muchas empresas, como por ejemplo Google, ofrecen servidores DNS para que puedas utilizarlos en lugar de los que te da tu proveedor de Internet, ofreciéndote más velocidad, más seguridad o ambas cosas. Lo que seguro que no te ofrece Google es más privacidad, así que aunque son muy rápidos igual no son los más recomendables (aunque si ya usas Chrome poco te importará que sepan a dónde te conectas ¿verdad?)
Yo personalmente uso los servidores DNS de Cloudflare (1.1.1.1) porque son muy rápidos, son seguros y sé que Cloudflare no va a guardar ni utilizar mi información.
En resumen, cuando escribes una dirección en tu navegador lo que ocurre es esto:
- Se consulta el servidor DNS de tu proveedor.
- Este consulta a uno de los servidores raíz para averiguar cuáles son los servidores DNS responsables para tu dominio de primer nivel (.es, .com, etc...).
- Se consultan esos servidores para averiguar qué dirección IP le corresponde a tu navegador.
- Devuelve a tu sistema operativo (y éste a tu navegador) la dirección IP a la que debe conectarse.
Y todo esto sin que los usuarios lo veamos.
Nota: esto sería así sólo cuando se pida ese dominio por primera vez. Si ya lo ha pedido alguien antes lo más probable es que lo tengan en caché (ya que no cambian a menudo) y que te lo devuelva inmediatamente sin más consultas. Por eso cuando cambias la IP asociada a un dominio éste tarda en "propagarse": mientras todos los servidores DNS que ya lo habían anotado no borren sus cachés no se verá la nueva IP en todo el mundo. Esa caché puede durar desde unos minutos hasta varias horas.
Se puede ver esta información con una utilidad de línea de comandos llamada nslookup. Por ejemplo, estas son las IPs asociadas al dominio del buscador de Google:
Como vemos tiene dos direcciones asociadas, una IPv6 (2a00:1450:4003:801::2004) y la otra IPv4 (172.217.17.4). Poríamos usarlas directamente para conectarnos a ese dominio.
Por cierto, ese "Server" que aparece al principio es el servidor DNS que se está utilizando para la consulta inicial, que en tu caso probablemente sea el de tu proveedor de acceso a Internet y en mi caso, como decía, es el servidor DNS de Cloudflare.
También podemos ver cuáles son los servidores de dominio (DNS) que se encargan de devolver las entradas DNS de ese dominio (recuerda: no solo tenemos IPs en esas bases de datos asociadas a un dominio). En el caso de Google son:
En este caso vemos que el principal es ns1.google.com y que indica que se debe conservar en caché la resolución durante un minuto (default TTL).
El archivo hosts: la excepción en la resolución de DNS
Todo lo anterior es "cultura general", ya digo, pero conviene saberlo.
Ahora bien, existe una excepción a todo lo que he explicado antes: el archivo hosts.
Se trata de un archivo de texto sin extensión que existe en todos los sistemas operativos de escritorio y que permite especificar parejas de dominio / IP cuya relación queremos forzar. Este archivo se consulta antes de hacer cualquier consulta al servidor DNS real como acabamos de ver.
Por lo tanto, si introduces cualquier relación entre dominio y dirección en este archivo podrás hacer que el dominio apunte a donde quieras a los efectos de tu máquina. Es como "hackear" el servicio DNS pero haciéndolo para ti mismo.
El archivo hosts en Windows está ubicado en la carpeta C:\Windows\System32\drivers\etc:
Para poder escribir en él debes hacerlo con permisos de administrador. Así que abre por ejemplo el bloc de notas como administrador y navega hasta esa carpeta para abrirlo. Tendrás que mostrar todos los archivos en el selector del bloc de notas:
Al abrirlo generalmente estará vacío y verás unas instrucciones sobre cómo utilizarlo:
Ahora, volviendo a nuestro ejemplo inicial, vamos a asociar el dominio misuperapp.com a la máquina local:
Como ves solo hay que poner la dirección IP (en este caso la local), un tabulador y el nombre de dominio (no te olvides de las www si lo necesita).
A partir del momento en que grabes los cambios, si vas a un navegador cualquiera e intentas acceder al dominio, te responderá el servidor local (que obviamente tiene que tener asociado dicho dominio para poder responder. Eso o responder a cualquier dominio, cosa que pasa con muchos de desarrollo local como Fenix o Live Server, pero no con IIS).
Nota: los navegadores basados en Chromium (Chrome, Opera, Brave, Vivaldi...) hacen una caché propia de DNS. Por eso, es posible que si ya habías pedido anteriormente el dominio y es un dominio real, no pille los cambios ue acabas de hacer ni aunque entres en modo privado. Debes borrar el histórico de navegación o esperar el tiempo que considere Chrome para ver el cambio reflejado. Si el dominio no existe no hay problema.
De hecho, y este es un truco poco conocido, puedes forzar la descarga de la caché de DNS de Google para un determinado dominio utilizando esta página especial de la propia empresa, para cuando te urja que los usuarios de Chomium (la mayoria) vacíen sus cachés de tu dominio cuanto antes.
Como ves es algo muy sencillo de hacer, y siento el "rollo" previo que te he contado, pero creo que conocer estos detalles del funcionamiento de la Red es indispensable para los desarrolladores y por eso me gusta divulgarlo.
¡Espero que te resulte útil!
💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor
