Project

General

Profile

Evolution #179

Gestion des reverse DNS et des délégations

Added by Baptiste Jonglez over 7 years ago. Updated over 7 years ago.

Status:
En cours
Priority:
Normal
Target version:
Start date:
03/06/2014
Due date:
% Done:

30%

Estimated time:
5.00 h
Spent time:

Description

- Backend
- Intégration au LDAP
- Interface utilisateur


Related issues

Related to SI du FAI Illyse - Evolution #176: Design : intégration visuelle des donnéesEn coursOriane Piquer-Louis03/06/2014

Actions
Blocked by SI du FAI Illyse - Evolution #178: Intégrer les permissions Django à l'authentification LDAPNouveau03/06/2014

Actions
Blocks SI du FAI Illyse - Evolution #186: Script de régénération du LDAPNouveau04/08/2014

Actions
#1

Updated by Baptiste Jonglez over 7 years ago

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.

#2

Updated by Baptiste Jonglez over 7 years ago

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.

#3

Updated by Baptiste Jonglez over 7 years ago

  • Status changed from Nouveau to En cours
  • % Done changed from 0 to 30

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.

#4

Updated by Baptiste Jonglez over 7 years ago

  • Assignee set to Baptiste Jonglez

Travail restant :

  • Gestion des permissions (cf. #178) pour les objets NameServer

Il faudrait probablement leur rajouter un champ "utilisateur", et restreindre la relation ManyToMany de IPSubnet pour ne pouvoir lier qu'aux objets NameServer qui correspondent au même utilisateur.

  • Enregistrement des données dans le backend LDAP
  • Interface utilisateur
#5

Updated by Pierre-Arnaud Poudret over 7 years ago

Exemple de configuration du reverse d'une IPv4 dans le LDAP

Reverse de 89.234.140.241 configuré à rev-140-241.legacytubes.illyse.net. :

dn: dlzRecordID=1,dlzHostName=241,dlzZoneName=140.234.89.IN-ADDR.ARPA,ou=dns,o
=ILLYSE,l=Villeurbanne,st=RHA,c=FR
objectClass: dlzPTRRecord
dlzData: rev-140-241.legacytubes.illyse.net.
dlzHostName: 241
dlzRecordID: 1
dlzTTL: 10800
dlzType: ptr

Exemple de délégation du reverse d'une IPv4 dans le LDAP

Reverse de 89.234.140.242 délégué à grunt.fdn.fr :

dn: dlzRecordID=10,dlzHostName=242,dlzZoneName=140.234.89.IN-ADDR.ARPA,ou=dns,
o=ILLYSE,l=Villeurbanne,st=RHA,c=FR
dlzType: ns
objectClass: dlzNSRecord
dlzTTL: 86400
dlzRecordID: 10
dlzData: grunt.fdn.fr.
dlzHostName: 242

dlzRecordID ne signifie rien de particulier mais doit être unique pour un dlzHostName donné.

#6

Updated by Pierre-Arnaud Poudret over 7 years ago

Exemple de configuration du reverse d'une IPv6 dans le LDAP

dn: dlzHostName=2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0,dlzZoneName=0.4.1.
8.8.5.0.0.a.2.ip6.arpa,ou=dns,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR
objectClass: dlzHost
dlzHostName: 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0

dn: dlzRecordID=1,dlzHostName=2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0,dlzZ
oneName=0.4.1.8.8.5.0.0.a.2.ip6.arpa,ou=dns,o=ILLYSE,l=Villeurbanne,st=RHA,c=
FR
dlzRecordID: 1
dlzType: ptr
dlzTTL: 3600
objectClass: dlzPTRRecord
dlzData: arawak.illyse.net.
dlzHostName: 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0

Exemple de délégation du reverse d'un range IPv6 dans le LDAP

dn: dlzHostName=8.7,dlzZoneName=0.4.1.8.8.5.0.0.a.2.ip6.arpa,ou=dns,o=ILLYSE,l
=Villeurbanne,st=RHA,c=FR
objectClass: dlzHost
dlzHostName: 8.7

dn: dlzRecordID=10,dlzHostName=8.7,dlzZoneName=0.4.1.8.8.5.0.0.a.2.ip6.arpa,ou
=dns,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR
dlzType: ns
dlzData: grunt.fdn.fr.
objectClass: dlzNSRecord
dlzTTL: 86400
dlzRecordID: 10
dlzHostName: 8.7

#7

Updated by Baptiste Jonglez over 7 years ago

  • Target version set to 0.1
#8

Updated by Baptiste Jonglez over 7 years ago

Il y a une méthode pour déléguer le reverse DNS de blocs IPv4 plus petits que /24.

Voir page 122 du guide LIR du RIPE : http://www.ripe.net/lir-services/training/material/LIR-Training-Course/LIR-Handbook.pdf/view

Also available in: Atom PDF