Introdução

AFRINIC gerencia delegações reversas (RDNS) para o IPv4 e IPv6 endereço espaço alocado pela IANA para AFRINIC.

Quando os recursos são emitidos para os operadores de rede, o AFRINIC delega a autoridade das zonas reversas a esses operadores, que por sua vez devem publicar os servidores de nomes de suas zonas reversas nas zonas gerenciadas do AFRINIC. Como você sabe, RDNS permite que aplicativos na Internet mapeiem um IP para um host e é considerado um mecanismo importante usado por muitos aplicativos na Internet, por exemplo, por servidores de correio prevenção de spam. Portanto, é muito importante ter dados precisos sobre os domínios reversos no AFRINIC WHOIS banco de dados, pois essas configurações incorretas podem ter impacto adverso múltiplo sobre a robustez do DNS.

AFRINIC tem cerca 30000 objetos de domínio com 72000+ Registros NS com mais de 45% de registros NS ruins em IPv4 zonas e 32% de registros NS ruins IPv6. Isso constitui por aí 25% de todos os objetos de domínio sendo coxos.

 

Quando sua delegação é considerada "manca"?

RFC1912 define uma delegação como 'lame' quando um servidor de nomes é delegado a responsabilidade de fornecer um serviço de nomes para uma zona (via registros NS), mas não está realmente fazendo isso, ou seja, o servidor de nomes não está configurado como um servidor primário ou secundário . No entanto, classificamos 'claudicação' em quatro casos diferentes para obter mais granularidade.

Casos de delegação coxo

Uma delegação (rdns) é considerada "manca" se uma das seguintes regras for atendida:

 

Tabela 1. Cenários de caso lame 

Pegamos o conjunto completo de domínio reverso e execute o experimento em cada tupla de registro de recurso (NS) de servidor de nomes e domínio. Um domínio pode ter vários registros NS. Cada registro é considerado uma entrada no DNS para o qual verificamos sua validade.

Formato	Número de objetos de domínio	Número de registros NS
IPv4	29894	72341
IPv6	196	550
Total	29986	72891

Tabela 2. Objetos de domínio AFRINIC

Executamos o experimento em dois locais diferentes (Maurício e Joanesburgo). Uma delegação é considerada 'manca' se falhar em ambos os sites. Para simplificar a representação dos resultados, decidimos classificar os domínios em 3 categorias:

Categoria	Descrição
CASO_0	NS é responsivo NS serve ao domínio NS é oficial, ou seja, bandeira AA presente
CASO_1	Conexão expirou Nome ou serviço desconhecido Ligação recusada Rede inacessível Host inacessível Fim do arquivo Erro de comunicação Não foi possível obter o endereço
CASO_2	O status da resposta é RECUSADO ou SERVFAIL Nenhuma resposta recebida do servidor, ou seja, ANSWER: 0
CASO_3	NS não é autoritário

Tabela 3. Status do domínio

Com o cavar , classificamos o resultado de cada delegação encontrada nas zonas reversas públicas do AFRINIC, de acordo com os critérios da Tabela 3. Também temos diferentes subcasos, por exemplo, CASE_3 pode ser marcado como RECUSADO. SERVFAIL, NXDOMAIN ou NO_ANSWER dependendo do tipo de erro retornado no resultado. 

Figura 1. Distribuição de erros por versão do protocolo

Para 45.5% das entradas RDNS que foram consideradas “problemáticas”, isso significa que pelo menos um dos registros NS no objeto de domínio é “LAME”. Vamos analisar os objetos com base nos diferentes cenários de caso na Tabela 4.

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

Tabela 4. Porcentagem de registros NS lame vs não lame

Detalhamento de erro por tipo de recurso

O Quadro 5 mostra a distribuição dos erros, ou seja, como esses 45.5% das delegações coxas podem ser classificados. Observamos que 75.5% são na verdade CASE_3 (servidores responsivos, mas não atendendo a zona). Muito provavelmente, os servidores de nomes que foram registrados foram desativados. 23.5% dos erros são CASE_1 e CASE_2, o que significa que os servidores nem mesmo estão acessíveis.

Formato	Caso 1		Caso 2		Caso 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 / Média	7822		25096		314		33144
Porcentagem média	23.5%		75.5%		1%

tabela 5. Repartição por tipo de recurso

Análise de erro por bloco de endereço

Observamos na tabela 6 e na figura 4 que CASE_4 não é realmente um problema para nenhum bloco de endereço gerenciado pelo AFRINIC. No entanto, temos uma alta porcentagem de CASE_3 (mais de 40%) em 197/8 e 154/8, bem como em 2001: 4200 :: / 23 IPv6 bloquear.

Bloco de endereços	NÃO COXO CASO 0		Caso 1		Caso 2		Caso 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
Vários[*]	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

mesa 6. Repartição por bloco de endereço

 

Figura 2. Análise de erro por bloco de endereço

Trabalho futuro

A delegação falha é apenas um subconjunto da misconguração do DNS. Para garantir a disponibilidade total, os servidores de nomes devem ser verdadeiramente redundantes. Por verdadeiramente redundante, queremos dizer que os servidores de nomes primários e secundários devem ser espalhados geograficamente e não encontrados no mesmo host e, tanto quanto possível, não na mesma rede (ou seja, em ASes diferentes). No caso de uma interrupção do roteamento e uma rede não estiver disponível, a outra rede ainda estará acessível. Isso garante redundância total. Além disso, seria interessante ver onde os operadores de rede africanos estão hospedando seus servidores DNS. O mapeamento dos servidores por localização nos daria uma indicação se os operadores africanos estão usando serviços locais ou offshore, geralmente acessíveis em links internacionais caros. A dependência de zona cíclica é outro problema menos conhecido, mas ainda assim é importante lidar com a criação de loops de dependência entre os servidores DNS. O impacto é o acréscimo de carga desnecessária nesses servidores, afetando, em última análise, a disponibilidade geral.