Resumen

  • La RFC 6761, de febrero de 2013, creó el registro de nombres de dominio de uso especial de la IANA y pidió que cada nueva especificación contestara siete preguntas sobre usuarios, aplicaciones, bibliotecas, servidores DNS, operadores y registradores.
  • La primera lista juntó reservas anteriores y zonas de búsqueda inversa para direcciones privadas. El comportamiento no es el mismo: localhost conduce al bucle local, invalid requiere una respuesta negativa y las zonas privadas pueden tener respuestas propias dentro de una red.
  • La RFC 8244 describió en 2017 las grietas del procedimiento: faltaba una coordinación formal entre IETF e ICANN, «uso técnico» no tenía un límite consensuado y terceros podían empezar a usar nombres sin pedir permiso. La fila del registro no certifica lo que hace un resolutor en producción.

El sello no contesta a la consulta

Un desarrollador introduce un nombre de prueba. La aplicación puede pasarlo a una biblioteca. Esta puede preguntar a un resolutor recursivo, que quizá acabe consultando un servidor autoritativo. En otro despacho, un registrador decide si permite comprar el nombre. La misma cadena de caracteres cruza varias autoridades técnicas. Inscribirla como especial no sincroniza por arte de magia sus respuestas.

La RFC 2606 había reservado en 1999 nombres para pruebas, documentación, fallos previstos y el equipo local. Aquella decisión evitaba que un ejemplo inventado acabara chocando con un dominio real. La RFC 6761 abordó en 2013 un asunto distinto: qué debe hacer cada clase de software con el nombre que ya está reservado. La distancia entre reservar una palabra y conseguir que un resolutor la reconozca es el argumento de esta historia.

El nuevo registro de la IANA arrancó con las reservas anteriores y con zonas inversas de direcciones privadas. Cada entrada remite al documento que define el trato correspondiente. La lista funciona como índice, no como una tabla de enrutamiento que un servidor consulte en cada petición. Esa diferencia explica por qué una designación pública puede coexistir con equipos configurados de manera desigual.

Siete preguntas antes de ocupar un nombre

La RFC 6761 fijó una puerta de entrada: una especificación mediante Standards Action de la IETF o aprobación del IESG. El texto debe delimitar los nombres afectados y responder a siete grupos de preguntas. ¿Los usuarios deben reconocerlos? ¿Las aplicaciones? ¿Las API y bibliotecas de resolución? ¿Los servidores DNS de caché? ¿Los autoritativos? ¿Qué debe saber quien opera un servidor? ¿Puede un registro o registrador aceptar solicitudes sobre ese nombre?

No son siete órdenes idénticas. Son siete lugares donde una decisión puede tener consecuencias. Para una zona inversa de direcciones privadas como 10.in-addr.arpa, la RFC indica que aplicaciones y bibliotecas deben tratar el nombre como cualquier otra consulta y enviarla al servidor de caché configurado. Ese servidor, por defecto, debe responder localmente y evitar una búsqueda pública; puede ofrecer una opción de configuración para una red privada con su propio servidor autoritativo. Si vemos salir una consulta de la aplicación, todavía no sabemos si el mecanismo funcionó: la responsabilidad principal está más adelante.

Con localhost cambia la situación. Las preguntas por direcciones deben terminar en el bucle local. Con invalid, la respuesta prevista es inmediatamente negativa. El mismo rótulo «uso especial» agrupa comportamientos y puntos de control diferentes. Comprobar solo si un nombre aparece en una lista no dice qué hizo la biblioteca. Probar solo un resolutor público tampoco dice cómo respondió una máquina que cortó la consulta antes de enviarla.

La lista actual de la IANA incluye, entre otros, localhost, invalid, local, onion, home.arpa y zonas inversas privadas. Sus referencias llevan a especificaciones distintas. Algunas excepciones siguen utilizando DNS; otras señalan un ámbito local o un contexto de aplicación específico. La RFC 6761 no redujo la categoría a dominios de nivel superior ni dispuso que todos abandonaran DNS. Lo común es la necesidad de explicar el comportamiento, no una receta única.

Un nombre viaja más que su significado

El problema aparece cuando una palabra usada dentro de una red sale de ella. Alguien copia un nombre interno en un correo. La persona que lo recibe prueba la misma cadena en otro entorno. Los bytes coinciden; el destino quizá no exista allí o apunte a otra cosa. La RFC 8244 examinó precisamente esa clase de ruptura entre el contexto de uso y la apariencia de un nombre global. La especialidad no está pegada a las letras como tinta indeleble.

En octubre de 2017, la RFC 8244 hizo inventario de los problemas surgidos alrededor del procedimiento. IETF e ICANN mantenían una relación de enlace, pero no un proceso formal para coordinar estas asignaciones. Tampoco había consenso explícito sobre el alcance del «uso técnico». Ambos organismos tenían un papel nominal en el espacio de nombres; ninguno podía impedir que un tercero usara una parte sin solicitar su visto bueno.

El documento también enumeró causas más prosaicas: un nombre local puede filtrarse, un uso informal puede chocar después con una asignación formal, y un desarrollador puede desconocer la vía existente o esperar que la petición sea rechazada. No atribuye una de esas causas a un despliegue concreto. Para hacerlo harían falta la configuración fechada y las trazas de consultas de ese sistema. El registro acredita qué se designó; esos registros operativos muestran qué ocurrió.

La ironía es precisa. La institución creó un casillero para impedir la ambigüedad y descubrió que cada casilla abría preguntas en siete oficinas distintas. La RFC 6761 obligó a formularlas antes de reservar. La RFC 8244 mostró que la oficina encargada de recibir nuevas reservas tampoco tenía todas las respuestas sobre coordinación y usos previos.