Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

À quel point nos délégations inversées sont-elles boiteuses?

Introduction

paralytiqueAFRINIC gère les délégations inversées (RDNS) pour le IPv4 et IPv6 propos espace alloué par l'IANA à AFRINIC.

Lorsque les ressources sont attribuées aux opérateurs de réseau, AFRINIC délègue l'autorité des zones inversées à ces opérateurs, qui doivent à leur tour publier les serveurs de noms de leurs zones inversées dans les zones gérées par AFRINIC. Comme vous le savez, RDNS permet aux applications sur Internet de mapper une adresse IP à un hôte et est considéré comme un mécanisme important utilisé par de nombreuses applications sur Internet, par exemple par les serveurs de messagerie dans le prévention du spam. Il est donc très important d'avoir des données précises sur les domaines inversés dans l'AFRINIC WHOIS base de données car ces erreurs de configuration peuvent avoir impact négatif multiple sur la robustesse du DNS.

AFRINIC a environ 30000 objets de domaine avec 72000+ Enregistrements NS avec plus de 45% de disques NS boiteux dans IPv4 zones et 32% de disques NS boiteux IPv6. Cela constitue autour 25% de tous les objets de domaine étant boiteux.

 

Quand votre délégation est-elle considérée comme "boiteuse"?

RFC1912 définit une délégation comme étant `` boiteuse '' lorsqu'un serveur de noms se voit déléguer la responsabilité de fournir un service de noms pour une zone (via des enregistrements NS) mais qu'il ne le fait pas réellement, c'est-à-dire que le serveur de noms n'est pas configuré en tant que serveur primaire ou secondaire . Cependant, nous avons classé la «boiterie» dans quatre cas différents pour plus de granularité.

Cas de délégation boiteuse

Une délégation (rdns) est considérée comme "boiteuse" si l'une des règles suivantes est respectée:

 

RÈGLE# Raison Description Exemple Message d'erreur
1 Un serveur de noms n'est pas accessible

le serveur de noms ne répond pas

creuser + norec aaa.bbb.ccc @ toto.afrinic.net A
dig: impossible d'obtenir l'adresse pour 'toto.afrinic.net': introuvable
or
dig + norec @ 1.1.1.1 afrinic.net a; << >> DiG 9.8.3-P1 << >> + norec @ 1.1.1.1 afrinic.net a
; (1 serveur trouvé)
;; options globales: + cmd
;; la connexion a expiré; aucun serveur n'a pu être atteint
nom du serveur ne répond pas
2 Le serveur de noms ne répond pas sur le port 53

le serveur de noms dans l'objet de domaine est accessible

mais ne répond pas sur le port 53

creuser + norec @ 196.216.2.6 afrinic.net a

; << >> DiG 9.8.3-P1 << >> + norec @ 196.216.2.6 afrinic.net a
; (1 serveur trouvé)
;; options globales: + cmd
;; la connexion a expiré; aucun serveur n'a pu être atteint
Nom du serveur ne répond pas sur le port 53
3 Le serveur de noms ne dessert pas le domaine

le serveur de noms dans l'objet de domaine est accessible

répond sur le port 53

mais ne répond pas à ce domaine

creuser + norec @ ns1.apnic.net afrinic.net. NS

; << >> DiG 9.8.3-P1 << >> + norec @ ns1.apnic.net afrinic.net. NS
; (2 serveurs trouvés)
;; options globales: + cmd
;; J'ai la réponse:
;; - >> HEADER << - opcode: QUERY, statut: REFUSÉ, identifiant: 15421
;; drapeaux: qr; RECHERCHE: 1, RÉPONSE: 0, AUTORITÉ: 0, ADDITIONNEL: 0

;; SECTION QUESTION:
; afrinic.net. EN NS

;; Temps de requête: 536 msec
;; SERVEUR: 2001:dc0:2001:0:4608::25#53(2001:dc0:2001:0:4608::25)
;; QUAND: Ven 3 octobre 11:38:17 2014
;; MSG TAILLE rcvd: 29
Nom du serveur ne serveur pas ce domaine
4 Le serveur de noms ne fait pas autorité

le serveur de noms dans l'objet de domaine est accessible

répond sur le port 53

renvoie une réponse DNS valide

le bit d'autorité (indicateur 'aa') n'est pas défini

creuser + norec @ 8.8.8.8 afrinic.net. NS

; << >> DiG 9.8.3-P1 << >> + norec @ 8.8.8.8 afrinic.net. NS
; (1 serveur trouvé)
;; options globales: + cmd
;; J'ai la réponse:
;; - >> HEADER << - opcode: QUERY, statut: NOERROR, identifiant: 60812
;; drapeaux: qr ra; QUESTION: 1, RÉPONSE: 7, AUTORITÉ: 0, SUPPLÉMENTAIRE: 0

;; SECTION QUESTION:
; afrinic.net. EN NS

;; RÉPONSE SECTION:
afrinic.net. 3563 EN N.-É. ns2.afrinic.net.
afrinic.net. 3563 EN NS sec1.apnic.net.
afrinic.net. 3563 EN NS tinnie.arin.net.
afrinic.net. 3563 EN N.-É. ns1.afrinic.net.
afrinic.net. 3563 EN NS sec1.authdns.ripe.net.
afrinic.net. 3563 EN NS sec3.apnic.net.
afrinic.net. 3563 EN N.-É. ns2.lacnic.net.

;; Temps de requête: 219 msec
;; SERVEUR: 8.8.8.8 # 53 (8.8.8.8)
;; QUAND: Ven 3 octobre 11:35:41 2014
;; MSG TAILLE rcvd: 192

Nom du serveur ne fait pas autorité pour la zone

 

Tableau 1. Scénarios de cas boiteux 

