Le Domain Name System (DNS) permet d’utiliser des noms facilement mémorisables plutôt que des adresses IP pour contacter des serveurs. Nous pouvons ainsi retenir google.fr à la place de 216.58.204.131. Ce qui pour nous, humains, est arrangeant.

Le DNS est composé de serveurs dédiés à cette tâche, que nous appelons Name Servers (NS). C’est concrètement ce qu’est une Hosted Zone du service Route53 sur AWS. Prenons par exemple le nom de domaine demo.fr : les NS sont en charge de distribuer la liste des entrées DNS. Celles-ci font le lien entre les “noms facilement mémorisables” et les adresses IP des serveurs qui répondent à un service. www.demo.fr et blog.demo.fr sont par exemple deux entrées DNS du domaine demo.fr.

Un NS peut tout à fait contenir la liste de toutes les entrées DNS d’un nom de domaine, par exemple demo.fr, www.demo.fr et blog.demo.fr. Est-ce que cela est toujours une bonne chose ? Pouvons-nous faire autrement ? C’est ce que nous allons voir.

La base de l’infra

Imaginons que nous ayons deux composants : une application App et un backend Backend.

Quels que soient les services utilisés pour l’hébergement, chacun de ces composants possède son load balancer (ALB).

Chaque ALB possède un nom DNS généré par AWS à la création. Celui-ci est directement utilisable, cependant nous préférons utiliser demo.fr et backend.demo.fr.

Un DNS pour les gouverner tous !

Le service Route53, via une Hosted Zone pour le nom de domaine demo.fr va nous permettre de mettre en place ce mécanisme.

Rendez-vous sur Route53 donc, pour créer cette Hosted Zone :

La Hosted Zone demo.fr est créée. Deux entrées DNS techniques, de type SOA et NS, sont automatiquement générées. À nous de créer nos deux entrées demo.fr et backend.demo.fr. Ces dernières sont de type A alias vers les noms DNS de nos ALB.

Le préfixe dualstack est automatiquement ajouté par AWS.

Maintenant imaginons que nous déployons aussi des versions de développement de notre application et backend. En général nous séparons les environnements de production des autres environnements. Fort heureusement, nos entrées DNS ne tiennent pas compte de l’environnement où sont hébergés nos services, ils pourraient même être hébergés on-premise ou chez d’autres fournisseurs cloud. Nous pouvons donc créer des alias vers les ALB de notre environnement de développement.

Ok. Tout fonctionne. Cependant il peut arriver que cette architecture atteigne ses limites.

Limites et délégation de zone

Il est très commun que les accès aux différents environnements soient cloisonnés. L’équipe A ayant les droits d’administration de toute l’infrastructure, donnera accès à l’équipe D seulement au compte de développement. Cela permet à l’équipe D d’être plus autonome, dans un cadre plus propice à la vélocité et à l’innovation. L’équipe D peut donc tester différents services et déployer de nouveaux composants à gogo, certes, mais est condamnée à utiliser les noms DNS à rallonge générés par AWS. Condamnée à valider leur nom de domaine via email lors de la génération des certificats...

Il est vrai, ça fonctionne.

Peut-on mieux faire ? Oui.

Évidemment nous pouvons tout simplement créer des tickets auprès de l’équipe A pour qu’elle ajoute les entrées DNS qui vont bien, leur envoyer un mail, ou même leur demander pendant la pause café.

Est-ce que c’est viable ? Oui, mais à quel prix ?

D’un temps certain, de ping-pongs entre l’équipe A et l’équipe D. Dans un environnement de développement les ressources sont amenées à être détruites puis recréées. Nouvelle ressource créée, nouveau nom DNS généré, entrée A alias à modifier…

Bref. Nous voyons là que c’est viable, mais pas tout à fait optimisé.

Et si nous donnions à l’équipe D la gestion de tout un sous-domaine, disons dev.demo.fr, sans pour autant leur donner accès à notre Hosted Zone ?

Voilà tout simplement ce qu’on appelle délégation de zone. Le fait de donner la responsabilité de l’ensemble d’un sous-domaine à une autre Hosted Zone (ou NS), ici créée dans notre compte de développement. Ainsi toutes les requêtes en *.dev.demo.fr reçues par la Hosted Zone principale seront transférées à la seconde Hosted Zone.

Mise en place

Comme pour notre Hosted Zone principale, rendez-vous sur Route53 :

La seconde Hosted Zone pour le sous-domaine dev.demo.fr est créée. Une nouvelle fois deux entrées DNS techniques, de type SOA et NS, sont générées.

Intéressons-nous de plus près à l’entrée NS : elle indique comment contacter cette Hosted Zone, ce Name Server. Ce sont donc ces valeurs que nous allons utiliser pour notre délégation de zone.

Retournons sur notre Hosted Zone principale, demo.fr. Nous devons renseigner d’une manière ou d’une autre que le sous-domaine dev.demo.fr est géré par un autre NS. Le mécanisme est le même que pour une entrée de type A alias, sauf que cette fois-ci nous créons une entrée de type NS.

La délégation de zone est en place !

Nous pouvons voir que le sous-domaine dev.demo.fr est maintenant géré par un autre NS, et que nos entrées pour notre domaine demo.fr sont toujours présentes sur celui-ci. Il suffira d’attendre plus ou moins longtemps que la propagation DNS se fasse.

Conclusion

La délégation de zone peut se révéler très utile. Dans le cas d’environnements de développement, si plusieurs équipes projet gèrent des applications différentes sous le même nom de domaine, ou encore si en tant que prestataire nous devons expliquer au client comment nous donner la main sur une partie de son domaine.

Sa mise en place est relativement simple, n’hésitez plus : déléguez.