Propos et Commentaires du Climenole

Je reprends une partie d’un article publié antérieurement, cette partie portant sur le protocole DNS et les serveurs DNS alternatifs devant faire l’objet d’un billet spécifique. Les texte original a été adapté et des informations supplémentaires ont été ajoutées.

Les requêtes DNS et l’utilisation de serveurs DNS alternatifs

L’utilisation de serveurs DNS alternatifs, id est, indépendants de ceux du FAI  peut contribuer dans une certaine mesure à préserver la confidentialité des communications sur Internet ou plus correctement à limiter et compliquer la traçabilité de vos connexions Internet par un tiers.

Un FAI “au long nez” par exemple …

1) La requête DNS, préalable aux connexions Internet

Internet ne marche qu’au moyen d’adresses IP et les applications Internet obtiennent la correspondance entre un URI et son adresse IP qu’au moyen de requêtes Domain Name System, protocole de la couche Application lui-même encapsulé dans le protocole UDP de la couche Transport du modèle TCP/IP.

Voir Wikipedia (en) Domain Name System Wikipédia (fr) Domain Name System

2) URI, URL, URN: précisions

Un URI (Uniform Resource Identifier) est un ensemble identifiant une ressource sur Internet et incluant un URL ou (ou inclusif) un URN.

Un URL (Uniform Resource Locator) est un élément d’un URI permettant d’accéder à la ressource Internet

Un URN (Uniform Resource Name) est un élément qui identifie une ressource Internet par son nom dans un espace de nom.

La syntaxe d’un URI comprend le schéma identifiant le protocole utilisé, suivie par le signe deux-points et l’adresse de la ressource suivie ou non par une requête et terminée ou non par un fragment:

URI= <schéma>: partie hiérarchique [ ? <requête> ] [ # <fragment>]

schéma ou URN du protocole= protocole utilisé { http, https, ftp, irc, mailto, etc.}

partie hiérarchique ou URL= autorité {[ utilisateur "@" ] hôte [ ":" port ]} {chemin {absolu, sans racine, vide}

Les URI avec http, https sont bien connus mais ne s’y limitent pas. Quelques exemples:

XMPP  xmpp:<utilisateur>@<hôte>[:<port>]/[<ressource>][?<requête>]

IMAP  imap://[<utilisateur>[;AUTH=<type>]@]<hôte>[:<port>]/<commande>

SMTP   mailto:<adresse>[?<entête1>=<valeur1>[&<entête2>=<valeur2>]]

NNTP  nntp://<hôte>:<port>/<nom du groupe>/<numéro d'article>

SIP  sip:<utilisateur>[:<mot de passe>]@<hôte>[:<port>][;<paramètres uri>][?<entêtes>]

SIPS  sips:<utilisateur>[:<mot de passe>]@<hôte>[:<port>][;<paramètres uri>][?<entêtes>]

RSS  feed:<uri absolu> ou feed://<partie hiérarchique>

L’utilisation en mode local est aussi possible pour des fichiers, des pages locales, des ressources d’applications.

Par exemple les interfaces de paramétrage des routeurs telle que http://192.168.0.1 , des fichiers locaux avec file:///<chemin>/nom de fichier ou des ressources d’applications comme celles des programmes développés par Mozilla:

chrome://<paquetage>/<section>/<chemin> (où <section> est soit “content”, “skin” ou “locale”) ou “about: nom de ressource”… Voir le KB de MozillaZine: «About protocol links» et «Chrome URLs»

Voir plusieurs exemples sur le site du développeur de l’extension Firefox «Linkification»: Testcases

Voir RFC 3986

La désignation la plus courante est «URL» mais la dénomination correcte pour les adresses dont nous parlons est «URI» et son utilisation devrait être préférée dans les discussions et documents techniques.

Dans le cas – par exemple – d’un navigateur, l’entrée dans la barre d’adresse de l’URI d’un site web déclenche une série d’étapes préalables à la sollicitation de connexion vers ce site web:

3) La vérification du fichier HOSTS

Le navigateur vérifie la présence ou non de l’URL (l’URI sans l’URN du protocole) dans le fichier HOSTS du système d’exploitation; si l’adresse est trouvée sous la forme {IP} {au moins 1 espace} {URL} la connexion est établie sans requête DNS (normalement mais ce n’est pas toujours le cas…) vers l’adresse IP indiquée (et qui n’est pas nécessairement la bonne!), si l’URL est trouvé sous la forme {127.0.0.1} {au moins 1 espace} {URL} alors la connexion ne se fait pas (bouclage sur localhost) mais habituellement l’URL n’est pas présent dans le fichier HOSTS …

Voir Wikipedia (en)  HOSTS File Wikipédia (fr)  HOSTS

4) La requête DNS

