WIP: rôle nameserver pour faire des serveurs DNS #3

Open
southerntofu wants to merge 4 commits from nameserver into master
Owner

Ceci est un brouillon. Ne pas merger immédiatement merci :)

L'approche générale du problème est décrite dans le README.md. On y trouve aussi des notes sur l'interopérabilité.

Version courte: bind9 + zones catalogue + TSIG + clé SSH + DNSSEC = <3

TODO:

  • configuration basique bind9
  • mise en place d'un système de peering entre serveur par SSH pour l'échange de secrets
  • génération des clés TSIG par paire de pairs, et échange des clés
  • signatures DNSSEC sur les domaines
  • délégation des sous-domaines aux utilisateurices localEs
Ceci est un brouillon. Ne pas merger immédiatement merci :) L'approche générale du problème est décrite dans le README.md. On y trouve aussi des notes sur l'interopérabilité. Version courte: bind9 + zones catalogue + TSIG + clé SSH + DNSSEC = <3 TODO: - [x] configuration basique bind9 - [ ] mise en place d'un système de peering entre serveur par SSH pour l'échange de secrets - [ ] génération des clés TSIG par paire de pairs, et échange des clés - [ ] signatures DNSSEC sur les domaines - [ ] délégation des sous-domaines aux utilisateurices localEs
Poster
Owner

Certains des changements introduits ici ne sont pas directement liés au rôle nameserver. En effet, pour pouvoir tester le rôle nameserver j'ai dû exécuter le playbook site.yml sur une VM de test.

Cette VM de test est une install fraiche de Debian Stable et sert donc de bonne mesure pour l'installabilité (ou bootstrappabilité si tu préfères) de notre playbook. Les changements qui ont lieu dans roles/common sont à cet effet.

Notes:

  • la VM de test n'a pas d'IPv4, du coup ça fait un bon test pour supporter des serveurs IPv6 seulement
  • il semblerait que cargo ne supporte pas l'IPv6 (un message comme quoi la connexion à github.com échoue) du coup pas la peine d'installer les paquets rust sur les machines IPv6
  • peut-être qu'il serait bien que les roles aient un minimum de paquets hardcodés (les dépendances explicites) et que le reste soit configuré dans les variables du playbook
Certains des changements introduits ici ne sont pas directement liés au rôle nameserver. En effet, pour pouvoir tester le rôle nameserver j'ai dû exécuter le playbook site.yml sur une VM de test. Cette VM de test est une install fraiche de Debian Stable et sert donc de bonne mesure pour l'installabilité (ou bootstrappabilité si tu préfères) de notre playbook. Les changements qui ont lieu dans roles/common sont à cet effet. Notes: - la VM de test n'a pas d'IPv4, du coup ça fait un bon test pour supporter des serveurs IPv6 seulement - il semblerait que cargo ne supporte pas l'IPv6 (un message comme quoi la connexion à github.com échoue) du coup pas la peine d'installer les paquets rust sur les machines IPv6 - peut-être qu'il serait bien que les roles aient un minimum de paquets hardcodés (les dépendances explicites) et que le reste soit configuré dans les variables du playbook
Poster
Owner

Dans les variables de configuration des NS secondaires, le mot "secondaire" est ambigu. Il peut indiquer qu'on se porte serveur secondaire pour un serveur primaire, ou qu'on demande à un serveur d'être notre serveur secondaire.

Pour lever l'ambiguité, on peut utiliser la forme:

vars:
  secondary:
    from: [ "peer1", "peer2" ]
    to: [ "peer1", "peer3" ]

En parallèle, on peut renommer primary en zones pour les zones primaires. C'est plus simple à retenir et à taper.

TODO: Pourrait-on trouver un nom plus simple pour renommer "secondary" ? "backup" semble correct, mais a une signification différente d'habitude. À creuser.

Dans les variables de configuration des NS secondaires, le mot "secondaire" est ambigu. Il peut indiquer qu'on se porte serveur secondaire pour un serveur primaire, ou qu'on demande à un serveur d'être notre serveur secondaire. Pour lever l'ambiguité, on peut utiliser la forme: ``` vars: secondary: from: [ "peer1", "peer2" ] to: [ "peer1", "peer3" ] ``` En parallèle, on peut renommer primary en zones pour les zones primaires. C'est plus simple à retenir et à taper. TODO: Pourrait-on trouver un nom plus simple pour renommer "secondary" ? "backup" semble correct, mais a une signification différente d'habitude. À creuser.
Poster
Owner

Si deux serveurs veulent se servir de NS secondaire l'un pour l'autre, alors il serait peut-être bien que chaque serveur se déclare d'abord comme NS secondaire pour l'autre, sans déclarer lui-même avoir de NS secondaire.

Comme ça tu peux tester le setup avec dig et si ça marche tu peux ajouter l'autre serveur à tes propres enregistrements NS.

Si deux serveurs veulent se servir de NS secondaire l'un pour l'autre, alors il serait peut-être bien que chaque serveur se déclare d'abord comme NS secondaire pour l'autre, sans déclarer lui-même avoir de NS secondaire. Comme ça tu peux tester le setup avec dig et si ça marche tu peux ajouter l'autre serveur à tes propres enregistrements NS.
This pull request has changes conflicting with the target branch.
README.md
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.