Resumen

  • El diseño de RFC 2167 encaminaba nombres jerárquicos mediante áreas de autoridad y remisiones ascendentes o descendentes.
  • Si un objeto howard.md.us quedaba bajo va.us, podía estar almacenado y, aun así, ser invisible para la búsqueda prevista por el árbol.

¿Qué debería contestar va.us cuando recibe una pregunta por howard.md.us? No conoce esa porción de la jerarquía. RFC 2167 exige remitir la consulta hacia su área matriz, us o la raíz. La contestación correcta del servidor equivocado no es «no existe», sino «pregunte más arriba». Esa pequeña disciplina separa la competencia para contestar de la mera capacidad de devolver bytes.

El mismo RFC plantea una prueba más dura. Colóquese el objeto de howard.md.us en la base de va.us. Su presencia física no lo rescata: el árbol dirige la consulta hacia Maryland, no hacia Virginia. El texto lo llama dato mal ubicado e imposible de encontrar mediante ese árbol. Advierte también que alojar un objeto en una zona superior, menos específica, puede seguir permitiendo encontrarlo en muchos casos. El problema no es cualquier desviación de la hoja ideal, sino la discrepancia entre etiqueta y rama visitada.

En junio de 1997, Referral Whois versión 1.5 ofrecía una alternativa conceptual a sostener un único Whois central. Nombres de dominio y redes en notación CIDR tienen etiquetas de las que se puede deducir una posición jerárquica. Un nombre humano aislado no la tiene. La arquitectura distribuía datos por áreas y utilizaba su estructura para encaminar preguntas hacia el presunto mantenedor. La palabra «presunto» importa: la remisión localiza otro servicio, no verifica la identidad ni el derecho de la persona descrita.

El protocolo distingue la remisión punt, hacia un padre, de link, hacia un descendiente. El destino identifica servidor, puerto y área. Puede haber varios destinos y el cliente decide el orden; la siguiente estación puede devolver datos, error u otra remisión. Una búsqueda no jerárquica puede consultar un servidor de índices aparte. De ahí que una respuesta negativa sólo tenga sentido junto con el camino, el ámbito consultado y la colocación de los datos. Una ruta impecable no descubrirá el expediente que alguien archivó en un hermano.

Tampoco había un esquema universal de base de datos. Cada área podía definir clases y atributos propios, aunque el RFC aconsejaba compartir un núcleo para interoperar. Encontrar un campo de contacto no equivale a saber que dos custodios le dieron la misma semántica. La clase de remisiones almacena el área referida y la URL RWhois del siguiente destino; esos campos hacen posible el encaminamiento, no una auditoría del contenido.

Para cada área, exactamente un maestro registraba datos. Los servidores secundarios podían contestar con autoridad a partir de copias, pero no registrar. La sincronización completa o incremental utilizaba, entre otros datos, un número de serie SOA y tiempos de actualización y reintento; podía limitarse a determinadas clases o atributos. Esa autoridad describía el papel de la respuesta dentro del directorio, no la veracidad eterna del registro. Los guardians imponían condiciones para modificar o ver determinados objetos, con contraseña o PGP entre los métodos descritos. Autorizar a un editor no valida por sí solo sus afirmaciones.

RFC 2167 se publicó como Informational, sin pretender especificar un estándar de Internet. Es evidencia de un diseño, no de una consulta observada, una base instalada, una asignación válida ni el funcionamiento actual de WHOIS o RDAP. Su lección útil es concreta: antes de usar una ficha como prueba, hay que saber dónde debió residir, por qué ruta llegó, quién podía escribirla y qué fuente externa respalda lo que dice.

Fuentes y alcance

El mecanismo procede de RFC 2167, §§2.1–2.6 y 4, con estado confirmado en su ficha oficial. RFC 1714 es la versión sustituida; RFC 954 documenta el antecedente Whois. Ninguna fuente demuestra un caso real de registro perdido o una identidad certificada.