Détails
| Détails |
|
Proposition
1. Résumé du problème traité par cette proposition
1.1.Contexte: qu'est-ce que la «délégation de boiteux»?
Dans le DNS, une délégation boiteuse est un type d'erreur de mauvaise configuration DNS qui se produit lorsqu'un serveur de noms désigné comme serveur faisant autorité pour un nom de domaine ne renvoie pas de données faisant autorité pour ce nom, lorsqu'il est interrogé. Par exemple, si un serveur de noms se voit déléguer la responsabilité de fournir un service de noms pour une zone (via des enregistrements NS) et qu'il ne le fait pas réellement, c'est-à-dire que le serveur de noms n'est ni configuré en tant que serveur principal ni secondaire, ou ne répond pas, alors l'enregistrement NS est considéré comme «boiteux» (RFC1912 [2]).
1.2. Impact des délégations Lame dans le DNS mondial
Dans les zones in-addr.arpa et ip6.arpa, conformément à cette politique, les enregistrements DNS considérés sont des enregistrements NS (comme dans l'exemple ci-dessus), déléguant l'autorité plus bas dans la chaîne d'autorité. Avec une telle délégation entraînant des réponses boiteuses, le problème le plus évident est l'échec complet pour la sous-zone .ARPA spécifique qui est déléguée à. Cela revient à ne pas avoir de délégation en place: le sous-ensemble d'enregistrements .ARPA est introuvable et les recherches DNS inversées échoueront donc pour cet ensemble de ressources d'adresse IP. Sans délégation en place, l'échec est immédiat et définitif. Le client interrogateur pour une zone particulière obtiendra une réponse négative du serveur de noms de la zone parent et n'effectuera plus de recherches.
Mais par rapport à une délégation boiteuse, le client reçoit une référence vers le (s) serveur (s) de noms boiteux (et invalide ou cassé). Il doit ensuite les rechercher par nom avant d'en interroger un ou plusieurs pour l'enregistrement initialement demandé. Si le premier serveur de noms de l'ensemble échoue, le client peut essayer le reste, un par un si tous sont boiteux.
Dans certains cas, la boiterie est le résultat d'une absence d'autorité ou de dossiers manquants, mais dans d'autres, le serveur de noms boiteux est inexistant ou ne répond pas. Dans ces cas, le client doit également attendre l'expiration de la demande avant d'essayer l'autre NS ou d'échouer complètement.
En résumé, les délégations de serveur de noms boiteuses par rapport à l'absence de délégation entraînent un trafic DNS supplémentaire et un temps beaucoup plus long pour répondre pour le client, avec le même résultat final pratique. En outre, les zones parentes de niveau supérieur qui contiennent ces enregistrements NS inutiles et effectivement invalides sont inutilement plus grandes que nécessaires. Il existe également un impact potentiel sur les données statistiques tirées de la ou des zones mères.
2. Résumé de la manière dont cette proposition résout le problème
2.1. Résumé
Cette stratégie définit un processus pour surveiller les enregistrements de serveurs de noms responsables de délégations boiteuses et une approche progressive pour supprimer ces enregistrements du DNS.
2.2. Portée de la politique
Cette politique est destinée à s'appliquer uniquement aux zones DNS sous in-addr.arpa et ip6.arpa gérées par AFRINIC. Des vérifications doivent être effectuées pour chaque enregistrement NS provenant d’objets «domaine» dans l’AFRINIC WHOIS base de données.
Plus précisément, cette politique n'est applicable qu'aux délégations DNS inversées gérées dans la région AFRINIC pour la majorité AFRINIC RIR Attributions et attributions IP.
Cette politique ne doit pas surveiller ou considérer les délégations DNS inversées pour les minorités RIR Ressources d'adresse IP ou ressources d'adresse IP héritées.
3. Proposition
3.1. Détails du processus
Le texte suivant sera ajouté au Manuel de politique consolidée:
10.7 Processus pour les délégations Lame
10.7.1 Surveillance / vérification
Tous les objets "domaine" de l'AFRINIC WHOIS la base de données doit être périodiquement examinée et tous les attributs "nserver" extraits pour vérification. Chaque "nserver" trouvé doit être vérifié pour:
- Répondez aux requêtes DNS.
- Répondre avec un enregistrement SOA valide pour le domaine associé dans le WHOIS base de données.
Cette vérification périodique devrait être automatisée. Les vérifications devraient être relativement fréquentes, mais pas assez fréquentes pour avoir un impact opérationnel sur les systèmes AFRINIC ou sur le DNS mondial. Si un serveur de noms échoue à une vérification pour la première fois, cela est initialement simplement enregistré. Ce n'est qu'après l'échec de plusieurs contrôles de boiterie qu'un serveur de noms doit être signalé pour une action ultérieure.
Notification 10.7.2
Une fois qu'un ou plusieurs serveurs de noms sont marqués comme boiteux, une tentative raisonnable doit être faite pour contacter la ou les personnes responsables de l'objet "domaine" et la délégation DNS.
Tous les contacts "admin-c", "tech-c" et "zone-c" doivent être essayés en parallèle.
De plus, les informations de contact peuvent être extraites des attributs "org" et / ou "mnt-by" associés, le cas échéant.
Les communications de notification sans réponse doivent également être réessayées plus d'une fois avant de passer à d'autres actions.
La fréquence de communication, les méthodes de communication et le nombre de tentatives devraient être normalisés et documentés publiquement.
10.7.3 Suppression de la délégation
Une fois qu'un serveur de noms donné a été déterminé comme étant boiteux pour un "domaine" DNS donné, et que des tentatives raisonnables ont été faites pour contacter une personne responsable, le serveur de noms doit alors être supprimé du "domaine" DNS donné.
Le serveur de noms ne doit pas être supprimé de tous WHOIS des objets et des zones DNS, car il peut ne pas être uniformément boiteux pour les autres zones qu'il dessert.
Seuls les serveurs de noms marqués comme boiteux doivent être supprimés d'un domaine donné. Le domaine ne doit pas avoir tous les attributs "nserver" supprimés.
Ces suppressions devraient être automatisées. Une ligne facultative "remarques" peut être ajoutée à l'enregistrement "domaine" dans la base de données.
Si un domaine donné a tous ses serveurs de noms identifiés comme boiteux, et donc supprimés, il doit également être supprimé de la base de données, car l'attribut "nserver" est obligatoire pour les objets "domaine".
Les informations historiques sur les serveurs de noms et les objets de domaine supprimés doivent être archivées pendant une durée raisonnable et mises à la disposition du membre à des fins d'information.
10.7.4 Réintégration
Une fois que les serveurs de noms sont fixes ou que d'autres serveurs de noms sont disponibles pour une zone DNS inversée donnée, la ou les personnes responsables leur ajoutent une délégation de la même manière qu'une nouvelle délégation est effectuée pour une nouvelle attribution ou attribution IP.
3.2 Impacts opérationnels possibles
Une délégation DNS d'une zone enfant par des enregistrements NS boiteux dans la zone parent entraînera une défaillance partielle ou complète de la zone enfant.
Par conséquent, la suppression de ces enregistrements boiteux chez le parent n'aura aucun autre effet négatif sur la zone enfant.
Dans le cas d'une boiterie partielle, où tous les serveurs de noms ne sont pas jugés boiteux, l'impact sera positif: la suppression des délégations défaillantes n'entraînera aucune défaillance DNS, plutôt que partielle.
3.3 Exemple de lignes directrices sur les opérations de mise en œuvre
Les auteurs sont conscients qu'il y aurait un travail important à faire pour mettre en œuvre cette politique. Ils ont travaillé sur une ligne directrice pour la mise en œuvre, si la politique devait être adoptée.
Un exemple de manuel opérationnel est disponible en ligne [9] pour guider le personnel d'AFRINIC. Les entrées et le texte sont les bienvenus, mais veuillez noter qu'il s'agit d'un exemple pour la mise en œuvre et ne fait pas partie de la politique.
4. Historique des révisions
2017/03/15: Premier draft
5. Références
5.1 Politiques similaires dans d'autres régions
- ARIN: Politique 2002-1: Lame Délégations dans IN-ADDR.ARPA [4]
- APNIC: prop-038: Modification de la politique de délégation inversée DNS boiteuse d'APNIC [5]
- LACNIC: Politique de délégation de la boeuf dans la région couverte par le LACNIC [6]
- RIPE NCC: Aucune politique connue pour le moment.
5.2 Études de mauvaise configuration DNS
- Délégation boiteuse dans la base de données AFRINIC: Quelle est la boiteuse de nos délégations inverses? [sept]
- Erreurs de configuration incorrecte du DNS: impact des erreurs de configuration sur la robustesse du DNS [8]
5.3 URI
https://www.rfc-editor.org/rfc/rfc2119.txt
https://www.ietf.org/rfc/rfc1912.txt
https://www.arin.net/policy/proposals/2002_1.html
https://www.apnic.net/community/policy/proposals/prop-038/
http://www.lacnic.net/en/web/lacnic/manual-6
http://afrinic.net/blog/165-how-lame-are-our-reverse-delegations
http://web.cs.ucla.edu/~lixia/papers/09DNSConfig.pdf
Glossaire 5.4
- DNS: système de noms de domaine
- RIR: Registre Internet régional
- Majorité RIR: Détient l'allocation parent de l'IANA.
- Minorité RIR: Gère l'espace au sein de l'allocation majoritaire.
- Ressources Internet héritées: ressources de numéros Internet obtenues avant ou en dehors du système de registre Internet hiérarchique actuel.
- Enregistrement SOA: enregistrement "Start Of Authority", en tête de chaque zone DNS.
Évaluation du personnel
Évaluation du personnel
| Proposition | AFPUB-2017-DNS-001-DRAFT- 01 |
| Titre | Délégations boiteuses dans le DNS inversé AFRINIC |
| évaluée | 15 mai 2017 |
1.0 Le personnel comprend la proposition
-
La proposition vise à atténuer ou à éliminer les délégations DNS de rdns boiteux associées aux ressources émises (ou gérées administrativement) par AFRINIC.
-
La proposition met en place un processus de surveillance des enregistrements NS responsables de délégations boiteuses et une approche progressive pour supprimer ces enregistrements du DNS.
-
Il s'agit d'une mise à jour (ou d'une amélioration) du processus rDNS actuel décrit dans le Consolidated Policy Manual (Sec 10)
2.0 Commentaires du personnel:
- L'espace DNS inversé délégué à partir des ressources IP AFRINIC est d'environ 44% LAME selon les données analysées à partir de http://ftp.afrinic.net/pub/zones/ sur 12 mai 2017.
- La proposition doit indiquer explicitement qu'AFRINIC ne tiendra pas compte des enregistrements de ressources "minoritaires" entrants provenant RIRs, car ces enregistrements proviennent de l'extérieur d'AFRINIC et échappent à notre contrôle.
- La proposition doit indiquer explicitement si les détenteurs de ressources héritées sont inclus / exclus / affectés et comment.
- Concernant les notifications - les auteurs doivent autoriser AFRINIC à déterminer qui peut être notifié et quel processus utiliser. Le libellé "communications sans réponse" pourrait également changer pour faire référence au manque de résolution du problème après un certain temps, car il peut arriver qu'une communication soit répondue sans que le problème soit résolu.
- Concernant la clause 10.7.4 - cette clause semble inutile.
3.0 Commentaires du conseiller juridique:
- Aucun observé
4.0 Mise en œuvre:
4.1 Chronologie et impact
Le développement et les tests (logiciels) prendront environ deux mois.
4.2 Exigences de mise en œuvre
Les actions suivantes sont nécessaires pour mettre en œuvre cette politique telle qu'elle est écrite:
- Implémentation des contrôles automatisés de "boiterie".
- Mise à jour des règles métier (internes) pour exécuter des vérifications avant la création / mise à jour du domaine.
- Automatisation des notifications envoyées aux contacts des enregistrements associés aux délégations boiteuses comme spécifié en 10.7.2 ainsi que des rapports mensuels de délégation de boiterie et des rapports semestriels de nettoyage de délégation boiteuse.
- Outil de vérification de la boiterie publique.
- Archivage d'objets dans WHOIS (des développements supplémentaires sont également nécessaires pour afficher les objets archivés dans MyAFRINIC).
- Automatisation de la suppression des délégations boiteuses comme spécifié en 10.7.3
- Automatisation des réintégrations comme spécifié en 10.7.4
- Documentation (et publication requise) du processus détaillant la manière dont la fréquence / les tentatives de communication et les méthodes seront mises en œuvre.
