La délégation NS d'un sous-domaine, cet illustre inconnu
Par Mathieu le mardi 5 mars 2019, 09:15 - Informatique - Lien permanent
Un billet un peu technique aujourd'hui. Si vous travaillez dans le Web, vous n'êtes pas sans savoir que c'est le mécanisme des DNS qui fait en sorte que vos noms de domaine soient résolus en adresses vers votre hébergement.
Vous savez aussi peut-être ce qu'est une zone DNS. Une zone DNS est un bête fichier présent sur le serveur DNS, et qui contient l'ensemble des enregistrements du domaine1.
Vous savez aussi certainement ce qu'est un sous-domaine, par exemple pour le domaine example.com, des sous-domaines seraient :
- www.example.com
- test.example.com
- sousdomaine.example.com
Parfois, pour séparer les services, on souhaite aller encore plus loin et dédier un sous-domaine entier à une tâche, par exemple on souhaite faire en sorte que compta.example.com soit totalement indépendant, c'est à dire :
- Qu'on puisse recevoir sur l'email facturation@compta.example.com ,
- Qu'on puisse avoir des mini-sites dédiés sous ce sous-domaine, comme urssaf.compta.example.com ou creances.compta.example.com
- Que le sous-domaine puisse servir tout autre usage tel que permis par les DNS (enregistrements SRV, etc)
Bien sûr, ces usages sont possibles à partir de la zone DNS du domaine parent, mais à mesure que le sous-domaine grandit en indépendance (et donc en nombre d'enregistrements), il peut être nécessaire de poser les bases d'une délégation plus avancée, pour éviter de maintenir une zone avec tous les enregistrements. On peut aussi vouloir déléguer à un prestataire la gestion de ce sous-domaine.
Pour ce qui est des mini-sites, il est relativement simple de déclarer un wildcard pour rediriger tous les enregistrements d'un sous-domaine vers un même serveur. Mais lorsqu'on veut plus de souplesse, ou que l'on veut aussi déléguer tous les enregistrements de ce sous-domaine, un wildcard est trop "brutal" et pas toujours supporté par toutes les spécifications, il faut alors déléguer la zone via une délégation NS.
En deux images
le client transmet la requête à l'autre serveur et obtient l'enregistrement A.
En exemple
Prenons un exemple de la vie réelle. Sortez votre commande dig, et examinez le domaine pingveno.net :
dig +trace pingveno.net @8.8.8.8 pingveno.net. 172800 IN NS ns-197-a.gandi.net. pingveno.net. 172800 IN NS ns-150-b.gandi.net. pingveno.net. 172800 IN NS ns-153-c.gandi.net. ;; Received 733 bytes from 192.52.178.30#53(k.gtld-servers.net) in 46 ms pingveno.net. 3600 IN A xx.xx.xx.xx ;; Received 57 bytes from 217.70.187.154#53(ns-153-c.gandi.net) in 45 ms
Dans l'exemple ci-dessus, j'ai retiré les appels du root server car ils ne sont pas pertinents pour notre exemple. On constate que la requête est transmise aux serveurs de Gandi, qui répondent directement avec l'enregistrement A du domaine.
Nouvel exemple, avec le sous-domaine uname.pingveno.net :
dig +trace pingveno.net @8.8.8.8 pingveno.net. 172800 IN NS ns-197-a.gandi.net. pingveno.net. 172800 IN NS ns-150-b.gandi.net. pingveno.net. 172800 IN NS ns-153-c.gandi.net. ;; Received 737 bytes from 2001:501:b1f9::30#53(m.gtld-servers.net) in 114 ms pingveno.net. 3600 IN A xx.xx.xx.xx www.pingveno.net. 10800 IN CNAME pingveno.net. ;; Received 75 bytes from 217.70.187.154#53(ns-153-c.gandi.net) in 44 ms
Cette fois le serveur répond avec un CNAME vers pingveno.net, c'est la méthode "pas chère" de déléguer le sous-domaine à un autre enregistrement. Ce n'est pas un wildcard, puisque l'enregistrement est seul, mais le résultat aurait été le même avec un wildcard.
Enfin, essayons avec ishimaru.pingveno.net :
dig +trace ishimaru.pingveno.net @8.8.8.8 pingveno.net. 172800 IN NS ns-197-a.gandi.net. pingveno.net. 172800 IN NS ns-150-b.gandi.net. pingveno.net. 172800 IN NS ns-153-c.gandi.net. ;; Received 742 bytes from 192.41.162.30#53(l.gtld-servers.net) in 45 ms ishimaru.pingveno.net. 10800 IN NS a.ns.wellhosted.ch. ishimaru.pingveno.net. 10800 IN NS b.ns.wellhosted.ch. ;; Received 98 bytes from 213.167.230.151#53(ns-150-b.gandi.net) in 44 ms ishimaru.pingveno.net. 60 IN A xx.xx.xx.xx ishimaru.pingveno.net. 3600 IN NS b.ns.wellhosted.ch. ishimaru.pingveno.net. 3600 IN NS a.ns.wellhosted.ch. ;; Received 130 bytes from 2a03:2040:d:121::1#53(a.ns.wellhosted.ch) in 49 ms
Cette fois, le serveur a répondu en deux temps : il a indiqué un enregistrement NS sur le sous-domaine, puis le client (ici la commande dig) a continué la requête vers les serveurs indiqués dans l'enregistrement NS pour retourner finalement l'adresse IP.
C'est une délégation NS. Cela signifie que tout le sous-domaine (la zone complète) de ishimaru.pingveno.net n'est pas gérée par gandi.net, mais par a.ns.wellhosted.ch . De cette manière, le sous-domaine est totalement indépendant, et peut être utilisé pour tous les usages d'un domaine de niveau supérieur.
Conclusion
C'est tout, ce court article sert juste à démystifier l'enregistrement NS, qui est très peu souvent utilisé, d'une part par la méconnaissance de la plupart des "webdesigners" se contentant de pointer des sous-domaines en A ou en AAAA, et ensuite parce qu'il faut pouvoir déléguer à un serveur DNS, tous les prestataires ne sont pas équipés pour accueillir un domaine de cette façon.
Notes
1 : L'ensemble, ou presque, le serveur DNS ne portant que la zone sur laquelle il a autorité, tout le travail du client DNS consiste justement à interroger les serveurs DNS en cascade, pour arriver à l'enregistrement qui fait autorité. Pas d'exposé là dessus aujourd'hui, mais vous pouvez lire la doc.
