En algún momento existió la idea que era “buena práctica operacional” el configurar nombres de host “localhost” en todos los subdominios. La justificación habría sido que los sistemas que por error agregaran como sufijo de un nombre el “search list” de algún dominio existente, estos fueran respondidos con el número correcto.
Esta idea incluso fue parte del RFC1537 de IETF, el “Common DNS Data File Configuration Errors”, del año 1993. Sospechamos que no es la única parte donde se recomendó, quizás incluso vendría escrito por defecto en software de DNS autoritativo, porque solo 3 años después el RFC1912 ya lo desestimó como una mala idea, y sin embargo hasta hoy se sigue usando.
Lo importante es que ahora, casi 30 años después, está claro que no lo es. La recomendación actual es que esas respuestas siempre den el código “NXDOMAIN”, que es la que se obtiene al simplemente no configurar en ninguna parte una etiqueta localhost para los dominios en los servidores autoritativos.
Haciendo un análisis de cuán extendida está esta práctica, por ejemplo la zona .CL completa con más de medio millón de dominios, un 22% de estos sí tiene configurado un “localhost.dominio.cl” para direcciones IPv4 (registro A), y de ellos casi el 80% retorna 127.0.0.1.
IPv6 está mucho mejor, con un 1% de dominios con registro AAAA para localhost.dominio.cl, de los cuales un 83% retorna ::1.
Estos datos han mejorado un poco en el último tiempo. Un escaneo de .CL para los registros A de localhost daba 33% hace 3 años atrás, con un 85% entregando el valor 127.0.0.1. Pero por supuesto falta mucho tiempo para esperar que desaparezca por completo.
Las razones de que ahora sea una mala práctica son múltiples a esta altura, todas de igual importancia. Se está llegando a la conclusión que el uso del “search list” es cada vez menos recomendado. Cada software y sistema debe preocuparse de utilizar nombres de hosts “completamente calificados” (fully qualified), para evitar secuestros hostiles de respuesta.
Por otro lado, los nombres “localhost.” son respondidos primeramente por los stub resolvers en forma directa, y siempre la respuesta debería ser la dirección loopback; mientras que los resolvers deben responder “nombre no existe”, haciendo fallar en forma evidente las preguntas que salgan hacia el DNS público ( let-localhost-be-localhost )
Por último, hay cierta evidencia teórica de problemas de seguridad que podrían realizarse contra dominios que tienen un localhost apuntando al 127.0.0.1, en ambientes multiusuario, y aprovechando propiedades de envío de cookies en navegadores web.
En el fondo, si no tiene alguna razón de peso para configurar un nombre “localhost” dentro de sus dominios, es mejor no hacerlo. Y de paso, ya que estamos en eso, hay que preocuparse de eliminar cualquier registro de nombres de prueba que puedan estar apuntando a IPs que ya no estén bajo su control. Se hace habitual por ejemplo el hacer pruebas en VPS o servicios “cloud” externos y luego se suspende el servicio, pero nunca se borran los nombres de las zonas. El problema es que ahora puede haber un tercero reutilizando esas mismas IPs externas, pudiendo tener algún tipo de acceso privilegiado a través del nombre.
Estimados operadores de DNS y dueños de dominios: por favor eliminen todos los “localhost.dominio.cl” de sus zonas.
Next post: Persiguiendo un error DNSSEC
Previous post: El tamaño de los mensajes en DNS (“DNS Flag Day 2020”)