Tâche #35005
Scénario #34941: [EOLE 2.9] Impossibilité d'instancier DC2 si un service podman est installé sur le DC1 avant instance
BIND : support des passerelles qui n'ont pas de support des cookies DNS
100%
History
#1 Updated by Laurent Gourvenec 3 months ago
Lorsqu'on redémarre le service 'named' sur un DC1 il est possible de faire des requêtes DNS pendant un certain temps (de l'ordre de la minute).
Après ce délai il n'est plus possible de faire des requêtes DNS.
En réalité on ne peut plus faire de requête dès qu'on retrouve l'erreur suivante dans les logs :
nov. 15 14:36:40 dc1.domseth.ac-test.fr named[34315]: missing expected cookie from 192.168.0.1#53
Si on ajoute l'option send-cookie no;
dans le fichier /etc/bind/named.conf.options, l'erreur n’apparaît plus et les requêtes sont tout le temps possible.
Si on remplace dnsmasq par un serveur bind sur la passerelle, il n'y a plus d'erreur non plus (sans modifier la configuration bind).
Le problème c'est que la gestion des cookies DNS n'est pas implémentée sur dnsmasq.
root@dc1:~# dig dev-eole.ac-dijon.fr | grep COOKIE ; COOKIE: 11cf8ac7386e412f0100000063739825f8992fd68cc27155 (good) root@dc1:~# dig @192.168.0.1 dev-eole.ac-dijon.fr | grep COOKIE root@dc1:~#
Informations complétementaires sur les cookies DNS : https://kb.isc.org/docs/aa-01387
Nous voyons deux solutions :
- désactiver la gestion des cookies dans la configuration de bind. Cela semble être une mauvaise idée de baisser la sécurité d'environnement avec des serveurs DNS gérant les cookies DNS ;
- proposer une options pour pouvoir désactiver les cookies DNS :
* les cookies DNS sont activés par défaut
* un diagnose qui vérifie si les cookies sont supportés par la passerelle (quelque chose comme
for dns in $(CreoleGet adresse_ip_dns); do dig @$dns +cookie $(CreoleGet test_distant_domaine) | grep -q "; COOKIE: " || echo "pas de support des cookies DNS pour $dns"; done
) * laisser le nouveau comportement même en cas de migration.
#2 Updated by Daniel Dehennin 2 months ago
Dans la documentation, il est noté que s’il n’y a pas de cookie, il y a un fallback TCP.
Le soucis semble venir de ce fallback qui ne fonctionne pas à travers la gateway:
root@gateway90:~# dig +tcp @192.168.232.2 dev-eole.ac-dijon.fr ;; Connection to 192.168.232.2#53(192.168.232.2) for dev-eole.ac-dijon.fr failed: timed out.
#3 Updated by Daniel Dehennin 2 months ago
- Status changed from Nouveau to En cours
- Assigned To set to Daniel Dehennin
- Start date set to 11/23/2022
Le problème semble se situer sur les machines virtuelle OpenNebula, je vais devoir inspecter toute la pile réseau.
#4 Updated by Daniel Dehennin 2 months ago
J’ai ouvert un ticket auprès des équipes du rectorat.
#5 Updated by Daniel Dehennin 2 months ago
- Status changed from En cours to Résolu
- % Done changed from 0 to 100
Jean-Philippe a corrigé une règle de parfeu qui n’autorisait que le DNS en UDP, il est désormais ouvert aussi en TCP.
#6 Updated by Laurent Gourvenec 2 months ago
- Status changed from Résolu to Fermé
- Remaining (hours) set to 0.0
Sur la maquette qui était en erreur il y 20 jours, je peux maintenant faire des requêtes DNS sans soucis.
#7 Updated by Joël Cuissinat 2 days ago
- Blocks deleted (Scénario #34941: [EOLE 2.9] Impossibilité d'instancier DC2 si un service podman est installé sur le DC1 avant instance)
#8 Updated by Joël Cuissinat 2 days ago
- Estimated time set to 0.00 h
- Parent task set to #34941