Résumé

  • LOC rapporte l’altitude à l’ellipsoïde WGS84 ; le niveau moyen de la mer n’est pas automatiquement la même référence.
  • Le format distingue dimensions de l’entité et incertitude de localisation. Son diamètre d’erreur horizontal par défaut atteint dix kilomètres, même si les coordonnées comportent beaucoup de chiffres.
  • Un résultat obtenu par repli vers un réseau reste une approximation de réseau. Ni sa durée de cache ni sa signature ne certifient la date ou la qualité d’une mesure physique.

Le zéro avait une adresse

Deux personnes peuvent annoncer la même altitude et parler de deux positions différentes. Il suffit que leur zéro ne soit pas le même. Le problème paraît relever de la cartographie ; il s’est aussi invité dans un format de données du DNS.

Publié en janvier 1996 à titre expérimental, le RFC 1876 définit l’enregistrement LOC. Son altitude se rapporte à l’ellipsoïde de référence WGS84. Pour la stocker, le format place son origine numérique cent mille mètres sous cette surface et compte en centimètres. Une altitude de zéro mètre par rapport à l’ellipsoïde s’écrit donc, dans ce champ binaire, dix millions de centimètres.

Ce décalage ne transporte évidemment pas l’équipement cent kilomètres plus haut. Il permet de représenter des valeurs sous la surface de référence avec un entier non négatif. Confondre nombre stocké et hauteur annoncée ferait d’une convention de codage une propriété du terrain.

Le document admet l’usage d’une approximation fondée sur le niveau de la mer, mais demande d’ajuster l’altitude ou la précision verticale en conséquence. Un ellipsoïde et le niveau moyen des mers ne sont pas interchangeables. Aucun nombre de décimales ne corrige un mauvais choix de référence.

Faire circuler une description locale

L’ambition était pourtant pratique. Certaines informations géographiques sur les sites circulaient dans les cartes UUCP. Leur entretien centralisé posait des problèmes de mise à jour et de vérification. Le DNS offrait une autre répartition du travail : chaque administrateur pouvait maintenir une description près du nom dont il avait la charge, et des applications pouvaient la consulter à distance.

Le RFC 1712, expérimental lui aussi, avait proposé GPOS en novembre 1994. Il examinait les limites des solutions disponibles à l’époque, dont les descriptions sysLocation de SNMP, souvent liées à un agent ou à un emplacement local, et une diffusion de X.500 alors insuffisante pour l’usage recherché. Ce sont des considérations historiques, pas un état des lieux de ces technologies aujourd’hui.

GPOS utilisait trois chaînes numériques imprimables. Ce choix pouvait conserver de nombreuses décimales, mais ne disait rien de l’instrument ayant produit la valeur. Le DNS distribuait une déclaration ; il n’effectuait pas le relevé.

Même le nom des axes demandait de l’attention. Le texte de 1994 intervertit certains termes et définitions de longitude et latitude. L’erratum officiel 541, signalé en 2006, propose de corriger les étiquettes en conservant l’ordre numérique. Son statut est « Held for Document Update », et non « Verified ». Il ne faut donc ni reproduire les exemples problématiques comme recette fiable ni prétendre que le texte normatif a déjà été corrigé pour tous les usages.

LOC ne constitue pas pour autant une abolition formelle de GPOS. Le RFC 1876 ne déclare pas le RFC 1712 obsolète. Le registre DNS d’IANA conserve GPOS sous le numéro 27 et LOC sous le numéro 29. Une inscription établit une identité de format, pas une mesure de sa diffusion.

La finesse du quadrillage et celle du savoir

La version zéro de LOC tient dans seize octets de RDATA, et non dans seize octets pour l’enregistrement DNS complet. Quatre octets indiquent séparément version, taille, précision horizontale et précision verticale. Trois champs de quatre octets portent latitude, longitude et altitude.

Les angles utilisent des millièmes de seconde d’arc. Ils sont codés avec un décalage : deux à la puissance trente et un représente l’équateur ou le méridien d’origine ; les valeurs supérieures vont vers le nord ou l’est. Ce n’est pas une simple copie de coordonnées signées dans des entiers ordinaires. Et une même variation de longitude n’a pas une longueur au sol constante à toutes les latitudes.

La résolution du codage signifie seulement que deux valeurs voisines peuvent être distinguées. Elle ne garantit pas que le producteur dispose d’une observation assez bonne pour choisir entre elles. LOC rend cette séparation visible grâce à d’autres champs, qu’un affichage peut malheureusement oublier.

SIZE est le diamètre d’une sphère qui englobe l’entité décrite. La précision horizontale est le diamètre d’un cercle d’erreur. La précision verticale exprime l’étendue totale de l’erreur verticale possible. Le premier champ décrit les dimensions de l’objet ; les deux autres décrivent l’incertitude de sa position. Un équipement minuscule peut être très mal localisé. Un réseau étendu peut avoir un centre de référence bien connu.

