Depuis le 12 octobre, la fonctionnalité “DNS Private Resolver” est en disponible globale.
Cette nouvelle fonctionnalité représente une avancée intéressante dans le mode hybride.
Nous avons déjà abordé le sujet du DNS hybride dans l’article ci-dessous :
Souvenez-vous, pour que les machines non-Azure soient en mesure de résoudre les adresses IP des ressources connectées via “private endpoint”, le déploiement d’une VM hébergeant le rôle DNS est nécessaire. Ce serveur DNS est en mesure de résoudre au travers des “private DNS zones” et du service Azure DNS les enregistrements privés des “private endpoint”.
Azure “DNS Private Resolver”, est un service PaaS venant remplacer le(s) serveur(s) DNS hébergé(s) sur Azure.
Il convient d’avoir quelques connaissances dans les “private DNS zones” avant de se lancer dans l’implémentation de ce nouveau service.
Notons tout de même pour les plus avant-gardistes d’entre nous, ce service ne supporte pas IPv6. Uniquement IPv4.
Sommaire
Présence, disponibilité et coût du service
Présence du service
Le service “DNS Private Resolver” n’est à ce jour pas disponible dans toutes les régions Azurées. Au moment de la rédaction de cet article (15 octobre 2022), celui-ci est disponible dans les régions suivantes :
Normalement, la liste devrait s’étoffer dans le mois à venir.
Disponibilité du service
Concernant la résilience du service, de manière factuelle, celle-ci est au niveau de la région Azure.
Ce niveau de disponibilité est équivalent à celui des “Private DNS Zones”. Ce qui signifie qu’en cas de perte d’une région Azure, ce service sera par la même occasion indisponible.
Si l’on fait la comparaison avec un service de type IaaS. Pour obtenir le même niveau de disponibilité, il est nécessaire de déployer 2 ou 3 VM (selon le nombre de zones que possède la région) ainsi qu’un NLB en tête de ces VM.
Coût du service
Le coût du service, la grande question qui drive aujourd’hui bon nombre de décisions.
Et bien, celui-ci se situe autour des 375€ /mois. Dans un premier temps, je pense que nous avons tous eu la même réaction, c’est un peu cher pour un serveur DNS …
Mais si l’on se pense de plus près sur la question, et bien pas tant que ça.
Si l’on prend le coût de 2 ou 3 VM de type B2MS + NLB, pour avoir le même niveau de disponibilité, il faut compter environ 230€ /mois.
À cela viennent s’ajouter les coûts :
- de mise en place des 3 VM et du NLB.
- de configuration du rôle DNS.
- de maintenance des 3 VM + rôle (update, upgrade, sécurization …).
- la complexité de cette solution.
En mettant tout ces coûts cachés dans la balance, je dirais en toute bonne foi que la balance est à l’équilibre.
Si l’on ajoute la possibilité d’utiliser un langage unique (ARM, Terraform, Biceps …) pour déployer la solution PaaS en IaC versus l’ajout d’un langage comme Ansible ou PowerShell pour installer /configurer le rôle “DNS Server”. Je dirais que la balance penche plus du côté de la solution PaaS.
À vous de faire vos propres calculs.
J'héberge déjà un DC + DNS ou un server DNS dans Azure
Dans le cas où vous hébergez déjà des contrôleurs de domaine sur Azure et bien oui vous n’aurez pas de gros avantages à passer sur cette solution.
À part si :
- vous n’avez pas le même niveau de disponibilité (région).
- vous voulez simplifier votre architecture DNS AD.
- héberger proprement les “conditionnal forwarder” dans les zones AD.
- coller au plus prèt des bonnes pratiques.
- limiter l’adhérence de votre infrastructure à Active Directory.
Dans le cas où vous héberger déjà un serveur DNS dans Azure pour répondre à la problématique. Là aussi, il n’y a pas de gros avantage à tout changer.
À part si :
- vous n’avez pas le même niveau de disponibilité (région) que le service PaaS.
- vous souhaitez faire évoluer votre infrastructure vers les services PaaS.
- diminuer vos coûts de MCO (cf: chapitre sur les coûts).
- simplifier votre IaC.
Mais soyons honnête, la bascule vers le service “DNS Private Resolver” n’est pas une impérieuse nécessité dans ces cas de figure et je vous rejoins sur ce point.
De quoi se compose Azure DNS Private Resolver
Du point de vue réseau
Le service Azure DNS Private Resolver est composé de deux subnets distincts :
- Inbound endpoints : ce subnet est utilisé pour héberger les adresses IP qui seront utilisées par les clients du service DNS. En gros l’adresse IP à configurer sur les clients comme serveur DNS.
- Outbound endpoints : ce subnet est le backend du service DNS. Il est utilisé comme “client DNS” par le service “Azure DNS Private Resolver” pour joindre d’autres serveurs DNS afin d’effectuer la résolution de nom. Les endpoint de type outbound peuvent être liés à une ruleset (nous verrons les rulesets plus tard).
Ces subnets possèdent quelques restrictions :
- Taille entre “/28” et “/24”.
Être dédié à une instance du service “Azure DNS Private Resolver”.
- Être accessible par les clients du service (privilégier votre hub).
- Être délégués pour le service “Microsoft.Network/dnsResolvers”.
DNS Forwarding Rulesets
Les rulesets du service “Azure DNS Private Resolver” doivent être liées à un ou plusieurs “endpoint” de type outboind.
Une des subtilités se trouve ici. Une ruleset peut être liée à plusieurs endpoints alors qu’un endpoint ne peut être lié qu’à une seule règle.
La ruleset va être composée de rules. Ces règles permettent d’indiquer au service comment joindre tel ou tel domaine. En spécifiant pour un nom de domaine les serveurs DNS ayant une copie de la zone.
Pour qu’une ruleset soit exploitable depuis les asets Azure, il convient que :
- Les vnet (in et out) que compose le service “Azure DNS Private Resolver” soient accessibles depuis le client (vnet peering /routage).
- Les vnet (in et out) et les vnets (hub and spoke) qui hébergent les clients soient liée aux rulesets qu’ils doivent utiliser.
De plus nous noterons que :
- la limite de 25 rules par ruleset a été augmentée à 1000 depuis le passage en GA du service.
- une limite sur le nombre de vNet liés à 500.
Conclusion
Azure DNS Private Resolver, est belle est bien un serveur DNS au format PaaS avec ça mécanique et ses propres contraintes. Il ne faut surtout pas le confondre avec un proxy DNS comme celui du Firewall Azure.
Pour les machines On-Premise, vos serveurs DNS (ex :ADDS) transféreront les requêtes DNS via les “conditional forwarder” à ce service pour résoudre les enregistrements tels que :
- privatelink.database.windows.net
- privatelink.blob.core.windows.net
- …
Alors que vos machines Azure, interroge ce service au travers des rulesets pour résoudre vos ressources On-Premise par exemple via le service DNS de vos DC locaux. Un vrai serveur DNS avec uniquement des “conditional forwarder” !
Next step, la maquette pour implémenter ce service en mode hybride 🙂
Liens annexes
- https://azure.microsoft.com/en-us/updates/general-availability-azure-dns-private-resolver-hybrid-name-resolution-and-conditional-forwarding/
- https://learn.microsoft.com/en-us/azure/availability-zones/az-region#an-icon-that-signifies-this-service-is-foundational-foundational-services
- https://learn.microsoft.com/en-us/azure/dns/dns-private-resolver-overview#regional-availability
- https://learn.microsoft.com/fr-fr/azure/dns/tutorial-dns-private-resolver-failover
- https://learn.microsoft.com/en-us/azure/dns/private-resolver-hybrid-dns
