Délégation de domaine expliquée : Un guide complet de l’autorité DNS et de la gestion des sous-domaines

Que vous lanciez un nouveau site web, que vous fassiez évoluer une infrastructure complexe, ou que vous essayiez simplement de comprendre comment Internet résout les noms de domaine, la délégation de domaine est un concept que vous ne pouvez pas vous permettre de négliger. Elle se situe au cœur même du système de noms de domaine (DNS) et détermine comment l’autorité sur les noms de domaine est distribuée sur Internet.

Ce guide explique tout ce que vous devez savoir sur la délégation de domaine — ce qu’elle est, comment elle fonctionne, ses composants clés et les meilleures pratiques qui maintiennent votre infrastructure DNS fiable et performante.

Qu’est-ce que la délégation de domaine ?

La délégation de domaine est le processus de transfert du contrôle autoritaire sur un domaine ou un sous-domaine spécifique à un ensemble désigné de serveurs de noms. En termes pratiques, cela signifie dire à Internet : *« Pour les questions sur ce domaine ou ce sous-domaine, posez-les à ces serveurs de noms — ils sont responsables. »*

Lorsqu’une requête DNS est effectuée pour un domaine, les résolveurs suivent une chaîne d’autorité. La délégation de domaine définit cette chaîne. Sans elle, le système DNS — qui traite des milliards de requêtes chaque jour — n’aurait aucun moyen structuré de distribuer la responsabilité entre des millions de domaines.

La délégation de domaine n’est pas qu’une simple formalité technique. Elle affecte directement :

• La disponibilité du site web — une délégation incorrecte entraîne des échecs de résolution DNS
• La délivrabilité des e-mails — les enregistrements MX doivent être accessibles via des serveurs de noms correctement délégués
• La sécurité — une délégation mal configurée peut exposer les domaines au détournement ou à l’usurpation
• Les performances — une délégation bien structurée réduit la latence des recherches DNS

Si vous enregistrez un nouveau domaine et avez besoin d’une base fiable sur laquelle construire, l’enregistrement de domaine avec AlexHost vous donne un contrôle total sur vos paramètres DNS dès le départ.

Composants clés de la délégation de domaine

Comprendre la délégation de domaine nécessite de se familiariser avec ses éléments constitutifs. Chaque composant joue un rôle spécifique dans la hiérarchie DNS.

1. Le domaine parent

Le domaine parent est le domaine qui se situe au-dessus du domaine délégué dans la hiérarchie DNS. Il contient les enregistrements NS (serveur de noms) qui pointent les résolveurs vers les serveurs de noms autoritaires du domaine enfant.

Exemple : Si vous déléguez sub.example.com, le domaine parent est example.com. La zone DNS pour example.com contient les enregistrements NS qui délèguent l’autorité pour sub.example.com à un ensemble différent de serveurs de noms.

Au sommet de la hiérarchie se trouvent les serveurs de noms racine, qui délèguent l’autorité aux registres de domaines de premier niveau (TLD) (tels que .com, .net ou .org). Ces registres TLD, à leur tour, délèguent l’autorité aux serveurs de noms de votre registraire de domaines.

2. Le domaine enfant

Le domaine enfant est le domaine ou le sous-domaine qui est délégué — l’entité recevant l’autorité. Dans l’exemple ci-dessus, sub.example.com est le domaine enfant.

Les domaines enfants peuvent être :

• Des sous-domaines (par exemple, api.example.com, mail.example.com, shop.example.com)
• Des domaines de deuxième niveau entiers (par exemple, example.com délégué du registre TLD .com)

3. Enregistrements NS (enregistrements de serveur de noms)

Les enregistrements NS sont le mécanisme fondamental de la délégation. Ils spécifient quels serveurs de noms sont autoritaires pour un domaine ou un sous-domaine donné. Lorsqu’un résolveur DNS rencontre un enregistrement NS lors d’une recherche, il sait qu’il doit interroger ces serveurs de noms pour obtenir des informations supplémentaires.

; NS records in the example.com zone delegating sub.example.com
sub.example.com.    IN    NS    ns1.childnameserver.com.
sub.example.com.    IN    NS    ns2.childnameserver.com.

La meilleure pratique veut d’avoir au moins deux enregistrements NS (primaire et secondaire) pour assurer la redondance. Si un serveur de noms devient indisponible, l’autre continue à servir les réponses DNS.

4. Enregistrements de colle (Glue Records)

Les enregistrements de colle sont un type spécial d’enregistrement DNS qui résout un problème de dépendance circulaire courant. Considérez ce scénario :

• Vous voulez déléguer sub.example.com à ns1.sub.example.com
• Mais pour trouver ns1.sub.example.com, un résolveur doit d’abord interroger sub.example.com
• Cela crée une boucle infinie

