Codification de la localisation géographique pour le DNS

Statut de ce mémoire

Le présent mémoire définit un protocole expérimental pour la communauté de l'Internet. Le présent mémoire ne spécifie aucune sorte de norme de l'Internet. La discussion et les suggestions pour son amélioration sont bienvenues. La distribution du présent mémoire n'est soumise à aucune restriction.

Résumé

Le présent document définit le format d'un nouvel enregistrement de ressource (RR) pour le système des noms de domaines (DNS) et réserve un mnémonique et un code numérique de type DNS correspondant. Cette définition associe des transpositions de localisation géographique d'hôte en noms d'hôtes au sein d'un domaine. Les données indiquées dans le présent document sont fictives et ne reflètent pas nécessairement l'Internet réel.

(Corrigé conformément à l'errata n° 541 rapporté par Arthur Coleman, du 9 mars 2006)

1.   Introduction

La mise en rapport des numéros IP avec les localisations géographiques est un vieux problème. La disponibilité des informations de localisation géographique a des applications immédiates dans la gestion de réseau. De telles informations peuvent être utilisées pour compléter les données déjà fournies par des utilitaires tels que whois [Har85], traceroute [VJ89], et nslookup [UCB89]. L'utilité et les fonctionnalités de ces outils largement utilisés seraient grandement améliorées par la fourniture d'informations de localisation géographique fiables.

La façon idéale de gérer et entretenir une base de données d'informations comme la localisation géographique des hôtes de l'Internet, est de déléguer la responsabilité aux administrateurs de domaine locaux. Une grande base de données répartie pourrait être mise en œuvre avec un mécanisme simple de mise à jour des informations locales. Un mécanisme d'interrogation doit aussi être disponible pour vérifier les entrées locales, ainsi que pou enquêter sur les données provenant de domaines non locaux.

2.   Fondements

L'Internet continue de croître à un taux toujours croissant avec des numéros IP alloués sur la base du premier arrivé, premier servi. Un certain nombre d'options s'offrent pour décider quand et comment établir une base de données d'informations géographiques sur les hôtes de l'internet. Le projet uumap [UU85] a été la première tentative sérieuse de collecter des données de localisation géographique à partir des sites avec une mémorisation centralisée. Ce projet n'a rencontré qu'un succès limité à cause de la difficulté de la maintenance et de la mise à jour d'une grande base de données centrale. Un autre problème était le manque d'outils de vérification des données fournies, ce problème débouchant sur l'entrée de données erronées dans la base.

2.1   SNMP:

L'utilisation d'une demande SNMP get sur la variable MIB (base de données d'informations de gestion) sysLocation était aussi une option, elle exigerait cependant que l'hôte fasse fonctionner un agent approprié avec un accès en lecture public. Il a aussi été estimé que les données de MIB devraient refléter les données de gestion locales (par exemple, "cet" hôte est au niveau 5, pièce 74) plutôt que la position géographique des hôtes. Cette position est étayée dans les exemples donnés dans la littérature sur ce domaine [ROSE91].

2.2   X500:

Le service d'annuaire X.500 [X.500.88] défini au titre des normes ISO apparaît aussi comme un fournisseur potentiel de données de localisation géographique. Cependant, du fait de la mise en œuvre limitée de ce service, il a été décidé de différer cela jusqu'à ce que service obtienne une acceptation et une utilisation plus larges au sein de la communauté de l'Internet.

2.3   BIND:

Le DNS [Mock87a][Mock87b] représente un système existant idéalement conçu pour la fourniture d'informations spécifiques des hôtes. Le DNS est largement utilisé et c'est un mécanisme bien compris pour fournir une base de données répartie de telles informations et sa nature extensible permet de l'utiliser pour disséminer virtuellement toute information. La mise en œuvre du DNS la plus couramment utilisée est le serveur de noms de domaines Internet de Berkeley (BIND, Berkeley Internet Name Domain) [UCB89]. Les informations que l'on souhaite rendre disponibles doivent être mises à jour localement mais sont disponibles dans le monde entier ; une correspondance parfaite avec les services fournis par le DNS. Les serveurs actuels du DNS fournissent une grande variété d'informations utiles sur les hôtes dans leur domaine mais n'ont pas la capacité de rapporter la localisation géographique d'un hôte.

3.   Format des RDATA

MSB                                         LSB

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

/                 LATITUDE                   /

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

/                 LONGITUDE                  /

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

/                  ALTITUDE                  /

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

où :

LATITUDE

Le nombre réel qui décrit la longitude codée comme une chaîne imprimable. La précision est limitée à 256 caractères dans la gamme de – 90 à 90 degrés. Les nombres positifs indiquent les localisations au nord de l'équateur.

LONGITUDE

Le nombre réel qui décrit la latitude codée comme une chaîne imprimable. La précision est limitée à 256 caractères dans la gamme de – 180 à 180 degrés. Les nombres positifs indiquent les localisations à l'est du méridien de Greenwich.

ALTITUDE

Le nombre réel qui décrit l'altitude (en mètres) au dessus du niveau moyen de la mer, codée comme une chaîne imprimable. La précision est limitée à 256 caractères. Les nombres positifs indiquent les localisations au dessus du niveau moyen de la mer.

Les valeurs de latitude/longitude/altitude sont codées comme des chaînes pour éviter les limitations de précision imposées par le codage en entiers non signés. Bien que cela puisse n'être pas considéré comme optimal, cela permet un très haut degré de précision avec une longueur moyenne acceptable d'enregistrement codé.

4.   Le RR GPOS

La localisation géographique est définie avec le mnémonique GPOS et le code de type 27.

GPOS a le format suivant :

<possesseur> <ttl> <classe> GPOS <latitude> <longitude> <altitude>

Un format de virgule flottante a été choisi par souci de simplicité pour spécifier les localisations géographiques. Cela garantit aussi une description concise et sans ambiguïté d'une localisation en mettant en application trois valeurs numériques à spécifier obligatoirement.

Les champs possesseur, ttl, et classe sont facultatifs et sont par défaut à la dernière valeur définie s'ils sont omis. La latitude est un nombre à virgule flottante dans la gamme de - 90 à 90 avec les valeurs positives qui indiquent les localisations au nord de l'équateur. Par exemple Perth, Australie occidentale, est situé à 32° 7' 19" sud de l'équateur, ce qui serait spécifié comme – 32,68820. La longitude est un nombre dans la gamme de – 180,0 à 180,0. Par exemple Perth, Australie occidentale, est situé à 116° 2' 25" est du méridien de Greenwich, ce qui serait spécifié 116,86520. L'Université Curtin à Perth est aussi à 10 mètres au dessus du niveau de la mer.

L'enregistrement GPOS valide pour un hôte à l'Université Curtin à Perth, Australie occidentale serait donc :

GPOS -32,6882 116,8652 10,0

Aucune limite n'est imposée au nombre d'emplacements décimaux, bien que la longueur de la chaîne codée soit limitée à 256 caractères pour chaque champ. Il est aussi suggéré que les administrateurs limitent leurs entrées au nombre minimum de caractères nécessaires dans chaque champ.

5.   Format de fichier maître

Chaque hôte exige son propre champ GPOS dans le RR DNS correspondant pour spécifier explicitement sa localisation géographique et son altitude. Si le champ GPOS est omis, une interrogation au DNS ne retournera aucune information de position pour cet hôte.

Considérons l'exemple suivant :

; Données d'autorité pour cs.curtin.edu.au.

;

@        IN    SOA marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au.

      (

               94070503    ; Série (aammjjnn)

               10800       ; Ra fraîchissement (3 heures)

               3600        ; Réessai (1 heure)

               3600000     ; Expire (1000 heures)

               86400       ; Minimum (24 heures)

      )

         IN    NS    marsh.cs.curtin.edu.au.

marsh    IN    A     34.7.1.1

         IN    MX    0        marsh

         IN    HINFO SGI-Indigo IRIX-4.0.5F

         IN    GPOS  -32.6882 116.8652 10.0

ftp      IN    CNAME marsh

lillee   IN    A     134.7.1.2

         IN    MX    0        marsh

         IN    HINFO SGI-Indigo IRIX-4.0.5F

         IN    GPOS  -32.6882 116.8652 10.0

hinault  IN    A     134.7.1.23

         IN    MX    0        marsh

         IN    HINFO SUN-IPC SunOS-4.1.3

         IN    GPOS  -22.6882 116.8652 250.0

merckx   IN    A     134.7.1.24

         IN    MX    0        marsh

         IN    HINFO SUN-IPC SunOS-4.1.1

ambrose  IN    A     134.7.1.99

         IN    MX    0        marsh

         IN    HINFO SGI-CHALLENGE_L IRIX-5.2

         IN    GPOS  -32.6882 116.8652 10.0

Les hôtes marsh, lillee et ambrose sont tous à la même localisation géographique à Perth, Australie occidentale (- 32,68820 116,86520). L'hôte hinault est à une localisation géographique différente, à 10 degrés au nord de Perth dans les montagnes (- 22,6882 116,8652 250,0). Pour des raisons de sécurité, nous ne souhaitons pas donner la localisation de l'hôte merckx.

Bien que la clause GPOS ne soit pas une entrée standard au sein des fichiers de configuration BIND, la plupart des mises en œuvre des fabricants semblent ignore toute chose qui n'est pas comprise au démarrage du DNS. Il en résulte habituellement qu'un certain nombre d'avertissements apparaissent dans les fichiers de connexion système, mais cela n'altère en aucune façon les informations de dénomination ni n'empêche le DNS d'effectuer ses tâches normales.

7.   Références

[ROSE91]   Rose M., "The Simple Book: An Introduction to Management of TCP/IP-based Internets", Prentice-Hall, Englewood Cliffs, New Jersey, 1991.

[X.500.88]   CCITT : L'annuaire - Concepts, modèles et services", Recommendations X.500 - X.521.

[Har82]   K. Harrenstein, M. Stahl et E. Feinler, "NICNAME/WHOIS" RFC 812, SRI NIC, mars 1982.

[Mock87a]   P. Mockapetris, "Noms de domaines - concepts et facilités", STD 13, RFC 1034, USC/Information Sciences Institute, novembre 1987.

[Mock87b]   P. Mockapetris, "Noms de domaines – mise en œuvre et spécification", STD 13, RFC 1035, USC/Information Sciences Institute, novembre 1987.

[FRB93]   Ford P., Rekhter Y., and H-W. Braun, "Improving the Routing and Addressing of IP", IEEE Network Vol.7, No. 3, pp. 11-15, mai 1993.

[VJ89   Jacobsen V., "The Traceroute(8) Manual Page", Lawrence Berkeley Laboratory, Berkeley, CA, février 1989.

[UCB89]   University of California, "BIND: Berkeley Internet Name Domain Server", 1989.

[UU85]   UUCP Mapping Project, Software available via anonymous FTP from ftp.uu.net., 1985.

8.   Considérations pour la sécurité

Une fois que les informations sont entrées dans le DNS, elles sont considérées comme publiques.

9.   Adresse des auteurs