Créer les relations issues des résultats DNS intégrés #79

Closed
opened 2026-07-22 12:19:07 +02:00 by fy59 · 0 comments
Owner

Créer les relations issues des résultats DNS intégrés

Description :

Objectif

Créer des relations explicites entre l’entité domaine interrogée et les entités intégrées depuis les résultats DNS.

Les relations doivent être créées uniquement après confirmation de l’utilisateur.

Relations initiales

Les correspondances minimales sont :

  • A : domaine → adresse IP, relation resolves_to ;
  • AAAA : domaine → adresse IP, relation resolves_to ;
  • CNAME : domaine → nom de domaine, relation aliases_to ;
  • NS : domaine → nom de domaine, relation uses_name_server ;
  • PTR : adresse IP → nom de domaine, relation resolves_to.

Les types DNS non pris en charge ne produisent aucune relation.

Fonctionnement attendu

Lors de l’intégration d’une proposition compatible :

  • rechercher ou créer l’entité cible ;
  • identifier l’entité source réellement sélectionnée dans le graphe ;
  • créer la relation DNS correspondante ;
  • réutiliser une entité cible déjà existante ;
  • ne pas créer une relation déjà présente ;
  • actualiser le graphe et la sidebar après succès.

Transaction

L’intégration des entités et des relations constitue une seule opération transactionnelle.

En cas d’échec :

  • aucune nouvelle entité ne doit rester enregistrée ;
  • aucune relation partielle ne doit rester enregistrée ;
  • une erreur compréhensible doit être affichée.

Traçabilité

La relation doit conserver au minimum :

  • son type DNS normalisé ;
  • un libellé compréhensible ;
  • une description indiquant l’outil dns.dig et la cible interrogée ;
  • un niveau de confiance indiquant qu’il s’agit d’un résultat OSINT à vérifier.

La provenance structurée complète reste réservée à la future migration du schéma OSINT.

Contrôle utilisateur

Avant confirmation, le dialogue doit indiquer la relation qui sera créée pour chaque proposition compatible.

Exemples :

example.org — resolves_to → 93.184.216.34
example.org — aliases_to → www.example.org

Une proposition sans relation compatible reste visible mais désactivée.

Critères d’acceptation

  • Chaque proposition compatible affiche la relation prévue.
  • La relation utilise l’entité sélectionnée comme source.
  • Une entité cible existante est réutilisée.
  • Une nouvelle entité cible est créée si nécessaire.
  • Les doublons de relations sont ignorés.
  • Entités et relations sont écrites dans une transaction unique.
  • Un échec annule toute l’opération.
  • Le graphe affiche les nouvelles relations après actualisation.
  • Annuler ne modifie pas SQLite.
  • Les règles de correspondance possèdent des tests unitaires.
  • Les nouvelles fonctions publiques respectent les commentaires Doxygen.
  • Tous les tests du projet passent.
# Créer les relations issues des résultats DNS intégrés Description : ## Objectif Créer des relations explicites entre l’entité domaine interrogée et les entités intégrées depuis les résultats DNS. Les relations doivent être créées uniquement après confirmation de l’utilisateur. ## Relations initiales Les correspondances minimales sont : - `A` : domaine → adresse IP, relation `resolves_to` ; - `AAAA` : domaine → adresse IP, relation `resolves_to` ; - `CNAME` : domaine → nom de domaine, relation `aliases_to` ; - `NS` : domaine → nom de domaine, relation `uses_name_server` ; - `PTR` : adresse IP → nom de domaine, relation `resolves_to`. Les types DNS non pris en charge ne produisent aucune relation. ## Fonctionnement attendu Lors de l’intégration d’une proposition compatible : - rechercher ou créer l’entité cible ; - identifier l’entité source réellement sélectionnée dans le graphe ; - créer la relation DNS correspondante ; - réutiliser une entité cible déjà existante ; - ne pas créer une relation déjà présente ; - actualiser le graphe et la sidebar après succès. ## Transaction L’intégration des entités et des relations constitue une seule opération transactionnelle. En cas d’échec : - aucune nouvelle entité ne doit rester enregistrée ; - aucune relation partielle ne doit rester enregistrée ; - une erreur compréhensible doit être affichée. ## Traçabilité La relation doit conserver au minimum : - son type DNS normalisé ; - un libellé compréhensible ; - une description indiquant l’outil `dns.dig` et la cible interrogée ; - un niveau de confiance indiquant qu’il s’agit d’un résultat OSINT à vérifier. La provenance structurée complète reste réservée à la future migration du schéma OSINT. ## Contrôle utilisateur Avant confirmation, le dialogue doit indiquer la relation qui sera créée pour chaque proposition compatible. Exemples : ```text example.org — resolves_to → 93.184.216.34 example.org — aliases_to → www.example.org ``` Une proposition sans relation compatible reste visible mais désactivée. ## Critères d’acceptation - [x] Chaque proposition compatible affiche la relation prévue. - [x] La relation utilise l’entité sélectionnée comme source. - [x] Une entité cible existante est réutilisée. - [x] Une nouvelle entité cible est créée si nécessaire. - [x] Les doublons de relations sont ignorés. - [x] Entités et relations sont écrites dans une transaction unique. - [x] Un échec annule toute l’opération. - [x] Le graphe affiche les nouvelles relations après actualisation. - [x] Annuler ne modifie pas SQLite. - [x] Les règles de correspondance possèdent des tests unitaires. - [x] Les nouvelles fonctions publiques respectent les commentaires Doxygen. - [x] Tous les tests du projet passent.
fy59 closed this issue 2026-07-22 12:20:47 +02:00
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: fy59/labfy-investigation#79
No description provided.