Servicio DNS

El protocolo DNS (Domain Name System, RFC 1034 y 1035) surge para evitar la complejidad que supone identificar a los equipos utilizando el direccionamiento de la capa de red, es decir, el direccionamiento IP, por ejemplo, en IPv4 tendríamos que recordar direcciones como 83.144.201.39, y aún peor en IPv6, donde los equipos se identifican con números como 2001:0db8:85a3:08d3:1319:8a2e:0370:7334.

Para resolver este problema en 1986 Paul Mockapetris creó el protocolo DNS, con el cual se crean direcciones de dominio (también llamadas URL o URI), que son cadenas de texto del estilo www.debian.org, a las cuales se les asocia una dirección IP como las anteriores, así los equipos de una red además de identificarse por un número, también se identificarán por un nombre, y el protocolo DNS será el encargado de pasar de uno a otro automáticamente, según se necesite. Lo habitual será usar el protocolo DNS para pasar de un nombre a un número, pues las personas recordarán los nombre de los equipos y no sus números, pero en determinadas circunstancias, también se necesitará lo contrario, es decir, pasar de un número a un nombre, y el DNS (DNS inverso) también se encargará de ello.

Evidentemente el servicio DNS es un gran avance, pero también puede generar problemas. Si nuestro servidor de nombres no está disponible, nuestro equipo no podrá acceder a los recursos de la red, a menos que conozcamos las IP, por lo que en la práctica la situación es que nos quedamos sin acceso a Internet. Hemos hecho del servidor de nombres un recurso crítico, por lo tanto, será conveniente disponer de más de un servidor de nombres para resistir el fallo de uno de ellos.

En un principio se hablaba de servidor DNS primario y secundario, pero hoy en día es común ver listas de tres, cuatro y más servidores DNS. Esta disposición lleva implícita una prioridad, de modo que todas las consultas se hacen al servidor primario y si este no está disponible, entonces pasan al secundario, y así sucesivamente. El problema de esto es que aunque el servidor primario no responda, todas las consultas se le harán a él, y solo pasado unos instantes sin recibir respuesta, se repetirá la consulta sobre el secundario, por lo que los tiempos de espera degradan bastante el rendimiento general del servicio, haciéndose inviable en caso de tener que recurrir a un servidor terciario o superior. Actualmente muchos sistemas operativos usan toda la lista de servidores DNS configurada, distribuyendo la carga de consultas entre todos ellos, consiguiéndose así la disminución de los tiempos de respuesta.

El crecimiento de las redes, y en consecuencia el crecimiento de número de consultas DNS, conducen a tres problemas:

1. Organización: Encontrar una entrada, en las cada vez más grandes bases de datos de nombres, se hace más lento, por lo que necesitamos un buen método para indexar y organizar los nombres.
2. Escalabilidad: Si cada host tiene acceso a nuestros servidores de nombres, la carga se vuelve muy alta. Necesitamos un método para repartir la carga entre varios servidores de nombres.
3. Administración: Con muchos registros de nombres en las bases de datos, se hace cada vez más difícil la administración. Es fundamental crear un método (conocido como delegar) que agilice esta tarea y evite problemas como que varios administradores actualicen los registros al mismo tiempo.

El software que implemente el protocolo DNS deberá resolver los tres problemas anteriores.