Les trois valeurs ne sont pas, telles quelles, des amplitudes « plus ou moins ». Passer d’un diamètre à un rayon exige de diviser par deux. Le document ne leur associe pas non plus de niveau de confiance statistique : un lecteur ne peut ajouter de lui-même une probabilité de présence dans le cercle.

Ce que l’omission écrivait quand même

Dans un fichier de zone, on exprime altitude, taille et précisions en mètres ; les champs binaires correspondants utilisent des centimètres. Les unités changent avec la représentation. Le passage du texte au réseau n’est pas une nouvelle mesure, mais une conversion.

La taille et les deux précisions sont facultatives dans la forme textuelle. Si elles manquent, les valeurs par défaut sont un mètre pour la taille, dix mille mètres pour la précision horizontale et dix mètres pour la précision verticale. Le RFC relie ce choix à la disponibilité de positions approximatives tirées de codes postaux.

Voilà une combinaison parfaitement cohérente : objet d’un mètre, cercle d’erreur de dix kilomètres de diamètre. La petite taille ne certifie pas la petite erreur. Et les valeurs omises dans le texte ne disparaissent pas des seize octets transmis : elles y entrent sous forme de valeurs par défaut.

Pour stocker taille et précisions dans un octet chacune, LOC emploie un chiffre de base et un exposant décimal, en centimètres. Les demi-octets ne définissent que les valeurs de zéro à neuf. Le cas zéro multiplié par dix puissance zéro signifie moins d’un centimètre, pas une exactitude infinie. Ce codage compact transporte une indication d’étendue ; il n’invente pas une capacité de mesure.

Le réseau n’était pas la machine

Le risque d’exagération ne se limite pas aux unités. Le protocole autorise une recherche qui change l’échelle de l’objet décrit.

Partant d’un nom, une application doit d’abord chercher son LOC et suivre les CNAME comme pour les autres types. À défaut de position directe, elle peut utiliser les adresses A associées pour rechercher une localisation du réseau ou du sous-réseau. Partant d’une adresse IPv4, elle commence par obtenir un nom via IN-ADDR.ARPA, puis cherche le LOC de ce nom. Cela ne revient pas à exiger un LOC directement sous chaque nom inversé d’adresse.

Le repli s’appuie sur le mécanisme historique de noms de réseaux du RFC 1101, publié en 1989. Dans des emplacements inversés particuliers, des PTR et des données de forme A permettent de retrouver noms et masques de sous-réseaux. Ces valeurs de forme A jouent ici le rôle de masques, pas celui d’adresses de service.

La procédure LOC rassemble les noms, puis cherche la localisation du plus spécifique vers les ensembles plus larges. Ce n’est ni une remontée banale des étiquettes parentes du DNS ni la sélection de route par plus long préfixe de BGP. Elle porte les hypothèses IPv4 et classful de son époque ; le texte n’en fait pas une méthode générale pour IPv6.

Le bénéfice est explicite : si la précision fine manque, une application peut encore montrer une zone plus large. Mais si elle conserve le même symbole ponctuel sans indiquer le repli, elle transforme une localisation de réseau en prétendue localisation de machine. Avec plusieurs adresses, elle dispose même de plusieurs choix possibles, dont la sélection ou la combinaison reste une décision d’application.

Trois horloges, aucune enquête sur place

Le RFC 1035 fournit le cadre des ressources DNS : nom propriétaire, type, classe, durée de cache et données. Le TTL indique quand il faudra consulter à nouveau la source plutôt que garder une copie en cache. Il ne date pas un relevé topographique.

Le RFC 4033, en mars 2005, distingue encore cette durée de cache de la période de validité d’une signature DNSSEC. Une signature protège l’authenticité de l’origine et l’intégrité des données. Elle ne mesure pas l’altitude, ne vérifie pas le choix du référentiel et n’ajoute pas de date d’observation physique au LOC.

L’inférence est limitée mais décisive : une valeur authentiquement publiée peut être ancienne ou mal interprétée. Renouveler une signature n’équivaut pas à déplacer un géomètre sur le terrain. Les usages de cartographie de traceroute proposés dans le RFC ne prouvent pas non plus qu’une coordonnée enregistrée décrit le chemin physique réellement suivi par un paquet.

Enfin, DNSSEC n’apporte pas de confidentialité. GPOS rappelait déjà le caractère public des informations placées dans le DNS ; LOC signalait le risque physique accru lié à une localisation très précise. Ces mises en garde ne documentent pas une attaque particulière. Elles imposent seulement de distinguer possibilité de publier et opportunité de divulguer.