Les enregistrements de colle résolvent ce problème en incluant l’adresse IP du serveur de noms directement dans la zone parent, contournant la recherche circulaire.

; Glue records in the example.com zone
ns1.sub.example.com.    IN    A    203.0.113.10
ns2.sub.example.com.    IN    A    203.0.113.11

Les enregistrements de colle sont obligatoires lorsque les serveurs de noms d’un domaine enfant sont eux-mêmes des sous-domaines de ce domaine enfant. Ils sont stockés au niveau du registraire de domaines et servis par le registre TLD.

5. Enregistrement SOA (Start of Authority)

Chaque zone déléguée doit avoir un enregistrement SOA qui définit les informations administratives sur la zone, notamment :

• Le serveur de noms primaire
• L’adresse e-mail du responsable
• Le numéro de série (utilisé pour le versioning des transferts de zone)
• Les valeurs de rafraîchissement, de nouvelle tentative, d’expiration et de TTL minimum

L’enregistrement SOA signale qu’une zone est correctement configurée et autoritaire.

Comment fonctionne la délégation de domaine : résolution DNS étape par étape

Lorsqu’un utilisateur tape sub.example.com dans son navigateur, un processus de résolution sophistiqué se déploie en arrière-plan. Voici exactement ce qui se passe :

Étape 1 : Requête du résolveur récursif

L’appareil de l’utilisateur envoie une requête DNS à un résolveur récursif — généralement exploité par son fournisseur d’accès Internet ou un fournisseur DNS public comme Google (8.8.8.8) ou Cloudflare (1.1.1.1). Le travail du résolveur est de trouver la réponse en interrogeant la hiérarchie DNS.

Étape 2 : Recherche du serveur de noms racine

Si le résolveur n’a pas la réponse en cache, il interroge l’un des 13 clusters de serveurs de noms racine. Les serveurs racine ne connaissent pas l’adresse IP de sub.example.com, mais ils savent quels serveurs de noms sont autoritaires pour le TLD .com.

Root Server Response:
.com is handled by:
a.gtld-servers.net.
b.gtld-servers.net.
[...etc]

Étape 3 : Recherche du serveur de noms TLD

Le résolveur interroge les serveurs de noms TLD .com. Ces serveurs savent quels serveurs de noms sont autoritaires pour example.com (tel qu’enregistré via votre registraire de domaines).

TLD Server Response:
example.com is handled by:
ns1.registrar.com.
ns2.registrar.com.

Étape 4 : Recherche du serveur de noms du domaine parent

Le résolveur interroge ns1.registrar.com (le serveur de noms autoritaire pour example.com). Ce serveur contient les enregistrements NS pour la délégation de sub.example.com.

Parent Domain Response:
sub.example.com is delegated to:
ns1.childnameserver.com.
ns2.childnameserver.com.

Étape 5 : Recherche du serveur de noms du domaine enfant

Le résolveur interroge maintenant ns1.childnameserver.com — le serveur de noms autoritaire pour sub.example.com. Ce serveur retourne les enregistrements DNS réels demandés, tels qu’un enregistrement A (adresse IP) ou un enregistrement MX (serveur de messagerie).

Child Name Server Response:
sub.example.com.    IN    A    198.51.100.42

Étape 6 : Réponse livrée

Le résolveur récursif retourne l’adresse IP au navigateur de l’utilisateur, qui établit ensuite une connexion au serveur web à cette adresse. L’ensemble du processus se termine généralement en millisecondes.

Chaque étape de cette chaîne représente une délégation d’autorité — de la racine au TLD au registraire aux serveurs de noms de votre fournisseur d’hébergement.

Comment déléguer un domaine ou un sous-domaine : étapes pratiques

Que vous déléguiez un domaine entier à un nouveau fournisseur d’hébergement ou que vous sépariez un sous-domaine dans une zone DNS distincte, le processus suit un modèle cohérent.

Étape 1 : Identifier les serveurs de noms cibles

Déterminez quels serveurs de noms seront autoritaires pour le domaine enfant. Ceci est généralement fourni par :

• Votre fournisseur d’hébergement (par exemple, ns1.alexhost.com, ns2.alexhost.com)
• Un service de gestion DNS dédié
• Votre propre infrastructure DNS auto-hébergée

Si vous exploitez vos propres serveurs et avez besoin d’un contrôle total sur votre environnement DNS, l’hébergement VPS d’AlexHost fournit l’accès root et la fiabilité réseau nécessaires pour exploiter des serveurs de noms autoritaires.

Étape 2 : Ajouter des enregistrements NS dans la zone parent

Connectez-vous au panneau de contrôle de votre registraire de domaines et accédez à la section de gestion DNS du domaine parent. Ajoutez des enregistrements NS pointant vers les serveurs de noms délégués.

