Passer au contenu 
Configuration DNS Hetzner de manière à ce que le site web, les sous-domaines et le courrier électronique fonctionnent sans détours et que les modifications prennent effet rapidement. Dans ce guide, je présente les réglages nécessaires dans le DNS Hetzner, un exemple de configuration éprouvé ainsi que des méthodes de contrôle pratiques, afin que tu puisses éviter les erreurs à un stade précoce et que ta zone reste propre.
Points centraux
Les points clés suivants te donnent un aperçu rapide de ce qui est important pour une zone DNS fiable.
- Serveur de noms s'inscrire correctement auprès du registraire
- A/AAAA pour le web, MX/TXT pour le courrier
- TTL choisir le bon et attendre la propagation
- SPF/DKIM contre le spam et le spoofing
- Suivi et tests après modifications
Le DNS en bref : ce dont tu as vraiment besoin
J'attribue à un domaine Records des objectifs concrets pour que les navigateurs et les serveurs de messagerie trouvent mes services. Un A-Record pointe vers une adresse IPv4, un AAAA vers IPv6 et un MX définit la distribution des e-mails. Un CNAME constitue un alias qui pointe vers un autre nom, tandis que TXT fournit des indications pour SPF ou des vérifications. Une ligne de base propre se compose de A/AAAA pour le domaine principal, CNAME pour www, MX pour Mail et un SPF-TXT. Je garde ainsi la zone claire, rapidement maintenable et ouverte à des extensions ultérieures.
Ajouter un domaine à la console DNS Hetzner
Dans la console DNS, je commence par créer un nouveau Zone et vérifie que l'orthographe du domaine est exacte. Ensuite, j'active la gestion manuelle de RecordsJe peux ainsi créer et modifier des entrées de manière ciblée. Astuce : je note au préalable les adresses IP et les destinations des e-mails afin de tout inscrire sans interruption. J'évite ainsi les fautes de frappe et je place les entrées dans un ordre tranquille. Dès que la zone est prête, je planifie le changement des serveurs de noms et les vérifications qui s'ensuivent.
Inscrire correctement le serveur de noms auprès du registraire
Après avoir créé la zone, j'inscris auprès du registraire la Serveur de noms de Hetzner, afin que la gestion soit centralisée dans la console DNS. Les entrées habituelles sont ns1.first-ns.de, robotns2.second-ns.fr et robotns3.second-ns.com. Pour les domaines .de ou .at, je mets en place, si nécessaire, mes propres serveurs de noms avec Glue-Recordspour que les références et les IP soient enregistrées. Pour ceux qui n'ont jamais fait cela, les différentes étapes sont décrites dans le guide de Configurer les enregistrements Glue. Je me laisse ensuite un peu de temps pour la conversion, car la mise à jour peut arriver à des vitesses différentes dans le monde entier.
Exemple de configuration : rendre le site web et le courrier électronique opérationnels
Pour une présence typique sur le web, je mets en place un A-Record pour le domaine racine, un CNAME pour www et des enregistrements de messagerie appropriés. Un SPF-TXT empêche les serveurs étrangers d'envoyer des e-mails au nom du domaine. En option, j'ajoute un enregistrement AAAA au cas où le serveur web IPv6 est mis à disposition. Pour les services de messagerie externes comme ForwardMX, j'adapte le MX et j'enregistre leurs spécifications. Le tableau suivant montre une base de départ solide pour de nombreuses configurations.
| Nom | Type | Valeur | Remarque |
|---|---|---|---|
| @ | A | 195.201.210.43 | Serveur web IPv4 |
| @ | AAAA | Facultatif : 2a01:4f8:xxxx:xxxx::1 | Serveur web IPv6 |
| www | CNAME | @ | Alias à la racine |
| @ | MX | mx1.forwardmx.net | Prio 10 |
| @ | TXT | "v=spf1 include:_spf.forwardmx.net -all" | SPF contre le spoofing |
Activer le DNSSEC et définir l'enregistrement DS
Si la sécurité de manipulation est importante pour moi, j'active DNSSEC pour la zone. Dans la console Hetzner, je génère pour cela des clés de signature et j'obtiens ensuite les données nécessaires. Données DSque je dépose auprès du registraire. Je vérifie que l'algorithme et le digest ont été correctement repris. Ensuite, j'attends que la chaîne du registraire à la zone soit validée proprement. Avant les grandes rotations de clés, j'abaisse le TTL et je prévois une fenêtre de temps pour que les résolveurs voient les nouvelles signatures à temps. Important : si une erreur se produit pendant le changement, les validations échouent chez les destinataires - je tiens donc un rollback à disposition (ne pas supprimer les anciennes clés trop tôt) et je teste avec des résolveurs de validation.
Définir correctement le TTL et comprendre la propagation
Le TTL détermine la durée de mise en cache d'une entrée par le résolveur. Pour les changements, je choisis une courte TTL (par exemple 300 secondes) pour que les changements soient rapidement visibles. Après la configuration finale, j'augmente à nouveau les valeurs afin d'économiser les requêtes et d'obtenir une résolution uniforme. Ceux qui déploient souvent restent volontiers à 600-1200 secondes, ceux qui modifient rarement utilisent 3600-14400. Un aperçu pratique pour prendre une décision est fourni par mon regard sur la sélection optimale du TTL.
Domaine Apex, CAA et certificats sous contrôle
Pour les objectifs SaaS le Zone Apex je pense que CNAME n'est pas autorisé sur @. J'utilise donc les A/AAAA du fournisseur ou je mets une redirection vers www au niveau du serveur web. Pour l'attribution des certificats, je contrôle avec CAA-Recordsquelles CA sont autorisées à émettre des certificats. Je ne gère par exemple que l'AC que j'utilise effectivement et j'ajoute en option une adresse e-mail pour les rapports. Si je change d'AC, j'augmente brièvement le TTL et j'actualise CAA avant l'émission. Pour les wildcards via ACME DNS-01, je m'assure que les enregistrements TXT sous _acme-challenge être rapidement définis et automatiquement nettoyés afin d'éviter que d'anciens challenges ne restent en suspens.
Créer proprement des sous-domaines et des services
Pour chaque sous-domaine, je crée un nom de domaine correspondant. A- ou bien CNAMEselon que le sous-domaine pointe directement sur une IP ou sur un nom. Exemple : blog.exemple.fr comme A-Record vers la VM du blog, cdn.exemple.fr comme CNAME vers un nom de CDN. Pour les API, je sépare strictement les noms internes et publics afin d'éviter les risques. Des noms uniformes comme api, app, img aident à la maintenance et au monitoring. Ainsi, je garde la zone structurée et je peux clairement attribuer les modifications.
Wildcards, SRV et types d'enregistrements spéciaux
J'utilise Enregistrements Wildcard (*.example.de), par exemple pour les configurations multi-clients. Je veille à ce que les entrées exactes aient toujours la priorité sur les caractères génériques. Pour les services tels que SIP, Matrix ou Autodiscover, je crée au besoin des Enregistrements SRV et vérifie le format et les priorités. Enregistrements TXT avec des contenus longs (par ex. DKIM 2048 bits), je les divise en plusieurs segments de guillemets pour que les analyseurs puissent les assembler correctement. J'évite les enregistrements SPF multiples et je combine les entrées en un SPF valide afin de ne pas rompre la limite de recherche.
Livrer les e-mails de manière fiable : SPF, DKIM et DMARC
Pour les e-mails de confiance, je mets en plus du MX un SPF-TXT propre qui couvre mes systèmes émetteurs. En outre, j'active DKIM auprès du service de messagerie utilisé et publie le sélecteur DKIM au format TXT sous selector._domainkey. Avec DMARC, je définis comment les destinataires traitent les messages qui ne passent pas SPF/DKIM. Je commence souvent avec "p=none", j'évalue les rapports et je passe plus tard à "quarantine" ou "reject". Cet ordre permet de réduire les risques et d'améliorer progressivement la qualité de la distribution.
Approfondir SPF/DKIM/DMARC dans la pratique
Je garde le SPF aussi léger que possible : seulement les include-et jamais plus d'un SPF par nom d'hôte. Pour respecter la limite de 10 lookups DNS, je réduis les chaînes ou j'utilise des mécanismes IP4/IP6 lorsqu'ils sont stables. Pour Rotation des DKIM j'exploite deux sélecteurs actifs (ancien/nouveau), je publie la nouvelle clé, je commute le service de messagerie et je ne supprime l'ancienne qu'après quelques jours. Chez DMARC je définis initialement des adresses de rapport (rua/ruf) et je vérifie l'alignement (aspf/adkim). Pour les sous-domaines, je peux utiliser sp= définir une politique propre lorsqu'ils envoient séparément. Ainsi, je réagis à des données de trafic réelles plutôt qu'à des suppositions.
Reverse DNS (PTR) pour une distribution propre du courrier électronique
En plus de MX, SPF et DKIM, je mets en place DNS inversé (PTR) pour les serveurs de messagerie sortants. Le PTR de l'IP pointe vers un nom d'hôte qui, à son tour, se résout correctement par A/AAAA sur la même IP (Match à terme/à l'envers). Je définis PTR par IP directement auprès du propriétaire de l'IP (par ex. dans l'interface du serveur) - pas dans la gestion des zones du domaine. Pour IPv6, j'utilise le format nibble. Un PTR adapté réduit les classements de spam et contribue à la réputation. Si le courrier passe par un service externe, je laisse son PTR tel qu'il est défini et j'évite les sources d'envoi mixtes sans adaptation du SPF.
Erreurs typiques et solutions rapides
Si un domaine ne se résout pas, je vérifie d'abord TTLLes enregistrements du serveur de noms et l'orthographe correcte des enregistrements. Le deuxième regard se porte sur les PropagationCertains résolveurs mettent plus longtemps en cache, surtout après des augmentations TTL. Je compare la résolution via différents DNS-checkers pour identifier les différences régionales. En cas de problèmes locaux, je passe temporairement à des résolveurs publics comme 1.1.1.1 ou 8.8.8.8. Si l'erreur ne se produit que sur des réseaux internes, je contrôle les résolveurs internes et les règles dans les conteneurs, Kubernetes ou les configurations CoreDNS.
Méthodes de contrôle : dig, nslookup et end-to-end
Je ne teste pas seulement les enregistrements, mais le chemin complet :
- dig A/AAAA/CNAME/MX/TXT : vérifier les réponses, TTL et l'autorité
- dig +tracevoir la chaîne de délégation et le comportement des nameservers
- Tests SMTPvérifier HELO/EHLO, TLS et bannière
- HTTPS réel: chaîne de certificats, nom d'hôte, redirections
Cela me permet de détecter des erreurs qui ne sont pas visibles dans les réponses DNS pures, comme des mappings VirtualHost incorrects ou des certificats qui expirent. Après des modifications, j'attends au moins un TTL avant de tirer des conclusions définitives.
Travailler efficacement avec la console Hetzner
Je regroupe des objets associés Entrées Je fais un petit TTL avant de faire des changements importants, puis je publie le tout en une seule fois. Avant de sauvegarder, je vérifie encore une fois MX-priorités, la syntaxe SPF et l'IP de destination de l'enregistrement A. Pour l'administration du serveur et les procédures, les indications compactes sous Conseils Hetzner Robot. Après les déploiements, je teste http, https et mail avec des requêtes réelles, pas seulement via ping. Cela me permet de détecter des erreurs que les requêtes DNS pures ne montrent pas.
Automatisation : API, modèles et ACME
Je gagne du temps grâce à l'automatisation. Pour les déploiements réguliers, j'utilise les API de la console DNS pour créer, modifier ou supprimer des enregistrements. Je travaille avec des modèles pour les modèles récurrents (par exemple, Web + Mail + DMARC) et je n'insère que des valeurs spécifiques au projet. Pour Let's Encrypt DNS-01, j'intègre un enregistreur TXT automatisé et je l'intègre dans le flux de travail de renouvellement. Important : je traite les jetons d'API comme des mots de passe, je les attribue à des projets spécifiques et je retire les accès lorsqu'ils ne sont plus nécessaires.
Configurations avancées : Split-Horizon, CDN et ACME
Pour les utilisateurs internes et externes, je sépare si nécessaire DNS-pour que l'application interne pointe sur des IP privées et les visiteurs sur des destinations publiques. Est-ce que j'utilise un CDNje renvoie les sous-domaines au nom du CDN par CNAME et j'y active TLS. Pour les certificats automatiques via ACME/Let's Encrypt, je définis en option des DNS-01 Challenges via TXT, si HTTP-01 ne convient pas. L'automatisation est importante ici, afin que les renouvellements se fassent à temps. Les journaux et les notifications permettent de détecter à temps les pannes.
Modèles de performance et de disponibilité
J'augmente la disponibilité avec des moyens simples : Plusieurs Enregistrements A/AAAA (round-robin) partagent la charge sans services supplémentaires, à condition que les backends soient sans état ou partagent des sessions. En cas de maintenance, je supprime temporairement certaines IP et relève ensuite l'entrée. Une exécution TTL continue trop courte peut solliciter les résolveurs ; je trouve un juste milieu entre la vitesse de réaction et le taux d'occurrence du cache. Pour le basculement sans contrôle de santé, je définis des processus clairs : En cas de panne, j'échange des entrées, je les surveille activement et je les réinitialise après le rétablissement.
Sécurité et hygiène de zone
Je désactive les Transferts de zones (AXFR) et ne publie que les NSqui font vraiment autorité. Je supprime régulièrement les anciens sous-domaines ou les sous-domaines orphelins afin d'éviter les zones d'ombre. Pour les IDN, je vérifie les Punycode-afin d'éviter les fautes de frappe et les erreurs de caractères spéciaux. Les accès basés sur les rôles dans la console garantissent que seules les bonnes personnes modifient les zones. Et de manière très pragmatique : je documente brièvement les modifications dans l'outil d'équipe - cela réduit considérablement les demandes de précisions dans l'entreprise.
Stratégie de migration et de retour en arrière
Avant un déménagement, j'abaisse le TTL (24-48 heures avant), je fais un miroir de tous les Records dans la nouvelle zone et teste directement la résolution via les nouveaux serveurs de noms. Ce n'est que lorsque tout est correct que je place les Serveur de noms auprès du registraire. Après la délégation, j'observe le trafic et les erreurs. Si quelque chose ne va pas, je fais un retour en arrière contrôlé ou je corrige certaines entrées de manière ciblée. Pour les transferts DNSSEC, je planifie de manière particulièrement conservatrice et laisse l'ancienne chaîne de signature en place jusqu'à ce que la nouvelle soit sûre. Pour finir, je réinitialise le TTL à des valeurs adaptées à la production.
Brève comparaison des fournisseurs pour la performance et la flexibilité
Performance, fonctions et Liberté DNS décider de la flexibilité avec laquelle je déploie les projets. Dans la pratique, les grands hébergeurs fournissent de solides Temps de réponseMais ils se distinguent par leur utilisation, leurs fonctionnalités et leur assistance. J'évalue la sélection en fonction des performances, des fonctionnalités, de la qualité de l'aide et des options DNS. L'aperçu suivant présente une image condensée que je peux utiliser pour prendre des décisions. Au final, ce qui compte, c'est ce dont mon projet a vraiment besoin, pas la plus grande liste de fonctionnalités.
| Fournisseur | Performance | Étendue des fonctions | Soutien | Flexibilité du DNS | Classement |
|---|---|---|---|---|---|
| webhoster.de | Haute | Très complet | Top | Maximum | 1 |
| Hetzner | Haute | Vaste | Bon | Haute | 2 |
| Contabo | Moyens | Standard | O. K. | Moyens | 3 |
En bref
Je mets une DNS Hetzner-La zone est structurée : Créer la zone, inscrire le serveur de noms auprès du registraire, définir les enregistrements de base pour le web et le courrier, puis tester. Avec un TTL je raccourcis les temps de conversion et augmente à nouveau après la fin pour une charge moindre. SPF, DKIM et DMARC renforcent la livraison et protègent le domaine contre les abus. Je garde les sous-domaines cohérents et je sépare les destinations internes des destinations publiques. Grâce à cet exemple de configuration et aux contrôles effectués au quotidien, ta configuration hetzner dns reste fiable, rapide et facile à entretenir.
