2e18724685
- 14 chapitres + annexe en Markdown (chapitres/), 99 étapes - Générateur WeasyPrint (build/build.py) : PDF générique ou personnalisé via --vars fichier.conf - PDF générique + PDF personnalisé srv1.skglobalinstitute.com - Commandes v-* vérifiées contre le code source HestiaCP 1.10.4 - 03-bis-hestiacp.md pointe vers le nouveau guide Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018J2PsVQ28oW4xEkWJpcU9G
116 lines
4.8 KiB
Markdown
116 lines
4.8 KiB
Markdown
# Héberger son propre DNS
|
||
|
||
Le serveur devient le serveur DNS de vos domaines. {{DOMAINE}} a ses propres serveurs de noms, `ns1.{{DOMAINE}}` et `ns2.{{DOMAINE}}`, déclarés chez le registrar par des **enregistrements glue**. Vos autres domaines, par exemple en `.ci`, utilisent ensuite ces mêmes serveurs de noms.
|
||
|
||
> [!WARNING] L'ordre compte
|
||
> Créez toujours la **zone DNS avant le domaine mail** : HestiaCP n'ajoute la clé DKIM que dans une zone qui existe déjà.
|
||
|
||
## Créer la zone du domaine principal
|
||
|
||
La zone appartient à {{CLIENT}}, comme le site et les mails de {{DOMAINE}}. Le modèle `child-ns` est prévu pour un domaine qui sert lui-même de serveur de noms : il crée les enregistrements `ns1` et `ns2` qui pointent vers {{IP}}.
|
||
|
||
```bash
|
||
sudo v-add-dns-domain {{CLIENT}} {{DOMAINE}} {{IP}}
|
||
sudo v-change-dns-domain-tpl {{CLIENT}} {{DOMAINE}} child-ns
|
||
```
|
||
|
||
> [!DANGER]
|
||
> Changer de modèle **efface les enregistrements ajoutés à la main**. Faites-le uniquement juste après la création, comme ici.
|
||
|
||
Ajoutez l'enregistrement du nom du serveur, dont dépendent le panel et son certificat :
|
||
|
||
```bash
|
||
sudo v-add-dns-record {{CLIENT}} {{DOMAINE}} {{HOST}} A {{IP}}
|
||
sudo v-list-dns-records {{CLIENT}} {{DOMAINE}}
|
||
```
|
||
|
||
> [!CHECK]
|
||
> La liste contient les NS `ns1.{{DOMAINE}}.` et `ns2.{{DOMAINE}}.`, les A `@`, `ns1`, `ns2`, `mail` et {{HOST}}, le CNAME `www`, le MX `mail.{{DOMAINE}}.`, le TXT SPF et le TXT `_dmarc`.
|
||
|
||
## Tester la zone sur le serveur
|
||
|
||
```bash
|
||
dig @{{IP}} {{DOMAINE}} SOA +short
|
||
dig @{{IP}} ns1.{{DOMAINE}} +short
|
||
dig @{{IP}} {{FQDN}} +short
|
||
```
|
||
|
||
> [!CHECK]
|
||
> La première commande affiche une ligne commençant par `ns1.{{DOMAINE}}.` ; les deux suivantes affichent {{IP}}.
|
||
|
||
## Déclarer les glue records chez OVH
|
||
|
||
Dans l'espace client OVH : **Web Cloud › Noms de domaine › {{DOMAINE}} › onglet GLUE › Ajouter**.
|
||
|
||
| Nom d'hôte | Adresse IP |
|
||
|---|---|
|
||
| `ns1.{{DOMAINE}}` | {{IP}} |
|
||
| `ns2.{{DOMAINE}}` | {{IP}} |
|
||
|
||
Ne mettez que l'IPv4 : l'IPv6 entrante est bloquée par le pare-feu (chapitre 4), donc une glue IPv6 rendrait le DNS injoignable pour une partie d'Internet.
|
||
|
||
## Basculer les serveurs DNS chez OVH
|
||
|
||
Toujours sur {{DOMAINE}} : **onglet Serveurs DNS › Modifier les serveurs DNS**. Remplacez les serveurs d'OVH par :
|
||
|
||
```text
|
||
ns1.{{DOMAINE}}
|
||
ns2.{{DOMAINE}}
|
||
```
|
||
|
||
> [!NOTE]
|
||
> OVH vérifie que vos serveurs répondent avant d'accepter le changement : c'est pour cela que la zone doit exister avant. La propagation prend de quelques heures à 48 h.
|
||
|
||
## Vérifier la délégation
|
||
|
||
Depuis le serveur ou votre ordinateur :
|
||
|
||
```bash
|
||
dig +trace NS {{DOMAINE}} | tail -n 8
|
||
dig NS {{DOMAINE}} +short
|
||
```
|
||
|
||
> [!CHECK]
|
||
> La fin du `+trace` montre `ns1.{{DOMAINE}}` et `ns2.{{DOMAINE}}` avec la réponse de {{IP}}. Un contrôle complet est possible sur <https://zonemaster.net>.
|
||
|
||
## Ajouter un autre domaine (ex. un .ci)
|
||
|
||
Pour un domaine de projet {{SITE}} enregistré chez un autre registrar, utilisez le modèle par défaut, qui inclut aussi les enregistrements SRV de la messagerie. Ses serveurs de noms seront ceux de l'utilisateur, c'est-à-dire `ns1.{{DOMAINE}}` et `ns2.{{DOMAINE}}`.
|
||
|
||
```bash
|
||
sudo v-add-dns-domain {{CLIENT}} {{SITE}} {{IP}}
|
||
sudo v-list-dns-records {{CLIENT}} {{SITE}}
|
||
```
|
||
|
||
Chez le registrar de {{SITE}}, remplacez ensuite les serveurs DNS par `ns1.{{DOMAINE}}` et `ns2.{{DOMAINE}}`. **Pas de glue** ici : elle ne sert que pour le domaine qui porte les serveurs de noms.
|
||
|
||
> [!NOTE]
|
||
> Si {{SITE}} est le même domaine que {{DOMAINE}}, cette étape est déjà faite : passez à la suite.
|
||
|
||
## Ajouter un sous-domaine dans le DNS
|
||
|
||
HestiaCP **ne crée pas** l'enregistrement DNS quand vous ajoutez un site en sous-domaine. Ajoutez-le vous-même avant de créer le site, puis vérifiez :
|
||
|
||
```bash
|
||
sudo v-add-dns-record {{CLIENT}} {{DOMAINE}} app A {{IP}}
|
||
dig @{{IP}} app.{{DOMAINE}} +short
|
||
```
|
||
|
||
## Activer DNSSEC (facultatif)
|
||
|
||
DNSSEC signe la zone pour empêcher la falsification des réponses DNS. HestiaCP ne l'autorise qu'en mode `hestia-zone`, un réglage de cluster sans effet sur un serveur seul.
|
||
|
||
```bash
|
||
sudo v-change-sys-config-value DNS_CLUSTER_SYSTEM hestia-zone
|
||
sudo v-change-dns-domain-dnssec {{CLIENT}} {{DOMAINE}} yes
|
||
sudo v-list-dnssec-public-key {{CLIENT}} {{DOMAINE}} shell
|
||
```
|
||
|
||
La dernière commande affiche l'enregistrement **DS**, avec le key tag, le flag 257, l'algorithme 13 et la clé publique. Chez OVH : **{{DOMAINE}} › onglet Enregistrements DS › Modifier**, puis copiez-y ces valeurs.
|
||
|
||
> [!DANGER] Désactiver DNSSEC dans le bon ordre
|
||
> Pour désactiver DNSSEC plus tard, supprimez **d'abord** le DS chez le registrar et attendez 48 h. Sinon le domaine devient injoignable. Sur un ancien serveur, OVH a déjà refusé un DS avec l'erreur « Error while checking DNSKEYS » : dans ce cas, réessayez plus tard ou contactez le support.
|
||
|
||
> [!CHECK]
|
||
> <https://dnsviz.net> affiche une chaîne de confiance verte pour {{DOMAINE}}.
|