Introduction

AFRINIC 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:

 

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. 

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

 

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.