Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DNS fournit une résolution de noms à l’aide de l’infrastructure Microsoft Azure. Cet article se concentre sur les zones DNS publiques, que vous créez généralement pour les domaines que vous possédez et utilisez pour publier des enregistrements pour les applications et les services disponibles sur Internet. Les noms d’hôte que vous résolvez sont des noms DNS accessibles publiquement et les adresses IP résolues sont généralement accessibles à partir d’Internet.
Azure DNS est un service non régional qui n'est pas lié à une zone de disponibilité spécifique ou Azure région.
Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft offre une gamme de fonctionnalités permettant de prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.
Cet article explique comment Azure DNS zones publiques répondent aux pannes temporaires, aux défaillances de zone de disponibilité, aux défaillances à l’échelle de la région, aux pannes de service, aux menaces de sécurité et à la configuration incorrecte, aux pannes des outils de gestion et au portail et à la maintenance des services. Il décrit également comment protéger et restaurer la configuration de votre zone et explique les exigences du contrat de niveau de service (SLA) clés.
Recommandations de déploiement de production pour la fiabilité
Pour les déploiements de production de zones publiques Azure DNS, suivez ces recommandations pour améliorer la fiabilité :
Déléguer à tous les serveurs de noms : Azure DNS attribue quatre serveurs de noms à chaque zone DNS publique. Configurez votre délégation de domaine pour utiliser les quatre serveurs de noms. Cette configuration fournit une isolation des erreurs et est requise pour être éligible au contrat SLA Azure DNS.
Configurez les valeurs de durée de vie appropriées : Définissez les valeurs de durée de vie (TTL) qui équilibrent le volume de requête avec la vitesse à laquelle les clients reçoivent des modifications d’enregistrement. Des valeurs TTL plus faibles permettent aux clients de recevoir les changements plus rapidement, mais augmentent le volume des requêtes. Des valeurs TTL plus élevées réduisent le volume de requêtes, mais peuvent retarder le basculement après la modification d’un enregistrement.
Utilisez des enregistrements d’alias pour les ressources Azure prises en charge :les enregistrements alias reflètent automatiquement les modifications apportées à une ressource de Azure sous-jacente pendant la résolution DNS et empêchent les enregistrements DNS obsolètes.
Vue d’ensemble de l’architecture de fiabilité
Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.
Architecture logique
La ressource principale que vous déployez est une zone, qui contient les jeux d’enregistrements DNS pour un domaine. Un jeu d’enregistrements associe un nom DNS à une valeur, telle qu’une adresse IP ou un point de terminaison. Les noms qu’une zone DNS publique résout sont accessibles via Internet.
Pour faire d’Azure DNS le serveur DNS faisant autorité pour votre domaine, déléguez le domaine aux serveurs de noms qu’Azure attribue lorsque vous créez la zone. Une fois la délégation en place, vous créez des jeux d’enregistrements pour les types d’enregistrements DNS pris en charge par Azure DNS. Vous pouvez également créer des enregistrements d’alias qui référencent Azure ressources telles que les adresses IP publiques, les profils Traffic Manager et les points de terminaison Azure Front Door, afin que l’enregistrement DNS reste synchronisé avec la ressource cible.
Pendant la résolution DNS, les résolveurs DNS récursifs suivent la hiérarchie DNS pour atteindre les serveurs de noms autoritaires Azure DNS de votre zone.
Important
Azure DNS résout les noms, mais ne surveille pas l'intégrité du point de terminaison ou route le trafic d'application. La fiabilité de votre solution globale dépend de la configuration des ressources auxquelles font référence vos enregistrements DNS, telles que les machines virtuelles et les équilibreurs de charge.
Cet article ne couvre pas ces ressources, mais leurs configurations de disponibilité affectent directement la résilience de votre application. Passez en revue les guides de fiabilité des services Azure dans votre solution pour découvrir comment chaque service prend en charge vos exigences de fiabilité.
Architecture physique
Azure DNS fonctionne en tant que service non régional et déploie son infrastructure dans plusieurs zones de disponibilité dans plusieurs régions Azure dans le monde entier. Cette conception permet aux Azure DNS de rester résilientes lors d’une panne de zone de disponibilité ou de région, car l’infrastructure d’une autre zone ou région continue de répondre aux demandes de résolution.
Les protocoles Internet globaux tels que Anycast, DNS et BGP acheminent automatiquement les requêtes de résolution DNS entrantes vers l’infrastructure Azure DNS saine la plus proche.
Le plan de diffusion d’Azure DNS fonctionne selon une configuration active-active sur deux stacks de diffusion indépendantes : l’une s’exécutant sous Linux et l’autre sous Windows. Ces couches ne partagent aucun code ni aucun matériel sous-jacent. Étant donné qu’ils sont indépendants, un bogue, une vulnérabilité ou une défaillance qui affecte une pile n’affecte pas l’autre. Cette indépendance réduit le risque de panne de service complète causée par un point de défaillance unique et contribue à protéger contre certaines classes de vulnérabilités zéro jour.
Résilience aux erreurs temporaires
Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.
Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, voir Recommandations concernant le traitement des pannes transitoires.
Azure DNS gère les erreurs temporaires via son infrastructure DNS globale.
Si une erreur temporaire se produit pendant la résolution DNS, le client ou le programme de résolution intermédiaire doit réessayer en fonction de son comportement de nouvelle tentative DNS configuré. Entre 2 et 5 secondes est généralement un délai d’expiration suffisant pour un client DNS.
Le temps de vie de chaque enregistrement DNS affecte également la façon dont votre solution gère les erreurs. Si le TTL est très faible, les clients doivent envoyer davantage de requêtes à Azure DNS, ce qui accroît les risques de défaillances temporaires. Si le TTL est très élevé, en cas de panne réelle d’un serveur back-end nécessitant de rediriger le trafic vers une autre adresse IP, les clients risquent de subir un retard de basculement jusqu’à l’expiration du TTL. Configurez soigneusement les TTL pour équilibrer la disponibilité, la latence et la réactivité.
Résilience aux échecs de zone de disponibilité
Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.
Azure DNS fonctionne en tant que service non régional. Microsoft distribue son infrastructure entre plusieurs zones de disponibilité dans plusieurs régions Azure et réplique les modifications apportées à vos zones DNS publiques dans cette infrastructure. Vous ne sélectionnez pas de zones de disponibilité ni ne configurez la redondance de zone. Pendant une panne de zone de disponibilité, l’infrastructure d’une autre zone ou région continue de répondre aux demandes de résolution.
Si une ressource que vous déployez sur une seule zone de disponibilité, telle qu'une machine virtuelle, devient indisponible pendant une défaillance de zone, Azure DNS continue de retourner l'adresse IP configurée de la ressource, car elle ne surveille pas l'intégrité du point de terminaison. Si vous basculez vers une ressource dans une zone saine, vous êtes responsable de la mise à jour de l’enregistrement DNS afin que les clients utilisent la ressource saine. Vous pouvez également placer les ressources derrière un équilibreur de charge redondant interzone qui dirige le trafic vers des machines virtuelles dans des zones saines.
Résilience aux défaillances à l’échelle de la région
Les zones DNS sont résilientes aux pannes de région, car les données de zone sont globalement disponibles et déployées dans plusieurs régions Azure. Si une région a une panne, les ressources que vous avez déployées dans cette région, telles que les réseaux virtuels et les machines virtuelles, peuvent être indisponibles, mais Azure DNS continue de résoudre les enregistrements dans votre zone.
Si vous avez une solution qui doit basculer entre plusieurs régions, par exemple à des fins de récupération d’urgence, envisagez d’utiliser Azure Traffic Manager ou Azure Front Door. Ces services fournissent des fonctionnalités de basculement automatisées, que vous pouvez utiliser si une région n’est pas saine.
Résilience aux menaces de sécurité et à la mauvaise configuration
Les attaques de sécurité et les erreurs de configuration sont deux des risques de fiabilité les plus importants pour les zones DNS. Plusieurs types d’attaques visent spécifiquement la résolution DNS, et une erreur de configuration accidentelle peut perturber vos charges de travail tout aussi gravement.
Pour obtenir des conseils de sécurité complets spécifiques aux zones DNS publiques, consultez Sécuriser votre déploiement Azure DNS et protéger les zones et enregistrements DNS.
Résilience aux pannes de service
Azure DNS est un service hautement résilient, avec un contrat SLA de disponibilité de 100% lorsque votre application répond à certaines conditions. Les pannes de service sont extrêmement inhabituelles, mais les problèmes réseau ou les problèmes liés à d’autres infrastructures peuvent perturber la connectivité au service Azure DNS.
La résilience d’Azure DNS est en partie due à son architecture de plan de service active-active distribuée à l’échelle mondiale.
Utiliser plusieurs serveurs de noms
Azure DNS attribue quatre serveurs de noms à chaque zone DNS publique. Lorsque vous délèguez votre domaine, configurez les quatre serveurs de noms. Si un programme de résolution ne peut pas atteindre un serveur de noms, il peut interroger un autre serveur.
Surveiller les pannes de service
Utilisez Azure Service Health pour surveiller l’intégrité de Azure DNS. Configurez les alertes Service Health pour vous avertir des incidents de service.
Tester les pannes de service
Azure Chaos Studio fournit des pannes qui simulent des échecs de résolution DNS au sein de certains types de charges de travail de test. Ces erreurs ne déclenchent pas de panne dans Azure DNS. L’agent Chaos Studio fournit l’erreur d’échec DNS et AKS Chaos Mesh fournit la fonctionnalité Chaos DNS. Utilisez ces erreurs pour tester la façon dont vos applications et votre infrastructure répondent en cas d’échec de la résolution DNS, par exemple lors d’une défaillance réseau partielle.
Résilience aux pannes des outils de gestion et du portail
Si vous gérez votre zone DNS publique dans le portail Azure, préparez un autre chemin de gestion pour les scénarios où vous ne pouvez pas accéder au portail, en particulier si vous devrez peut-être reconfigurer la zone pendant une panne.
Si le portail Azure n’est pas disponible, utilisez les Azure CLI, les Azure PowerShell ou l’infrastructure en tant que code (IaC) tel que Bicep ou Terraform pour gérer votre zone DNS publique. Ces outils restent opérationnels même si le portail Azure est détérioré.
Sauvegarde et restauration
Azure DNS est un service sans état. Il ne fournit pas de sauvegardes managées ni de restauration à un point dans le temps pour les zones DNS publiques.
Pour conserver la configuration complète des ressources Azure, définissez vos zones DNS publiques à l’aide d’IaC, telles que Bicep ou Terraform, et stockez les définitions dans le contrôle de code source. Testez régulièrement les définitions pour pouvoir les utiliser pour redéployer votre configuration.
En tant qu’option de récupération au niveau de l’enregistrement supplémentaire, exportez un fichier de zone compatible BIND. L'importation de fichiers de zone présente des limitations et ne conserve pas chaque paramètre de ressource spécifique à Azure. N'utilisez donc pas de fichier de zone exporté comme seul artefact de récupération. Passez en revue les limitations d’importation documentées et vérifiez les enregistrements après la restauration d’une zone.
Résilience à la maintenance du service
Microsoft applique régulièrement des mises à jour de service et effectue d’autres maintenances. La plateforme Azure gère automatiquement ces activités, ce qui garantit que la maintenance est fluide et transparente pour vous. Aucun temps d'arrêt n'est prévu pendant les événements de maintenance, sauf si vous avez été informé via la maintenance planifiée d'Azure Service Health.
Contrat de niveau de service
Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les SLA pour les services en ligne.
Azure DNS fournit un contrat SLA de disponibilité de 100% pour les réponses de requête DNS valides, tant que certaines conditions sont remplies. Ces conditions incluent les nouvelles tentatives de demandes ayant échoué à plusieurs reprises pendant au moins 60 secondes consécutives et l’utilisation de tous les serveurs de noms qui Azure DNS affecte à votre zone. Passez en revue le document SLA pour connaître les conditions détaillées.