Servidores recursivos y no recursivos.

Los servidores de nombres pueden actuar recursivamente o no permitirla. Si un servidor no recursivo tiene la respuesta a una petición cacheada de una transacción previa o es el autorizado del dominio al cual la consulta pertenece, entonces proporciona la respuesta apropiada. De otro modo, en lugar de devolver una contestación real, devuelve una referencia al servidor autorizado de otro dominio que sea más capaz de saber la respuesta. 

Un cliente de un servidor no recursivo debe estar preparado para aceptar referencias y actuar en consecuencia.

Aunque los servidores no recursivos puedan parecer perezosos, tienen habitualmente un buen motivo para deshacerse del trabajo extra. Los servidores raíz y los servidores de más alto nivel son todos no recursivos, pero es que 10.000 consultas por segundo bien son una excusa para serlo.

Un servidor recursivo devuelve únicamente respuestas reales o mensajes de error. Se encarga de seguir las referencias por si mismo, descargando al cliente de esa tarea. El procedimiento básico para traducir una consulta es, esencialmente, el mismo; la única diferencia es que el servidor de nombres se preocupa de de hacerse cargo de las referencias en lugar de devolverlas al cliente.

Localización de servicios

Un registro SRV especifica la localización de los servicios ofrecidos por un dominio. Por ejemplo, el registro SRV permite consultar un dominio remoto directamente y preguntarle por el nombre de su servidor FTP. Hasta ahora, en la mayoría de ocasiones, había que probar suerte. Para contactar el servidor FTP de un dominio remoto, uno esperaba que el administrador de sistemas de ese dominio hubiese seguido el estándar (el gusto mejor dicho) actual y tuviese un CNAME para ftp en su servidor de DNS.

Los registros SRV adquieren mucha importancia en este tipo de consultas y son realmente una mejor manera para los administradores de sistemas de trasladar servicios y controlar su uso. Sin embargo, deben ser solicitados y analizados explícitamente por los clientes, por lo que sus efectos se irán viendo gradualmente a medida que pase el tiempo. Los registros SRV se parecen a registros MX generalizados con campos que permiten al administrador local guiar y balancear la carga de las conexiones provenientes del mundo exterior. El formato es 

servicio.proto.nombre [ttl] IN SRV pri wt puerto destino

donde servicio es uno de los servicios definidos en la base de datos de números asignada por la IANA(14), proto puede ser tcp o udp, nombre es el dominio al cual el servicio hace referencia, pri es una prioridad al estilo de los registros MX, wt es el peso usado para balancear la carga entre diferentes servidores, puerto es el puerto en el cual el servicio escucha, y destino es el nombre de host del servidor en el cual se provee ese servicio. El registro A del destino habitualmente es devuelto de forma automática junto a la respuesta envíada a una consulta SRV. Un valor "0" para el parámetro wt significa que no se realiza ningún tipo especial de balanceo de carga. Un valor de "." para el destino significa que el servicio no se ejecuta en ese sitio.

En la zona linuxsilo.net del ejemplo, adaptado del RFC2052 (donde se define SRV), se tiene lo siguiente:

ftp.tcp SRV 0 0 21 ftp.linuxsilo.net.

ssh.tcp SRV 0 0 22 linuxsilo.net.

telnet.tcp SRV 0 0 23 linuxsilo.net.

smtp.tcp SRV 0 0 25 smtp.linuxsilo.net.

; 3/4 de las conexiones al principal, 1/4 al secundario

http.tcp SRV 0 3 80 linuxsilo.net.

http.tcp SRV 0 1 80 ns2.linuxsilo.net.

; para que funcionen tanto http://www.linuxsilo.net como

http://linuxsilo.net

http.tcp.www SRV 0 3 80 linuxsilo.net.

http.tcp.www SRV 0 1 80 ns2.linuxsilo.net.

; servidor principal en el puerto 443, secundario − en caso de fallo − en otra máquina y otro puerto

https.tcp SRV 1 0 443 linuxsilo.net.

https.tcp SRV 2 0 4443 ns2.linuxsilo.net.

https.tcp.www SRV 1 0 443 linuxsilo.net.

https.tcp.www SRV 2 0 443 ns2.linuxsilo.net.

pop3s.tcp SRV 0 0 995 pop3.linuxsilo.net.

*.tcp SRV 0 0 0 .

*.udp SRV 0 0 0 .