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

Quão coxas são nossas delegações reversas?

Imprimir amigável, PDF e e-mail

Introdução

paralíticoAFRINIC 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:

 

REGRA# Razão Descrição Exemplo Mensagem de erro
1 Um servidor de nomes não está acessível

servidor de nomes não responde

dig + norec aaa.bbb.ccc @ toto.afrinic.net A
dig: não foi possível obter o endereço para 'toto.afrinic.net': não encontrado
or
dig + norec @ 1.1.1.1 afrinic.net a; << >> DiG 9.8.3-P1 << >> + norec @ 1.1.1.1 afrinic.net a
; (1 servidor encontrado)
;; opções globais: + cmd
;; conexão expirou; nenhum servidor foi alcançado
nome do servidor não responde
2 O servidor de nomes não está respondendo na porta 53

o servidor de nomes no objeto de domínio está acessível

mas não responde na porta 53

dig + norec @ 196.216.2.6 afrinic.net a

; << >> DiG 9.8.3-P1 << >> + norec @ 196.216.2.6 afrinic.net a
; (1 servidor encontrado)
;; opções globais: + cmd
;; conexão expirou; nenhum servidor foi alcançado
Nome do servidor não responde na porta 53
3 O servidor de nomes não atende ao domínio

o servidor de nomes no objeto de domínio está acessível

responde na porta 53

mas não responde a este domínio

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

; << >> DiG 9.8.3-P1 << >> + norec @ ns1.apnic.net afrinic.net. NS
; (2 servidores encontrados)
;; opções globais: + cmd
;; Resposta obtida:
;; - >> HEADER << - opcode: QUERY, status: RECUSADO, código: 15421
;; sinalizadores: qr; QUERY: 1, RESPOSTA: 0, AUTORIDADE: 0, ADICIONAL: 0

;; SEÇÃO DE PERGUNTAS:
; afrinic.net. EM NS

;; Tempo de consulta: 536 mseg
;; SERVIDOR: 2001:dc0:2001:0:4608::25#53(2001:dc0:2001:0:4608::25)
;; QUANDO: Sex. 3 de outubro 11: 38:17 de 2014
;; TAMANHO MSG rcvd: 29
Nome do servidor não serve este domínio
4 O servidor de nomes não é autoritativo

o servidor de nomes no objeto de domínio está acessível

responde na porta 53

retorna uma resposta DNS válida

bit de autoridade (sinalizador 'aa') não está definido

dig + norec @ 8.8.8.8 afrinic.net. NS

; << >> DiG 9.8.3-P1 << >> + norec @ 8.8.8.8 afrinic.net. NS
; (1 servidor encontrado)
;; opções globais: + cmd
;; Resposta obtida:
;; - >> HEADER << - opcode: QUERY, estado: ERRO, código: 60812
;; sinalizadores: qr ra; CONSULTA: 1, RESPOSTA: 7, AUTORIDADE: 0, ADICIONAL: 0

;; SEÇÃO DE PERGUNTAS:
; afrinic.net. EM NS

;; RESPOSTA SECÇÃO:
afrinic.net. 3563 IN NS ns2.afrinic.net.
afrinic.net. 3563 IN NS sec1.apnic.net.
afrinic.net. 3563 IN NS tinnie.arin.net.
afrinic.net. 3563 IN NS ns1.afrinic.net.
afrinic.net. 3563 IN NS sec1.authdns.ripe.net.
afrinic.net. 3563 IN NS sec3.apnic.net.
afrinic.net. 3563 IN NS ns2.lacnic.net.

;; Tempo de consulta: 219 mseg
;; SERVIDOR: 8.8.8.8 # 53 (8.8.8.8)
;; QUANDO: Sex. 3 de outubro 11: 35:41 de 2014
;; TAMANHO MSG rcvd: 192

Nome do servidor não é autorizado para a zona

 

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.

Tipo 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
CASE_0
  • NS é responsivo
  • NS serve ao domínio
  • NS é oficial, ou seja, bandeira AA presente
CASE_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
CASE_2
  • O status da resposta é RECUSADO ou SERVFAIL
  • Nenhuma resposta recebida do servidor, ou seja, ANSWER: 0
CASE_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. 

20161019010742

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.

Tipo 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.

 Tipo  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
# % # % # % # %
Suporte 6599 47.7 2204 16.0 4953 35.8 91 0.7
Suporte 5855 35.4 699 4.2 9908 60.0 58 0.4
Suporte 1599 41.0 458 11.7 1821 46.7 25 0.6
Suporte 15692 63.1 2850 11.5 6238 25.1 104 0.4
Suporte 7 100 0 0 0 0 0 0
Suporte 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

 repartição de recursos

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. 

Última modificação em -
Data e hora nas Maurícias -