Dans un paysage numérique en constante évolution, il est indispensable de sortir des sentiers battus pour combiner des solutions permettant de garantir la disponibilité, la fiabilité, la sécurité et les performances des applications à l’échelle mondiale.
Dans cette optique, il est logique d’aborder ce défi en partant d’un concept simple que la plupart d’entre nous connaissent bien : les charges de travail DNS. Plus précisément, les charges de travail DNS internes et externes.
“Déployer une solution DNS sur site pour les charges de travail des applications internes et une solution DNS dans le cloud pour celles des applications externes peut constituer une bonne pratique.”
Bien que ces charges de travail soient de nature similaire, l’utilisation d’un seul et même ensemble d’outils pour les gérer n’est pas toujours la pratique la plus efficace ni la plus sûre. Trop solliciter une solution DNS peut entraîner des inefficacités, des risques de sécurité, une latence accrue et une consommation excessive de ressources de calcul. Toutefois, une même solution n’a pas à répondre aux exigences des deux types de charges de travail. En effet, associer un service DNS exclusivement chargé des applications internes à une solution dédiée uniquement aux applications externes permet à chacun de concentrer ses ressources sur une tâche unique et de l’accomplir de manière optimale.
C’est pourquoi l’utilisation d’une solution DNS sur site pour les charges de travail des applications internes et d’une solution DNS cloud pour celles des applications externes peut constituer une bonne pratique pour les équipes qui souhaitent répartir les sollicitations de leur infrastructure. Le recours à deux solutions DNS distinctes évite d’avoir à gérer dans les moindres détails des flux de trafic disparates transitant par un seul appareil. Laissez chaque solution faire ce qu’elle fait de mieux afin de réduire globalement les contraintes qui pèsent sur elles.
Voici pourquoi il peut être judicieux de répartir les charges de travail DNS entre les ressources internes et externes.
1. Sécurité
Le maintien d’une solution DNS dédiée aux applications internes réduit le risque d’exposer des enregistrements internes sensibles à d’éventuelles attaques provenant de l’Internet public. Un service DNS externe dédié peut se concentrer sur la protection des ressources accessibles au public, en mettant en œuvre des mesures telles que l’atténuation des attaques par déni de service distribué (DDoS) pour les zones externes.
2. Optimisation des performances
Les services DNS internes peuvent être configurés pour traiter les requêtes avec une faible latence et optimisés spécifiquement pour le trafic interne à l’organisation. Cela est essentiel pour les applications à grande échelle ou sensibles à la latence. Les services DNS externes peuvent optimiser la distribution des applications accessibles depuis l’extérieur, en offrant aux utilisateurs le chemin le plus rapide et le plus efficace vers les applications dont ils ont besoin.
3. Évolutivité
La séparation des DNS internes et externes permet à chaque service d’évoluer indépendamment en fonction de ses modèles de trafic et des besoins des applications. Les applications externes peuvent connaître des pics de trafic imprévisibles et nécessitent des services DNS évolutifs offrant une mise en cache robuste et une couverture mondiale. À l’inverse, les applications internes sont moins susceptibles de connaître de tels pics de trafic et nécessitent donc des services DNS optimisés pour évoluer au sein de l’infrastructure.
4. Conformité et visibilité
Garantir la conformité aux cadres réglementaires (par exemple, le RGPD ou la loi HIPAA) nécessite souvent un contrôle et une visibilité accrus sur les requêtes DNS. Des systèmes DNS internes dédiés peuvent contribuer à satisfaire ces exigences. Des services dédiés au DNS externe peuvent offrir une visibilité spécifiquement axée sur les schémas de trafic des utilisateurs finaux, l’état des domaines et le bon fonctionnement des applications accessibles depuis l’extérieur.
5. Gestion et fonctionnalités sur mesure
Les services DNS internes peuvent prendre en charge des fonctionnalités telles que la découverte de services internes adaptée aux architectures de microservices (par exemple, les enregistrements SRV ou NAPTR). Les services DNS externes peuvent se concentrer sur des tâches telles que l’équilibrage de charge global, l’intégration à un CDN ou la reprise après sinistre afin de garantir une haute disponibilité aux utilisateurs finaux.
6. Simplicité opérationnelle
Grâce à une séparation claire des services DNS, les équipes peuvent mieux se concentrer sur les besoins propres aux charges de travail internes et externes, sans priorités contradictoires ni configurations mixtes, ce qui facilite le dépannage en réduisant la complexité.
Mettre en place un tel environnement lorsqu’une équipe utilisait jusqu’alors une solution DNS unique peut s’avérer pour le moins délicat. Comment étendre son infrastructure sans créer de risques excessifs en matière de sécurité ou d’efficacité, tout en maintenant les applications en ligne et disponibles ? Cette question est particulièrement cruciale lorsque ces applications externes prennent en charge des processus métier critiques qui ne peuvent être interrompus.
Comment y parvenir
Le déploiement de nouvelles solutions de mise à disposition d’applications couvrant à la fois les ressources sur site et dans le cloud peut présenter certaines difficultés. Les équipes ont besoin d’un outil permettant d’étendre facilement les applications à différents environnements, tout en garantissant une disponibilité et des performances élevées, afin qu’elles restent accessibles aux utilisateurs à tout moment, même sur un réseau en pleine expansion.
Un outil tel que F5 Distributed Cloud App Connect peut grandement faciliter cette transition pour les équipes qui ont décidé qu’une solution DNS double leur convenait. Distributed Cloud App Connect aide les équipes à adapter la diffusion des applications publiques et étend les services F5 Distributed Cloud aux applications hébergées sur F5 BIG-IP. Pour une équipe souhaitant utiliser F5 Distributed Cloud DNS pour ses applications accessibles au public, Distributed Cloud App Connect peut prendre en charge les processus de découverte, de configuration et d’équilibrage de charge afin de garantir une migration simple.
Grâce à la fonctionnalité de découverte de services de Distributed Cloud App Connect, les équipes peuvent utiliser Distributed Cloud Services pour identifier tous les serveurs virtuels exécutés sur BIG-IP, à condition de disposer d’une extension vers ce serveur BIG-IP. L’un des moyens les plus simples d’y parvenir consiste à déployer un dispositif Customer Edge (CE) sous forme de machine virtuelle parallèlement à un déploiement BIG-IP. Cela crée un tunnel sécurisé vers le réseau mondial de F5 et permet d’appliquer Distributed Cloud Services aux applications sur BIG-IP.
Une fois la connexion établie, les équipes peuvent utiliser Distributed Cloud App Connect pour détecter n’importe quel ensemble de serveurs virtuels et créer un catalogue d’applications à gérer. L’utilisation de Distributed Cloud DNS pour créer un sous-domaine, et de Distributed Cloud App Connect pour créer un enregistrement DNS pour le front-end ainsi qu’un équilibreur de charge HTTP pour le serveur virtuel hébergeant l’application, permet à ces applications accessibles au public d’utiliser Distributed Cloud DNS comme service DNS externe dédié. Les services back-end auxquels le serveur virtuel doit accéder sont uniquement annoncés au front-end, et non aux utilisateurs publics. F5 BIG-IP DNS peut ainsi se concentrer sur les charges de travail internes critiques qui assurent le bon fonctionnement des organisations. Une fois les applications sur BIG-IP détectées par App Connect, les équipes peuvent également, si elles le souhaitent, déployer des services de sécurité tels que F5 Distributed Cloud Web App and API Protection (WAAP) sur les serveurs virtuels de BIG-IP.
Restez à l’écoute pour en savoir plus
Pour découvrir plus en détail comment ces solutions peuvent fonctionner ensemble afin d’étendre votre environnement, ne manquez pas la vidéo qui accompagne cet article et consultez notre article d’analyse approfondie sur DevCentral, dans lequel nous posons les bases d’une extension réussie de votre infrastructure. Et si vous êtes prêt à passer à l’étape suivante, contactez-nous pour découvrir comment Distributed Cloud DNS peut étendre votre environnement et offrir aux utilisateurs des expériences numériques plus homogènes et plus performantes.
À propos des auteurs
Colin Clauset est Senior Product Marketing Manager chez F5, où il est spécialisé dans les solutions SaaS de mise à disposition d’applications. Il pilote la stratégie de mise sur le marché de projets et de services de mise à disposition d’applications distribuées, avec un intérêt particulier pour la manière dont la technologie peut simplifier les processus complexes afin de mieux répondre aux besoins des professionnels de l’informatique. Fort de son expérience dans le conseil avant de rejoindre F5, Colin aborde les problématiques des clients en privilégiant des solutions globales qui vont au-delà des produits pris individuellement.
Autres articles de Colin ClausetArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.