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

southerntofu · 2020-04-14T15:25:59Z

southerntofu commented

2020-04-14 15:25:59 +00:00

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

southerntofu commented

2020-04-14 15:36:44 +00:00

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

southerntofu commented

2020-04-14 15:56:37 +00:00

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.

southerntofu referenced this pull request

2020-04-14 16:16:43 +00:00

Gestion fine des paquets #4

southerntofu referenced this pull request

2020-04-14 17:07:15 +00:00

Héberger notre serveur de noms DNS #8

southerntofu referenced this pull request

2020-04-14 19:13:37 +00:00

Rédiger un manuel utilisateurice #19

southerntofu referenced this pull request

2020-04-14 19:15:52 +00:00

Rédiger un manuel administrateurice #20

~~southerntofu referenced this pull request 2020-04-14 19:53:46 +00:00~~

Échanger des secrets entre serveurs (peering) #23

southerntofu commented

2020-04-14 20:00:58 +00:00

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.