Enfer DNS: Les sept péchés capitaux – Serveur d’impression

Il est de notoriété publique partout sur le Web et sur les réseaux LAN partout que «si le DNS n'est pas heureux, personne n'est content». C'est assez simple, vraiment. Les applications codées en dur pour utiliser des adresses IP fixes sont mauvaises, car elles changent. Ainsi, tout, des navigateurs Web de vos utilisateurs aux applications métier stratégiques, tous doivent reposer sur un système DNS sain et performant. Le problème est que l'infrastructure DNS de nombreuses organisations est tout sauf saine, ce qui entraîne des performances médiocres pour tout. Examinons d'abord quelques concepts DNS.

GeoDNS

GeoDNS est une fonctionnalité de BIND et d'autres services DNS qui permet aux serveurs DNS de donner des réponses différentes en fonction de l'ip.addr source de la demande. Cela fonctionne comme ça. Une zone est configurée avec plusieurs entrées pour les ressources, comme www.example.com. Le contenu de ce site Web est répliqué sur des serveurs partout dans le monde et exploite probablement les CDN mondiaux qui ont également du contenu répliqué sur des serveurs partout dans le monde. Lorsqu'une requête atteint DNS pour www.example.com ou images.example.com, le serveur DNS qui fait autorité pour la zone example.com examine l'ip.addr source de la requête DNS, détermine d'où provient cette requête, et fournit une réponse qui inclut ip.addrs qui sont «locaux» à la requête. Ce n'est pas un système parfait, et souvent les entreprises réallouent les plages d'adresses IP sans mettre à jour les bases de données, mais dans l'ensemble, cela fonctionne très bien. Voici un exemple pratique.

Disons que vous êtes en France et recherchez www.example.com, qui a un point de terminaison en Autriche et un autre aux États-Unis. Le DNS example.com utilise GeoDNS. Si votre requête DNS frappe les serveurs example.com du NAT ip.addr de votre bureau en France, ils vous donneront l'ip.addr du serveur autrichien. Mais si les serveurs DNS du bureau français sont configurés pour être transférés au siège américain, ce que les serveurs DNS example.com voient comme une requête pour www provient du NAT ip.addr du centre de données américain, donc ils répondent avec le serveur américain. Au lieu d'un temps de réponse rapide de 30 millisecondes à vos demandes HTTP, vous devez traverser l'Atlantique et affronter des vidéos de chats, et voir probablement plus comme un temps de réponse de 150 millisecondes. C'est mauvais.

Pour que votre réseau profite correctement de GeoDNS, vous devez vous assurer que pour les zones externes, vos utilisateurs utilisent un serveur DNS qui leur est proche et que le serveur DNS doit pouvoir effectuer ses propres requêtes pour les zones externes en allant à la racine , sans avoir à transférer sur votre WAN vers d'autres serveurs DNS dans une autre partie du monde. Cela permet non seulement d'économiser du temps et de la bande passante WAN, mais aussi de garantir que s'il y a des ressources locales, vous obtenez les adresses IP qui vous sont locales.

Utilisation de root

L'ancre du DNS est composée de 13 serveurs, nommés A via M.root-servers.net, qui hébergent la zone racine. Ces serveurs sont gérés par 12 organisations différentes et sont distribués dans le monde entier. Ils ne résolvent pas chaque enregistrement pour chaque zone dans DNS, mais ils résolvent les serveurs faisant autorité pour chaque domaine sur Internet. Lorsque votre serveur DNS peut «aller à la racine», au lieu de le transmettre à votre FAI ou à votre siège social, il fait une requête directe à l'un des serveurs racine pour trouver les serveurs faisant autorité pour une zone, puis il interroge ces serveurs faisant autorité. pour résoudre les enregistrements A, CNAME, MX et autres pour cette zone. Il faut un peu plus de temps pour résoudre un domaine pour la toute première fois de cette façon, mais votre serveur DNS peut mettre en cache l'identité des serveurs faisant autorité de la zone, et le TTL sur leurs enregistrements dure généralement des heures ou des jours. Tant qu'au moins les enregistrements NS d'un domaine sont déjà dans le cache, vous devriez voir la résolution pour tous les autres enregistrements terminés en bien moins de 50 millisecondes. Les enregistrements déjà mis en cache dans la mémoire de votre serveur DNS seront définitivement résolus en moins de 25 millisecondes. Étant donné que le DNS doit avoir un point de départ, les serveurs DNS utilisent un fichier appelé «fichier d'indications de racine» qui répertorie les 13 serveurs racine et leurs ip.addrs IPv4 et IPv6 afin que le service DNS sache par où commencer.

