Introdução

A AFRINIC gere delegações inversas (RDNS) para a IPv4 e IPv6 endereço espaço alocado pela IANA para AFRINIC.

Quando recursos são alocados a operadores de rede, a 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 pela AFRINIC. Como você sabe, o RDNS permite que aplicativos na Internet mapeiem um endereço IP para um host e é considerado um mecanismo importante usado por muitos aplicativos na Internet, por exemplo, por servidores de e-mail. prevenção de spamPortanto, é muito importante dispor de dados precisos sobre 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.

A AFRINIC tem cerca de 30000 objetos de domínio com 72000+ Registros NS com mais de 45% de registros NS deficientes em IPv4 zonas e 32% de registros NS fracos IPv6Isso constitui por aí 25% de todos os objetos de domínio serem fracos.

 

Quando é que a sua delegação é considerada "ineficiente"?

RFC1912 Definimos uma delegação como "inadequada" quando um servidor de nomes recebe a responsabilidade de fornecer um serviço de nomes para uma zona (via registros NS), mas na realidade não o faz, ou seja, o servidor de nomes não está configurado como servidor primário ou secundário. No entanto, classificamos a "inadequação" em quatro casos diferentes para maior granularidade.

Casos de delegação inadequada

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

 

Tabela 1. Cenários de casos de claudicação 

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

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

Tabela 2. Objetos do domínio AFRINIC

Realizamos o experimento a partir de dois locais diferentes (Maurício e Joanesburgo). Uma delegação é considerada "ineficaz" se falhar em ambos os locais. Para simplificar a apresentação dos resultados, decidimos classificar os domínios em 3 categorias:

Categoria	Descrição
CASO_0	NS é responsivo NS serve o domínio NS é autoritativo, ou seja, a bandeira AA está 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 FALHA NO SERVIÇO. Nenhuma resposta recebida do servidor, ou seja, RESPOSTA: 0
CASO_3	NS não é uma autoridade no assunto.

Tabela 3. Situação do domínio

Com o cavar Para cada comando, classificamos o resultado encontrado nas zonas reversas públicas da AFRINIC, conforme os critérios da Tabela 3. Também temos diferentes subcasos, por exemplo, CASE_3 pode ser marcado como RECUSADO, FALHA NO SERVIÇO, NXDOMAIN ou SEM RESPOSTA, dependendo do tipo de erro retornado no resultado. 

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

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

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

Tabela 4. Percentagem de registos NS com claudicação versus sem claudicação

Detalhamento dos erros por tipo de recurso

A Tabela 5 mostra a distribuição dos erros, ou seja, como os 45.5% de delegações inválidas podem ser classificadas. Observamos que 75.5% são, na verdade, CASO_3 (servidores responsivos, mas que não atendem à zona). Muito provavelmente, os servidores de nomes registrados foram desativados. Os 23.5% restantes dos erros são CASO_1 e CASO_2, o que significa que os servidores sequer estão acessíveis.

Formato	Caso 1		Caso 2		Caso 3		Segurança
	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
Percentagem média	23.5%		75.5%		1%

tabela 5. Detalhamento por tipo de recurso

Detalhamento de erros por bloco de endereço

Observamos na tabela 6 e na figura 4 que o CASO_4 não representa um problema significativo para nenhum dos blocos de endereços gerenciados pelo AFRINIC. No entanto, há uma alta porcentagem de CASO_3 (mais de 40%) nos blocos 197/8 e 154/8, bem como no bloco 2001:4200::/23. IPv6 bloquear.

Bloco de endereços	NÃO É RIDÍCULO 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. Detalhamento por bloco de endereço

 

Figura 2. Detalhamento de erros por bloco de endereço

Trabalho futuro

A delegação inadequada é apenas um subconjunto da má configuração do DNS. Para garantir disponibilidade total, os servidores de nomes devem ser verdadeiramente redundantes. Por verdadeiramente redundantes, queremos dizer que os servidores de nomes primários e secundários devem estar geograficamente dispersos e não devem estar no mesmo host e, na medida do possível, não na mesma rede (ou seja, em ASes diferentes). No caso de uma falha de roteamento e uma rede ficar indisponível, a outra rede ainda estará acessível. Isso garante redundância total. Além disso, seria interessante verificar onde os operadores de rede africanos estão hospedando seus servidores DNS. Mapear os servidores por localização nos daria uma indicação se os operadores africanos estão usando serviços locais ou offshore, geralmente acessíveis por meio de links internacionais caros. A dependência cíclica de zonas é outro problema menos conhecido, mas importante de ser abordado, pois cria loops de dependência entre os servidores DNS. O impacto é a adição de carga desnecessária a esses servidores, afetando, em última análise, a disponibilidade geral.