Resumen

  • El campo de precisión horizontal de LOC expresa el diámetro del círculo de error, no su radio ni una probabilidad estadística.
  • La representación admite coordenadas muy detalladas y, a la vez, una incertidumbre horizontal predeterminada de diez kilómetros de diámetro. No hay contradicción: son datos distintos.
  • Sustituir la ubicación de un host por la de su red cambia el alcance de la respuesta. Ni el TTL ni una firma DNSSEC convierten esa aproximación en una medición reciente.

Un error de lectura que agranda el territorio

Leer «diez kilómetros» no basta para saber qué zona se está describiendo. Si el número es un diámetro y la aplicación lo dibuja como radio, ya ha cambiado el significado. Si elimina el círculo y deja solo un punto, lo ha cambiado de otra manera: la incertidumbre deja de verse.

El RFC 1876, publicado en enero de 1996 como documento experimental, definió LOC para representar lugares de hosts, redes y subredes dentro del DNS. Su campo horizontal no decía «más o menos esta distancia». Decía diámetro del círculo de error. El campo vertical, por su parte, indicaba la extensión total del posible error vertical.

La precisión de la palabra importaba tanto como la del número. Para expresar una amplitud equivalente a cada lado del centro, había que distinguir la mitad de la extensión completa. Tampoco se asignaba una confianza estadística al círculo. Añadir un porcentaje de probabilidad habría sido inventar una propiedad que el formato no proporcionaba.

Esta historia no trata de cuántos servidores utilizaron LOC. Trata de una decisión de representación: conservar junto a un lugar las condiciones que impedían interpretarlo como certeza absoluta.

Una máquina pequeña en una zona grande

LOC distinguía SIZE de la precisión. SIZE era el diámetro de una esfera capaz de envolver la entidad descrita. No era un margen de error, la potencia del equipo ni el radio de una zona de servicio.

Un objeto pequeño puede estar mal localizado. Una entidad extensa puede tener un centro de referencia conocido con bastante detalle. Por eso, intercambiar sus dimensiones y la incertidumbre de su posición elimina información en lugar de simplificarla.

En la forma textual del registro, los valores opcionales tienen valores por defecto: un metro de tamaño, diez mil metros de precisión horizontal y diez metros de precisión vertical. El documento relaciona esa elección con la disponibilidad de posiciones aproximadas obtenidas a partir de códigos postales.

Así, un objeto de un metro y un círculo de error de diez kilómetros de diámetro pueden convivir sin incoherencia. Omitir las precisiones del archivo de zona no significa que falten en la versión binaria. El proceso incorpora sus valores predeterminados. La aplicación que conserva solo latitud y longitud descarta algo que sí estaba en la respuesta.

Distribuir el mantenimiento, no hacer el levantamiento

Antes de LOC, el RFC 1712 había propuesto GPOS en noviembre de 1994, también con carácter experimental. La idea era mantener la información geográfica localmente y consultarla mediante una infraestructura ya distribuida.

El problema histórico incluía el mantenimiento y la comprobación de mapas UUCP centralizados. El texto consideraba también sysLocation de SNMP, ligado a agentes y a descripciones locales, y las limitaciones de despliegue que entonces encontraba en X.500. No son observaciones que puedan trasladarse sin más a la Internet actual.

El DNS ofrecía una forma de repartir la responsabilidad editorial de cada dato. Quien administraba un nombre podía modificar su descripción geográfica. No necesitaba que una oficina central redibujara un mapa por él. Pero esa facilidad no otorgaba al administrador una capacidad de medición ni certificaba su conocimiento del terreno.

GPOS contenía tres cadenas numéricas imprimibles, no tres números binarios de coma flotante IEEE. La posibilidad de incluir muchas cifras no demostraba que cada una procediera de una observación fiable. Ese límite precedía a la elección del formato de LOC.

Los ejes también necesitaban una explicación

El texto de GPOS presenta un problema adicional: intercambia términos y definiciones de longitud y latitud. El erratum oficial 541, comunicado en 2006, señala el problema y propone corregir las etiquetas conservando el orden numérico.

Su estado es «Held for Document Update», no «Verified». Conviene respetar esa diferencia: la existencia de una propuesta de corrección no equivale a una especificación ya enmendada ni demuestra que todos los programas hayan resuelto la ambigüedad del mismo modo. Reutilizar sus ejemplos geográficos sin examinar esa historia sería una mala manera de enseñar el formato.

LOC llegó después, pero el RFC 1876 no declaró obsoleto el RFC 1712. El registro de parámetros DNS de IANA sigue identificando GPOS con el tipo 27 y LOC con el 29. La cronología de dos propuestas no debe convertirse por intuición en una historia de sustitución formal. El registro tampoco es un censo de uso.

Dieciséis octetos, varias unidades