Que vous regardiez vos bureaux distants, votre fournisseur de filtrage Web ou même la façon dont vous avez résolu ce site Web, passez en revue votre infrastructure DNS aujourd'hui pour vous assurer que vous ne commettez pas l'un de ces sept péchés capitaux:

1. Pas de DNS local

Flickr / Elijah van der Giessen

Je vois cela presque chaque semaine chez un client ou un autre. Ils ont des bureaux partout dans le monde, avec des utilisateurs qui se plaignent de la lenteur des performances, et lorsque nous allons dépanner le réseau, nous constatons qu'il n'y a pas de serveur DNS local au bureau. Même si le mieux que vous puissiez faire est de mettre en cache un serveur DNS sur le routeur dans le petit bureau extérieur, c'est mieux que rien et cela améliorera les performances globales pour tout le monde. La résolution DNS ne devrait pas prendre plus de 25 millisecondes; 50 hauts. Si chaque fois qu'un utilisateur doit se connecter à une imprimante, un contrôleur de domaine, un serveur de fichiers ou ouvrir une page Web, il doit attendre des centaines de millisecondes pour que la réponse DNS revienne du bureau distant, alors l'utilisateur va remarquez que les choses sont «lentes». Assurez-vous que vous avez des serveurs DNS locaux dans n'importe quel bureau suffisamment grands pour disposer d'un équipement capable d'exécuter DNS.

2. Configuration du transfert vers le bureau principal

Il s'agit d'un problème courant parmi les grandes entreprises, en particulier celles ayant une portée mondiale. Ils configurent les serveurs DNS dans chacune de leurs régions, mais configurent ensuite ces serveurs DNS pour les transmettre aux serveurs DNS du siège social ou du centre de données principal. Alors que de plus en plus de fournisseurs SaaS et de sites Web majeurs déploient des points de terminaison distribués et utilisent des CDN mondiaux pour offrir de meilleures performances aux utilisateurs, plus l'erreur est grave. De mauvaises décisions de sortie peuvent aggraver la situation – voir ci-dessous pour en savoir plus.

3. Utilisation de votre DNS FAI

D'accord, vous modifiez donc la redirection de vos serveurs DNS au bureau pour ne pas la rediriger vers les serveurs DNS du siège de l'autre côté de l'océan. C'est bon. Au lieu de cela, vous les transférez à votre FAI parce que c'est mieux. Mais ce n'est souvent pas le cas. Les adresses IP que votre FAI vous donne peuvent très bien NE PAS être dans la même région que vous, ou elles-mêmes peuvent être configurées pour être transférées vers une autre région. La seule fois où je me sentirais à l'aise d'utiliser les serveurs DNS d'un FAI, c'est pour la maison, et je ne le fais même pas à la maison! Si vous êtes absolument sûr que les serveurs DNS de votre FAI sont locaux pour vous, et qu'ils ne transmettent à aucun serveur distant, alors ça va, mais surveillez vos temps de réponse, et envisagez simplement de laisser vos serveurs DNS locaux s'enraciner.

4. Utilisation du DNS public