Exemple — Délégation de shop.example.com à un environnement d’hébergement distinct :

shop.example.com.    3600    IN    NS    ns1.shophosting.com.
shop.example.com.    3600    IN    NS    ns2.shophosting.com.

Important : Définissez un TTL raisonnable (Time to Live). Un TTL de 3600 secondes (1 heure) est courant. Les TTL plus bas permettent une propagation plus rapide des modifications mais augmentent la charge des requêtes DNS.

Étape 3 : Ajouter des enregistrements de colle si nécessaire

Si les serveurs de noms de votre domaine enfant sont des sous-domaines du domaine enfant lui-même, contactez votre registraire pour ajouter des enregistrements de colle. Ceci se fait au niveau du registraire, pas dans votre fichier de zone DNS.

Étape 4 : Configurer la zone enfant

Sur les serveurs de noms délégués, créez la zone DNS pour le domaine enfant et ajoutez tous les enregistrements nécessaires :

; Zone file for shop.example.com
$ORIGIN shop.example.com.
$TTL 3600

@    IN    SOA    ns1.shophosting.com. admin.example.com. (
                  2024010101 ; Serial
                  3600       ; Refresh
                  900        ; Retry
                  604800     ; Expire
                  300 )      ; Minimum TTL

@    IN    NS     ns1.shophosting.com.
@    IN    NS     ns2.shophosting.com.
@    IN    A      198.51.100.42
www  IN    A      198.51.100.42
@    IN    MX  10 mail.shophosting.com.

Étape 5 : Vérifier la propagation

Les modifications DNS peuvent prendre de quelques minutes à 48 heures pour se propager mondialement, selon les valeurs TTL et le comportement de mise en cache. Utilisez des outils comme :

• dig (Linux/macOS) : dig NS shop.example.com @8.8.8.8
• nslookup (Windows) : nslookup -type=NS shop.example.com
• Outils en ligne : dnschecker.org ou whatsmydns.net

Délégation de domaine vs hébergement DNS : comprendre la différence

Ces deux concepts sont étroitement liés mais distincts :

Vous pouvez enregistrer un domaine auprès d’un fournisseur et le déléguer à des serveurs de noms exploités par un fournisseur complètement différent. C’est extrêmement courant — par exemple, enregistrer un domaine auprès d’un registraire bon marché mais héberger le DNS auprès d’un fournisseur qui offre des performances supérieures ou des fonctionnalités avancées.

Pour les entreprises qui ont besoin d’une messagerie professionnelle aux côtés de leur présence web, l’hébergement e-mail d’AlexHost s’intègre parfaitement à votre configuration DNS, garantissant une configuration correcte des enregistrements MX et une livraison fiable des messages.

Scénarios courants de délégation de domaine

Scénario 1 : Migration d’un domaine vers un nouveau fournisseur d’hébergement

Lors de la migration d’un hôte à un autre, vous mettez à jour les enregistrements NS chez votre registraire pour pointer vers les serveurs de noms du nouveau fournisseur. Les serveurs DNS du nouveau fournisseur deviennent alors autoritaires pour votre domaine.

Conseil clé : Configurez tous les enregistrements DNS sur les nouveaux serveurs de noms *avant* de modifier les enregistrements NS chez le registraire. Cela minimise les temps d’arrêt lors de la transition.

Scénario 2 : Délégation d’un sous-domaine à une plateforme SaaS

De nombreuses plateformes SaaS (par exemple, les plateformes de commerce électronique, les fournisseurs CDN) vous demandent de déléguer un sous-domaine à leurs serveurs de noms. Par exemple, déléguer shop.yourdomain.com à une plateforme de commerce électronique hébergée tout en gardant www.yourdomain.com sur votre hébergement principal.

Scénario 3 : Répartition de l’infrastructure entre plusieurs fournisseurs

Les grandes organisations délèguent souvent différents sous-domaines à différents fournisseurs d’infrastructure :

• api.example.com → Fournisseur cloud A
• cdn.example.com → Fournisseur CDN B
• mail.example.com → Infrastructure de messagerie dédiée

Cette architecture nécessite une gestion DNS minutieuse mais permet des choix d’infrastructure de meilleure qualité. Un serveur dédié peut servir d’ancrage fiable pour votre zone DNS primaire tandis que les sous-domaines sont délégués à des fournisseurs spécialisés.

Scénario 4 : Délégation DNS interne

Dans les environnements d’entreprise, les domaines internes (par exemple, corp.internal) sont souvent délégués à des serveurs DNS internes qui ne sont pas accessibles au public. Cela permet aux organisations de gérer les ressources internes (sites intranet, API internes, imprimantes) via la même infrastructure DNS que leurs domaines publics.

