Gestion des reverse DNS et des délégations

• Backend
• Intégration au LDAP
• Interface utilisateur

https://www.illyse.org/issues/179

Pour chaque range IP, l'abonné a le choix entre :

• définir directement des reverse DNS pour des IP du range
• définir des serveurs de nom à qui Illyse délègue la gestion des reverse DNS

Il faut aussi gérer les reverse par défaut. Pour IPv4, ce n'est pas très gênant de créer à l'avance tous les reverse possibles pour nos IP ; pour IPv6, ça l'est plus.

C'est un peu compliqué d'en faire un modèle.

Dans le cas d'une délégation, il faut associer un ou plusieurs serveurs de nom à un subnet.

Dans le cas d'une définition simple de reverse, il faut associer une ou plusieurs entrées "IP → nom" à un subnet.

Problème : avec Django, c'est compliqué de dire « Ce type d'objet est lié à ça OU à ça » (en fait, c'est une limitation des bases de données relationnelles)

Solutions possibles :

• mettre les deux ForeignKey, et à chaque modification de l'objet subnet, vérifier que l'une des deux relations est bien vide (chiant à faire)
• héritage : mettre une ForeignKey vers une classe abstraite ReverseDNSProvider, et faire deux classes dérivant de cette classe abstraite.

Solution beaucoup plus simple : un subnet est lié à la fois à des serveurs de nom et à des entrées simples sur des IP.

Il y a simplement un switch (booléen) qui indique quel est le mode actuel : délégation, ou reverses gérés par Illyse.

Avantages : simplicité ; on peut changer le mode sans perdre les données associées à l'autre mode (elles sont toujours dans le SI, elles ne sont simplement pas utilisées)

Inconvénient : il faut bien penser l'interface utilisateur pour que ce soit clair (e.g. ne pas demander de serveur de nom à qui déléguer lorsque le mode actuel est « géré par Illyse »). Ça demandera probablement de tweaker un peu les formulaires Django.