Nous avons pris le ensemble complet de domaine inverse et exécutez l'expérience sur chaque tuple d'enregistrement de ressources (NS) de domaine et de serveur de noms. Un domaine peut avoir plusieurs enregistrements NS. Chaque enregistrement est considéré comme une entrée dans le DNS pour laquelle nous avons vérifié sa validité.

Type Nombre d'objets de domaine Nombre d'enregistrements NS
IPv4 29894 72341
IPv6 196 550
Total 29986 72891

Tableau 2. Objets du domaine AFRINIC

Nous menons l'expérience à partir de deux endroits différents (Maurice et Johannesburg). Une délégation est considérée comme «boiteuse» si elle échoue sur les deux sites. Pour simplifier la représentation des résultats nous avons décidé de classer les domaines en 3 catégories:

Catégories Description
CAS_0
  • NS est réactif
  • NS sert le domaine
  • NS fait autorité c.-à-d. Drapeau AA présent
CAS_1
  • Connexion interrompue
  • Nom ou service inconnu
  • Connexion rejetée
  • Réseau inaccessible
  • Hôte inaccessible
  • Fin de fichier
  • Erreur de communication
  • Impossible d'obtenir l'adresse
CAS_2
  • L'état de la réponse est REFUSED ou SERVFAIL
  • Aucune réponse reçue du serveur c.-à-d. RÉPONSE: 0
CAS_3
  • NS ne fait pas autorité

Tableau 3. Statut du domaine

Le creuser commande, nous avons classé le résultat de chaque délégation trouvée sur les zones inversées publiques d'AFRINIC, selon les critères du tableau 3. Nous avons également différents sous-cas, par exemple CASE_3 peut être étiqueté comme REFUSED. SERVFAIL, NXDOMAIN ou NO_ANSWER selon le type d'erreur renvoyé dans le résultat. 

20161019010742

Figure 1. Répartition des erreurs par version de protocole

Pour les 45.5% d'entrées RDNS jugées «problématiques», cela signifie qu'au moins un des enregistrements NS de l'objet de domaine est «LAME». Nous analyserons les objets en fonction des différents scénarios de cas du tableau 4.

Type OK % NOK % Total
IPv4 39439 54.5 32970 45.5 72409
IPv6 369 68 174 32 543

Tableau 4. Pourcentage d'enregistrements NS boiteux et non boiteux

Répartition des erreurs par type de ressource

Le tableau 5 montre la distribution des erreurs, c'est-à-dire comment ces 45.5% de délégations boiteuses peuvent être classés. Nous avons observé que 75.5% sont en fait CASE_3 (serveurs réactifs mais ne desservant pas la zone). Très probablement, les serveurs de noms enregistrés ont été mis hors service. 23.5% des erreurs sont CASE_1 et CASE_2, ce qui signifie que les serveurs ne sont même pas joignables.

 Type  Cas 1  Cas 2 Cas 3 Total
 JNB  MRU  JNB MRU JNB MRU  
 IPv4  7933  7674  24965 24918 298 331 32970
 IPv6  18  20  155 155 0 0 174
Total / Moyenne 7822 25096 314 33144
Pourcentage moyen 23.5% 75.5% 1%  

Tableau 5. Répartition par type de ressource

Répartition des erreurs par bloc d'adresses

Nous remarquons à partir du tableau 6 et de la figure 4 que CASE_4 n'est pas vraiment un problème pour aucun des blocs d'adresses gérés par AFRINIC. Cependant, nous sommes un pourcentage élevé de CASE_3 (plus de 40%) sur 197/8 et 154/8 ainsi que sur 2001: 4200 :: / 23 IPv6 bloque.

Bloc d'adresse PAS LAME CAS 0 Cas 1 Cas 2 Cas 3
# % # % # % # %
196/8 6599 47.7 2204 16.0 4953 35.8 91 0.7
197/8 5855 35.4 699 4.2 9908 60.0 58 0.4
154/8 1599 41.0 458 11.7 1821 46.7 25 0.6
41/8 15692 63.1 2850 11.5 6238 25.1 104 0.4
102/8 7 100 0 0 0 0 0 0
105/8 431 43.7 31.9 239 239 24.0 2 0.2
Divers[*] 9122 74.4 11.0 1753 1753 14.3 33 0.3
2001: 4200 :: / 23 106 52.3 4.5 87 87 43.1 0 0.0
2c00 :: / 12 263 77.1 2.9 68 68 20.0 0 0.0

lampe de table 6. Répartition par bloc d'adresses

 répartition des ressources

Figure 2. Répartition des erreurs par bloc d'adresse

Travail futur

La délégation Lame n'est qu'un sous-ensemble de la mauvaise configuration DNS. Pour garantir une disponibilité totale, les serveurs de noms doivent être réellement redondants. Par vraiment redondant, nous entendons que les serveurs de noms primaires et secondaires doivent être répartis géographiquement et ne pas se trouver sur le même hôte et dans la mesure du possible, pas sur le même réseau (c'est-à-dire sur des AS différents). En cas de panne de routage et qu'un réseau n'est pas disponible, l'autre réseau serait toujours accessible. Cela garantit une redondance totale. De plus, il serait intéressant de voir où les opérateurs de réseaux africains hébergent leurs serveurs DNS. La cartographie des serveurs par emplacement nous permettrait de savoir si les opérateurs africains utilisent des services locaux ou offshore, généralement accessibles sur des liaisons internationales coûteuses. La dépendance de zone cyclique est un autre problème moins connu mais néanmoins important à résoudre car ils créent des boucles de dépendance entre les serveurs DNS. L'impact est l'ajout d'une charge inutile sur ces serveurs affectant finalement la disponibilité sur l'ensemble. 

Print Friendly, PDF & Email
Dernière modification le -