Project

General

Profile

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

Added by Laurent Gourvenec 3 months ago. Updated 2 days ago.

Status:
Fermé
Priority:
Normal
Assigned To:
Start date:
11/23/2022
Due date:
% Done:

100%

Estimated time:
0.00 h
Remaining (hours):
0.0

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

Also available in: Atom PDF