Suport technique et veille technologique

/home/lord (publications courtes)  -  Panne de DNS de Geeknode

 -  21 mars - 

Je pensais pas en faire un article d'autant plus que j'ai déjà pas mal parlé DNS mais au final… Ça ne prend la place de rien après tout et puis au moins ça me fait écrire un petit peu sur un truc que j'ai bien en tête.

La ptite histoire 🔗

Du coup voilà ce qui s'est passé. Un peu avant le weekend, on me signale que la résolution DNS pour les domaines de geeknode.org est HS. Et effectivement c'était plus très fonctionnel puisque le serveur DNS primaire ne répond plus au ping, la machine est a priori morte.

On ne s'en est pas rendu compte très vite (oui le monitoring toussa) puisque ça fonctionnait grâce au secondaire. Sauf que le serveur secondaire au bout d'un moment il bosse plus si le primaire est HS trop longtemps. Et de toute façon, je n'ai pas la main sur le serveur secondaire.

Il faut dire que l'infra de Geeknode est particulière. Rien n'appartient à Geeknode. Non ce sont des machines/vm fournies par des membres ou des assos amies. Qui plus est, Geeknode étant une asso (d'irc qui plus est), l'implication et la motivation de chacun est très fluctuante. Tout cela pour dire que la personne ayant la main sur le DNS primaire n'est pas connectée et on a pas de moyen de la contacter.

Le pansement 🔗

Bref, n'ayant pas de nouvelles pour l'accès à la machine, on a pris la décision dans un premier temps de remonter un serveur DNS primaire.

Connexion au registrar, ajout de glu pour le nouveau primaire. Connexion à mon serveur où je crée une nouvelle zone pour Geeknode. Test de la résolution du SOA : ✅ ça marche.

Bon maintenant deuxième étape : reremplir la zone. N'ayant pas la main sur l'ancien primaire ni sur son secondaire. Là c'est un jeu de piste. Bon, pour retrouver les adresses des IRCD, on peut compter sur la config des IRCD eux-mêmes. Ils ont les IP rentrées en dures. C'est déjà une grande partie de faite. Pour d'autres enregistrements, j'ai pu m'aider du très cool site DNS History.

Bon, c'est bien c'est fonctionnel. Les utilisateurs peuvent de nouveau se connecter. Tout un tas d'anciens enregistrements sont passés à la trappe mais pour la plupart les machines ne sont plus joignables et plus utilisées. L'asso a quelques années au compteur et avec pas mal de legacy comme on dit. C'est l'occasion de faire le ménage.

La partie ACME pour les certificats 🔗

Maintenant, il faut remettre en place notre système pour les certificats LetsEncrypt.

On utilise le challenge DNS parceque l'on a du round robin sur le DNS. En gros irc.geeknode.org arrive sur plusieurs machines différentes, du coup on ne peut pas utiliser d'autres challenges. Qui plus est chaque machine génère son certificat en toute autonomie, on ne s'amuse pas à bouger les certifs d'une machine à l'autre. On utilise donc dehydrated qui va parler au primaire DNS pour ajouter les enregistrements dns temporaires du challenge.

En gros ça utilise nsupdate pour modifier la zone et bien entendu on sécurise le tout avec un peu de crypto. On a donc des clés privées/publiques sur chaque ircd et sur le primaire dns. Historiquement on avait un vieux Bind des familles qui n'aimaient que les antiquités. Mais là le nouveau primaire de secours utilise Knot. On va pouvoir en profiter pour utiliser de la crypto moins vieillotte mais ça sera dans un second temps.

Conf du primaire 🔗

La base de la base. On définit le domaine, le fichier contenant les enregistrements et on définit qu'elles vont utiliser un template pour appliquer les bouts de conf qu'on veut.

zone:
  - domain: geeknode.org.
    file: geeknode.org
    template: geeknode

  - domain: geeknode.net.
    file: geeknode.net
    template: geeknode

Le fameux template où l'on dégage dnssec (ça sera ptet dans un futur lointain mais faut pas trop espérer). On choisit d'utiliser une nouvelle ACL pour nos zones.

template:
  - id: geeknode
    dnssec-signing: off
    acl: ["acl_geeknode_letsencrypt"]
    

Et donc maintenant on définit l'ACL en question. En gros on donne le droit à des clés de faire des update de la zone. Donc les nsupdate sur ces zones avec les clés sélectionnées.

acl:
 - id: acl_geeknode_letsencrypt
    action: ["update"]
    key: [ hivane.geeknode.org. , fdn.geeknode.org. , united.geeknode.org. , wirefull.geeknode.org. ]

Il ne nous reste plus qu'à donner les clés et voilà. Donc oui ce sont des vieilles hmac-md5, mais ça va changer très bientôt. Il faut bien faire gaffe à l'id qui doit être le même que celui définit lors de la création de la clé.

  - id: hivane.geeknode.org.
    algorithm: hmac-md5
    secret: XXXXXXXXX
  - id: fdn.geeknode.org.
    algorithm: hmac-md5
    secret: XXXXXXXXX
  - id: united.geeknode.org.
    algorithm: hmac-md5
    secret: XXXXXXXXX
  - id: wirefull.geeknode.org.
    algorithm: hmac-md5
    secret: XXXXXXXXX

Conf des IRCD 🔗

Bon l'élément manquant est donc le hook de Dehydrated pour modifier la zone.

#!/usr/bin/env bash

#
# Example how to deploy a DNS challenge using nsupdate
#

set -x
set -e
set -u
set -o pipefail

NSUPDATE="nsupdate -k /notre/Khivane.geeknode.org.key"
DNSSERVER="193.106.119.12"
TTL=300

case "$1" in
    "deploy_challenge")
        ZONE=$(echo $2 | tail -c 13)
        printf "server %s\nzone %s.\nupdate add _acme-challenge.%s. %d in TXT \"%s\"\nshow\nsend\n" "${DNSSERVER}" "${ZONE}" "${2}" "${TTL}" "${4}" | $NSUPDATE
	sleep 10
        ;;
    "clean_challenge")
        ZONE=$(echo $2 | tail -c 13)
        printf "server %s\nzone %s.\nupdate delete _acme-challenge.%s. %d in TXT \"%s\"\nsend\n" "${DNSSERVER}" "${ZONE}" "${2}" "${TTL}" "${4}" | $NSUPDATE
        ;;
    "deploy_cert")
        # do nothing for now
        ;;
    "unchanged_cert")
        # do nothing for now
        ;;
    "startup_hook")
        # do nothing for now
        ;;
    "exit_hook")
        # do nothing for now
        ;;
    *)
        #echo Unknown hook "${1}"
        #exit 1
        ;;
esac

exit 0

Et maintenant 🔗

Voilà, ça remarche comme ça pour le moment. C'est du provisoire.

On verra si on remet la machine d'origine ou si l'on repart sur une nouvelle VM dédiée. A priori la seconde solution est envisagée vu l'absence de maîtrise de la VM.

C'est l'occasion de faire un énorme ménage dans la zone, on pourra mettre à jour les clés pour des trucs plus robustes et modernes. Ça ne fera pas de mal.

Et on essaiera de voir pour être un peu plus nombreux à pouvoir trifouiller la dite machine (bus factor trop élevé). Qui sait, ptet qu'on monitorera également nos serveurs DNS ?

par