Serveurs DNS

[PierreBerger]

Bonjour,

J'ai lu un article de Mr Hébert de Netapsys sur ce forum ( cf http://www.webmaster-hub.com/publication/L...de-voute-d.html ) et j'aimerais des avis sur ce qu'il avance.

En gros, si j'ai bien compris, il dit que si l'on a des serveurs DNS en Australie par exemple, les sites seront plus facilement accessibles aux internautes australiens. Il parle bien de serveurs DNS, pas de serveurs d'hébergement.

Je ne comprends pas trop cet argument : il me semble que justement, le principe des serveurs cache ds le monde entier fait que les serveurs primaires et secondaires des "registrars" ne seraont pas utilisés à chaque connexion.

Quelqu'iun peut il me dire si j'ai mal piugé quelque chose et s'il est utile de payer les services d'un registrar ayant des serveurs dns partout ds le monde ou si ça n'est que du vent marketing ?

merci d'avance

Pierre

[Dan]

Bonjour Pierre,

Il dit précisément que le premier accès au site (au moment où on fait la première requête DNS) dépendra de la localisation du serveur DNS.

Par exemple pour le serveur du Hub qui héberge la zone webmaster-hub.com (il est DNS primaire), un internaute résidant en Australie devra lors de sa première visite interroger le serveur DNS en France pour savoir quelle est l'IP correspondant à www.webmaster-hub.com. Cette requête ne devra se faire qu'une fois, mais sera nécessaire avant de pouvoir accéder au site.

Les requêtes suivantes seront dès ce moment mises en cache, et il n'y aura plus besoin d'interroger le serveur DNS1 du Hub.

[auto]

Sauf si un autre utilisateur australien utilisant le même FAI/dns et déjà venu sur le site, non ?

Dans ce cas, cela à peu d'intéret à mon avis

[PierreBerger]

merci de vos réponses. Il est donc clair que la 1ere fois qu'un visiteur ds un pays via un fournisseur d'accès ira sur le site, la localisation du serveur DNS sera importante. Si elle est loin, quelques milli secondes de plus seront nécessaires... pour un seul utilisateur par fournisseur d'accès, une fois pour toutes.

l'argument développé par le Mr de Netapsys me semble dès lors ultra faible, non?

il est impossible de répondre à son post sur le site, est-ce qu'en tant qu'admin du site vous pourriez l'informer de ce thread? Il a peut-être des explications plus détaillées à fournir.

Merci d'avance

Pierre

[glibre]

bonjour,

faut savoir qu les FAI utilisent du cache DNS ce qui limite enormement ce genre de probleme.

[Dan]

il est impossible de répondre à son post sur le site, est-ce qu'en tant qu'admin du site vous pourriez l'informer de ce thread? Il a peut-être des explications plus détaillées à fournir.

Je le contacte par mail

<edit: inutile, je vois qu'il est sur le post >

[yoann.hebert]

Bonjour,

Cette question est effectivement pertinente !

Comme je l'indique dans l'article concerné :

- "Larchitecture DNS mondiale est basée sur un système de cache : lorsquun serveur a effectué une première fois une résolution, il la garde en mémoire un certain temps pour pouvoir répondre plus rapidement aux nouvelles requêtes."

Et :

- "Le coût de la résolution DNS en termes de performance est donc essentiellement sensible lors du premier accès de linternaute à votre site."

Cependant, la proportion d'internautes impactés dépend essentiellement de deux facteurs :

- Le trafic de votre site : moins celui-ci est visité, moins il y a de chance que la résolution DNS soit dans le cache du serveur DNS que l'internaute utilise.

- Le TTL du zone file de votre nom de domaine : ce paramètre détermine la durée pendant laquelle un enregistrement DNS doit rester en cache. Au delà de cette durée, une nouvelle interrogation vers les serveurs DNS autoritaires doit être effectuée. Certaines zones particulièrement actives, ou sur lesquelles une réactivité accrue est nécessaire, peuvent avoir un TTL de l'ordre de quelques minutes seulement.

Sur un échantillon de quelques dizaines de milliers de noms de domaine (du nom personnel au site d'ecommerce critique), nous constatons plusieurs millions de résolution DNS quotidienne. Ce sont autant de requêtes qui sont impactées par le temps de résolution DNS.

L'optimisation de ce temps de résolution n'est par ailleurs pas le seul intérêt d'une répartition géographique des serveurs DNS.

Lors du tremblement de terre du 27 décembre 2006, qui a coupé le réseau Internet chinois du réseau Internet global pendant plusieurs jours, la présence d'un serveur DNS à Hong Kong nous a ainsi permis d'assurer la continuité de service DNS à l'intérieur de la zone isolée. Cette continuité de service DNS n'a bien évidemment de sens que si les services supportés (Web, mail, ...) sont également sécurisés et redondés.

De façon générale, la sécurisation d'Internet s'appuie sur un mécanisme de répartition, de redondance et de cache. C'est le cas au niveau des serveurs ROOT, mais cela doit également l'être à chaque niveau : DNS autoritaire, Web (sites miroirs), Mail (serveurs secondaires), ...

Et, pour être efficace, cette répartition doit être complète :

- répartition réseau : il ne sert à rien de disposer de 2 serveurs DNS si ceux-ci sont sur le même réseau. En cas de problème sur ce réseau, vos noms de domaine seront inaccessibles.

- répartition "électronique" : les serveurs DNS qui s'appuient sur un même nom de domaine sont vulnérables en cas de problème sur ce nom. Par exemple, ns1.nom.com et ns2.nom.com sont totalement inutilisables si nom.com est malencontreusement supprimé par le registre, si son propriétaire oubli de le renouveler ou bien encore si son zone file est mal configuré. Nous préconisons des configurations du type ns.nom1.com, ns.nom2.fr, ns.nom3.us, ns.nom4.hk.

- répartition géographique : elle permet d'optimiser les temps d'accès (le système DNS est conçu pour interroger systématiquement le serveur DNS le plus rapide) et de se prémunir contre les coupures macroscopiques du réseau qui peuvent conduire à l'isolement complet de certaines zones.

Bien évidemment, cette sécurisation est également une question de bon sens et il convient d'adapter les moyens mis en oeuvre aux enjeux et aux risques (techniques, financiers, ...) encourus sur votre architecture en cas d'interruption de service.

Cordialement,

Yoann Hébert