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.
- 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.
https://www.illyse.org/issues/179
Pour chaque range IP, l'abonné a le choix entre :
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 :
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.