Ainsi, au lieu d'utiliser le DNS de votre FAI, vous décidez d'utiliser l'un des services DNS publics fournis par Google, ou OpenDNS, FreeDNS, votre fournisseur d'antimalware ou l'un des FAI de niveau 1 comme Level3 ou Hurricane Electric. Malheureusement, le même problème peut se poser ici. Souvent, ces ip.addrs répertoriés publiquement ne se trouvent pas dans la même région que vous, vous devez donc à nouveau résoudre des noms en ip.addrs qui ne sont pas locaux pour vous. Encore une fois, je vous recommande de laisser vos serveurs DNS locaux s'enraciner plutôt que de gérer le transfert.

5. Ne pas mettre à jour les indications de racine

Vous avez peut-être lu ceci jusqu'à présent et vous vous sentez plutôt bien parce que vous ne transférez pas vers des serveurs distants et que vous autorisez vos serveurs locaux à aller à la racine. C'est génial! Mais à quand remonte la dernière fois que vous avez mis à jour votre fichier d'indices de racine? N'importe qui? N'importe qui? Bueller? Le fichier named.root maintenu par Internic a été mis à jour pour la dernière fois le 2016-10-20. Ils ne le mettent pas souvent à jour, mais lorsqu'ils le font, il est essentiel que tous les administrateurs DNS utilisant des conseils de racine mettent à jour leur fichier de conseils de racine local sur tous leurs serveurs DNS avec les dernières informations. Si vous ne l'avez pas fait au cours des derniers mois, accédez à Internic et consultez le fichier mis à jour.

6. Résolution d'un chemin, sortie d'un autre

Voici un énorme problème (j'ose dire yuuuge) que je vois constamment avec les clients. Ils ont une sortie Internet locale mais ils ont configuré le transfert DNS vers des serveurs distants, ou ils ont des chemins dédiés aux ressources SaaS ou PaaS dans un emplacement, mais pas dans un autre. En remplaçant tout ce qui précède sur le DNS local, vous devez vous assurer que votre résolution DNS passe par le même chemin que votre trafic Internet. Si vous divisez ce chemin de sorte que certaines sorties Internet soient locales (directes ou via un proxy) mais que d'autres sorties Internet soient sorties d'un circuit dédié à un fournisseur externe, vous devrez peut-être configurer le transfert conditionnel pour vous assurer que la résolution DNS et le routage sont épuisés. la même sortie pour les ressources distantes. Sinon, vous constaterez peut-être que vous résolvez un point de terminaison local, mais que vous acheminez votre trafic à mi-chemin à travers le monde avant qu'il ne puisse sortir de votre réseau, pour devoir revenir à la ressource locale, puis à nouveau.

7. Proxy distants

Il existe plusieurs solutions de proxy sur le marché qui fournissent des proxy «dans le cloud» ou dans les centres de données du fournisseur de services. Si vous utilisez l'un d'eux, vous devez vous assurer que le fournisseur de services vous offre non seulement des nœuds proxy locaux, mais qu'il ne fait pas les mêmes erreurs DNS avec le transfert que ci-dessus. J'ai vu maintes et maintes fois où un client utilise un proxy cloud et essaie d'accéder à un service SaaS dans sa région et a de très mauvaises performances. Lorsque nous travaillons avec le fournisseur SaaS pour diagnostiquer les connexions à partir du proxy, nous déterminons que le proxy lui-même se connecte à des points de terminaison de l'autre côté de la planète plutôt qu'à des ressources hébergées localement, et cela revient à la redirection DNS des nœuds proxy aux serveurs en amont dans une autre région.

Pratiquement chaque connexion unique établie d'un hôte à un autre commence par une requête DNS. De plus en plus de fournisseurs de services et de CDN adoptent une approche GeoDNS pour aider à distribuer les ressources à l'échelle mondiale et à fournir aux clients la meilleure réponse possible. Les administrateurs DNS doivent faire leur part pour garantir que les clients obtiennent des réponses rapides et appropriées à leurs requêtes. Prenez le temps d'examiner votre infrastructure DNS pour vous assurer que vous ne commettez pas l'un des sept péchés capitaux.

Vues du message:
15 277

Lire Suivant