La versión cero de LOC utiliza dieciséis octetos de RDATA. Son los datos del registro, no todo el registro ni todo el mensaje DNS. Versión, tamaño, precisión horizontal y precisión vertical ocupan un octeto cada uno. Latitud, longitud y altitud ocupan cuatro cada una.

La latitud y la longitud se expresan en milésimas de segundo de arco mediante enteros con desplazamiento. Dos elevado a treinta y uno representa el ecuador o el meridiano de origen; los valores superiores indican norte o este. No es simplemente el almacenamiento de ángulos positivos y negativos como enteros con signo.

Ese detalle permite distinguir números muy próximos. No demuestra que el lugar se haya medido con la misma resolución. Tampoco existe una conversión única de una variación de longitud a metros que sirva en cualquier latitud.

Tamaño y precisiones usan, dentro de un octeto, una cifra y un exponente decimal para expresar centímetros. Solo están definidos los valores de cero a nueve en cada mitad del octeto. La combinación cero por diez elevado a cero significa menos de un centímetro, no error matemáticamente nulo. El formato es compacto, no una promesa de exactitud ilimitada.

La forma textual introduce otra frontera: altitud, tamaño y precisiones se escriben en metros, mientras los campos correspondientes en la red usan centímetros. El lector debe respetar la representación en la que se encuentra. Confundirla puede alterar el lugar sin que el número resulte sintácticamente extraño.

La altura no empezaba en el mar

LOC tomó como referencia de altitud el elipsoide WGS84. Para codificarla, colocó el origen cien mil metros por debajo de esa superficie y contó en centímetros. Una altura de cero metros respecto al elipsoide corresponde, por tanto, a diez millones en el campo almacenado.

Ese desplazamiento permite representar alturas inferiores a la referencia sin convertirlas en enteros negativos. No añade cien kilómetros a la posición física. Tampoco convierte el nivel medio del mar en la misma superficie que el elipsoide.

El RFC acepta una aproximación basada en el nivel del mar con los ajustes apropiados en altitud o precisión vertical. Lo importante para esta historia es que hay una decisión sobre el punto de partida. Mostrar más decimales no subsana haber elegido un cero distinto del que supone el consumidor.

Una respuesta útil podía describir otra escala

La búsqueda también conservaba sus condiciones. Desde un nombre, había que consultar primero su LOC y seguir los CNAME de la manera habitual. Si faltaba un LOC directo, las direcciones A asociadas podían permitir una búsqueda de ubicación de red o subred. Desde una dirección IPv4, el primer paso era obtener un nombre mediante IN-ADDR.ARPA y buscar después el LOC de ese nombre.

El recurso opcional a una ubicación de red se apoyaba en el RFC 1101. Este método histórico organizaba nombres y máscaras con PTR y datos de forma A bajo determinados nombres inversos. Algunos de esos valores A eran máscaras de subred, no direcciones a las que conectarse.

La búsqueda de LOC reunía nombres y examinaba primero los más específicos, retrocediendo hacia ámbitos mayores. No era simplemente subir por los nombres padres del DNS ni aplicar la regla de encaminamiento de prefijo más largo de BGP. Tenía supuestos históricos de IPv4 y redes por clases; el RFC no definía una solución general equivalente para IPv6.

Encontrar el LOC de una red permitía mostrar una zona más amplia cuando faltaba un dato de host. No transformaba esa coordenada en una observación de la máquina. Con varias direcciones A, la aplicación podía escoger entre varias ubicaciones, usar algunas o combinarlas. El formato no eliminaba esa decisión.

Un mapa responsable debería conservar la identidad de lo que representa: consulta original, propietario del registro y carácter directo o aproximado del resultado. Sin esa distinción, un éxito de búsqueda se convierte indebidamente en un éxito de medición.

El reloj de la caché no era el del terreno

En el modelo de recursos del RFC 1035, TTL regula durante cuánto tiempo puede conservarse una respuesta en caché antes de consultar otra vez la fuente. No indica cuánto tiempo ha pasado desde que alguien verificó el lugar.

El RFC 4033, de marzo de 2005, distingue además la coherencia de caché de la vigencia de una firma DNSSEC. La firma aporta autenticación del origen e integridad de los datos. No acredita que la altura esté bien medida, que la referencia sea correcta o que el objeto siga allí.

La conclusión es una inferencia sobre los límites del mecanismo: un dato auténticamente publicado puede ser antiguo o estar mal interpretado. DNSSEC tampoco ofrece confidencialidad. Los avisos de GPOS sobre la publicidad del DNS y de LOC sobre riesgos físicos de posiciones muy precisas no quedan anulados por firmar la respuesta.

Las propuestas de visualizar traceroute o mapas de gestión eran usos posibles, no pruebas de que una coordenada registrada revelara el trayecto físico de los paquetes. Ni el documento ni esta reconstrucción aportan una medición de adopción, exactitud geográfica o ataques derivados de esos datos.