Le navigateur envoie à l’adresse IP du serveur DNS, configurée au préalable dans les paramètres de l’ O.S. , une requête pour obtenir l’adresse IP correspondant à l’URI, en UDP vers le port 53 du serveur DNS qui retourne au navigateur l’adresse IP correspondante,

La sollicitation de connexion en 3 phases

Cette adresse IP étant obtenue, le navigateur peut alors utiliser cette adresse IP pour envoyer une sollicitation de connexion via le protocole TCP depuis le premier port dynamique local disponible vers le port 80 (Http) du serveur (dans le cas d’une connexion à un site web non-sécurisé) et suivant le Handshake en trois phases :

TCP + Syn out

le client (navigateur) envoie un paquet TCP avec le flag Syn depuis le premier port dynamique local disponible vers le port 80 du serveur Http,

TCP + Syn Ack in

le serveur répond à cette sollicitation de connexion par un paquet TCP avec le flag Syn-Ack , (si la connexion est acceptée sinon c’est un paquet TCP + Ack-Rst signifiant que le serveur est indisponible et le port fermé) envoyé au client vers le port dynamique du client choisi dans la première phase,

TCP + Ack out

le client confirme alors la connexion en renvoyant depuis le même port dynamique local choisi au début un paquet TCP avec le flag Ack (acquittement de connexion), la connexion entre dans l’état «established» et se poursuit entre le port dynamique choisi au début du côté client et le port 80 du serveur web avec lequel cette connexion est établie tant que dure cette connexion…

5) Les serveurs DNS alternatifs

Pour utiliser ces serveurs DNS alternatifs, il n’y a rien à télécharger ou à installer. Il suffit de modifier les paramètres de connexion Internet de votre système d’exploitation. Les explications détaillées sont données sur les sites web et pour les principaux S.E.

Le projet le plus complet est celui d’OpenDNS qui offre, en plus du service DNS, un ensemble de fonctionnalités de filtrage de contenu, d’auto-correction des adresses, d’anti-hameçonnage, etc.

Cependant les Projet OpenNIC est prometteur et s’il semble disposer de moins de fonctionnalités, c’est une option à considérer. Puisque l’utilisation de ces serveurs alternatifs est simple, un essai vous permettra de décider si les performances et les résultats vous conviennent.

-  Open NIC project

• 88.191.51.140 – France
• 91.186.21.136 – Royaume-Uni
• 216.67.98.38 – USA, Alaska
• 216.87.84.209 – USA, Colorado
• 71.170.11.156 – USA, Texas
• 58.6.115.42 – Australie
• 58.6.115.43 – Australie
• 119.31.230.42 – Australie

- OpenDNS

• 208.67.222.222
• 208.67.220.220

Statut des serveurs OpenDNS

.

Voir Wikipedia (en)      OpenNIC OpenDNS

Nota Bene : J’ai fait l’essai d’Open NIC pendant une semaine (serveur 71.170.11.156) et les résultats sont excellents: aucune requête n’a échouée et l’accès est aussi rapide – à vue de nez – qu’avec OpenDNS…

J’utilise présentement OpenNIC comme serveur principal et OpenDNS comme serveur alternatif.

Si vous en faites l’essai, n’hésitez pas à laissez un commentaire sur votre expérience.

Voir aussi: OpenDNS des requêtes plus rapides et plus sûres (article du 11 juillet 2006)