Considérations de sécurité dans la délégation de domaine

La délégation de domaine introduit plusieurs risques de sécurité que les administrateurs doivent atténuer activement.

DNSSEC (extensions de sécurité DNS)

DNSSEC ajoute des signatures cryptographiques aux enregistrements DNS, permettant aux résolveurs de vérifier que les réponses sont authentiques et n’ont pas été altérées. Lors de la délégation d’un domaine, DNSSEC nécessite :

1. Signer la zone enfant avec une clé de signature de zone (ZSK) et une clé de signature de clé (KSK)
2. Ajouter des enregistrements DS (Delegation Signer) à la zone parent
3. Établir une chaîne de confiance de la racine à votre zone

DNSSEC est fortement recommandé pour tout domaine traitant des données sensibles ou des transactions financières. Associez DNSSEC à un certificat SSL pour fournir à la fois la sécurité au niveau DNS et au niveau du transport pour votre domaine.

Prise de contrôle de sous-domaine

La prise de contrôle de sous-domaine se produit lorsque les enregistrements DNS d’un sous-domaine pointent vers une ressource (par exemple, un service cloud, un point de terminaison CDN) qui n’existe plus, permettant à un attaquant de réclamer cette ressource et de servir du contenu malveillant sous votre domaine.

Prévention :

• Auditez régulièrement les enregistrements DNS et supprimez les délégations obsolètes
• Surveillez les ressources non réclamées associées à vos sous-domaines
• Utilisez des outils de surveillance DNS qui alertent sur les modifications inattendues

Sécurité du compte registraire

Puisque la délégation de domaine est contrôlée au niveau du registraire, votre compte registraire est une cible de grande valeur. Protégez-le avec :

• Des mots de passe forts et uniques
• L’authentification à deux facteurs (2FA)
• Le verrouillage du registraire (également appelé verrouillage de domaine ou verrouillage de transfert) pour empêcher les transferts non autorisés

Empoisonnement du cache DNS

Les attaques par empoisonnement du cache tentent d’injecter des enregistrements DNS frauduleux dans les caches des résolveurs, redirigeant les utilisateurs vers des sites malveillants. DNSSEC est la principale défense contre ce vecteur d’attaque.

Meilleures pratiques pour la délégation de domaine

L’application de ces meilleures pratiques maintiendra votre infrastructure DNS sécurisée, fiable et maintenable.

✅ Utilisez plusieurs serveurs de noms

Configurez toujours au moins deux serveurs de noms pour la redondance. Idéalement, ils doivent être géographiquement distribués et exploités sur une infrastructure réseau distincte pour éliminer les points de défaillance uniques.

✅ Définissez les valeurs TTL appropriées

• TTL élevé (86400 secondes / 24 heures) : Réduit la charge des requêtes DNS et améliore les performances. À utiliser pour les enregistrements stables.
• TTL faible (300–900 secondes) : Permet une propagation plus rapide des modifications. À utiliser temporairement avant les migrations planifiées.

✅ Documentez toutes les modifications DNS

Maintenez un journal des modifications pour chaque modification DNS, notamment :

• Ce qui a été modifié
• Pourquoi cela a été modifié
• Quand cela a été modifié
• Qui a effectué la modification

Cette documentation est inestimable lors de la réponse aux incidents et des audits.

✅ Surveillez continuellement la santé DNS

Mettez en place une surveillance qui vous alerte sur :

• Les modifications inattendues des enregistrements NS
• Les échecs de résolution DNS
• Les modèles de requête inhabituels (DDoS potentiel ou reconnaissance)
• L’expiration des certificats (pertinent pour DNSSEC et SSL)

✅ Testez avant la propagation

Utilisez dig ou nslookup pour interroger directement vos nouveaux serveurs de noms avant de mettre à jour les enregistrements NS chez le registraire. Cela confirme que la zone est correctement configurée avant que la délégation ne soit mise en ligne.

# Query the new name server directly before delegation
dig A sub.example.com @ns1.childnameserver.com

✅ Implémentez DNSSEC

Activez DNSSEC sur tous les domaines accessibles au public, en particulier ceux traitant l’authentification, les paiements ou les données utilisateur sensibles.

✅ Auditez les délégations périodiquement

Examinez toutes les délégations NS trimestriellement. Supprimez les délégations pour les sous-domaines désaffectés et vérifiez que les délégations actives pointent toujours vers les serveurs de noms corrects et opérationnels.

Dépannage des problèmes courants de délégation de domaine

Problème : DNS ne se résout pas après la modification de la délégation

Cause : Les anciennes valeurs TTL causent la persistance des réponses en cache.

Solution : Attendez l’expiration du TTL précédent.