Dia da Bandeira do DNS 2020

Autores: Yazid Akanho, Malick Alassane, Mike Houngbadji e Amreesh Phokeer

O Sistema de Nomes de Domínio (DNS) é um dos serviços mais críticos para o funcionamento diário da Internet. Ele permite que os nomes sejam resolvidos em endereços IP e vice-versa por meio de um sistema hierárquico de servidores distribuídos. Como um prelúdio para o Dia da bandeira do DNS 2020, foi realizado um estudo para avaliar o nível de prontidão de EDNS e TCP de servidores DNS autorizados (Name Server - NS) em zonas reversas de endereços IP alocados pela AFRINIC para seus membros e servidores autorizados de domínios ccTLD africanos. Tal estudo torna possível avaliar o nível de conformidade do DNS na África com boas práticas relacionadas ao EDNS, mas também destacar vários aspectos relacionados de boas práticas e padrões DNS, como localização, distribuição geográfica, resiliência e IPv6 acessibilidade ou alcançabilidade desses servidores autorizados.

O Plano de Ação Global para Saúde Mental da Dia da bandeira do DNS é uma iniciativa nascida do desejo conjunto dos provedores e operadores de DNS de tornar o DNS mais confiável, resiliente e escalonável. O primeiro DNS Flag Day ocorreu em 1º de fevereiro de 2019 e foi dedicado ao estudo do nível de configuração da extensão EDNS em servidores DNS autorizados em todo o mundo.

Para 2020, o DNS Flag Day planeja verificar dois elementos: por um lado, o tamanho do buffer EDNS (que não deve exceder 1232 bytes para evitar a fragmentação das respostas DNS em UDP), e por outro lado, a possibilidade de comunicação em modo TCP entre o cliente e o servidor DNS.

EDNS, abreviação de Extension Mechanisms for DNS, é definido na RFC 6891, como uma extensão do protocolo DNS, para a troca de informações entre clientes (resolvedores) e servidores. Embora o EDNS tenha várias funções, seu foco principal era originalmente habilitar o suporte para DNSSEC, que fornece segurança criptográfica para a infraestrutura DNS. 

O EDNS foi projetado para ser compatível com as versões anteriores, o que significa que não deve afetar o desempenho de servidores mais antigos que não oferecem suporte ao EDNS. Na prática, entretanto, muitos servidores foram considerados incompatíveis com EDNS, o que obrigou os desenvolvedores de resolvedores a adicionar todos os tipos de soluções alternativas a seus códigos para permitir que clientes e servidores continuassem a trocar tráfego DNS sem interromper. Um servidor compatível com EDNS é, portanto, um servidor que suporta a extensão EDNS ou é capaz de ignorá-la de acordo com a especificação.

A fim de avaliar a compatibilidade global de EDNS de um servidor autorizado, este último deve ser submetido a vários testes descrito em detalhes aqui. O Internet System Consortium (ISC) também desenvolveu e publicou uma série de Ferramentas de teste de conformidade de DNS permitindo, entre outras coisas, que os registros e registradores verifiquem a conformidade do protocolo DNS em execução nos servidores aos quais delegam zonas. 

Em 15 de junho de 2020, havia 38,945 IPv4 zonas reversas e 348 IPv6 zonas reversas conhecidas por AFRINIC. Essas zonas são definidas por membros que receberam prefixos IP do registro. Um total de 3604 (únicos) servidores de nomes autorizados (NS) fornecem resolução reversa para a zona de endereçamento IP global (v4 e v6) administrada pela AFRINIC: 3224 NS gerenciam o IPv4 espaço, enquanto 61 NS gerencia o IPv6 espaço e 319 NS fornecem resolução reversa para os blocos v4 e v6 do Registro Regional da Internet.

Em relação à compatibilidade EDNS geral dos servidores testados, apenas 1.78% são rigorosamente compatíveis em todos os parâmetros EDNS testados para o NS das zonas reversas AFRINIC, ou seja, todos os testes retornam exatamente as respostas esperadas e o tamanho do cache EDNS está entre 512 e 1232 bytes. Na verdade, não há nenhum valor fixo retido para a configuração do buffer EDNS. RFC6891 define um tamanho máximo de 4096 bytes. No entanto, para evitar a fragmentação das respostas DNS, um valor entre 1220 e 1232 bytes é recomendado; a principal razão é que o MTU em um link Ethernet tem 1500 bytes. Os organizadores do DNS Flag Day 2020 recomendam 1,232 bytes.

No entanto, isso deve ser colocado em perspectiva porque cerca de 75% dos servidores testados para zonas reversas suportam EDNS0 com um buffer entre 512 e 4096 bytes, o que já é muito encorajador. Verificamos que de 3604 NS, 872 (25.4%) retornaram erro com o status: RECUSADO.

Figura 1. Distribuição de tamanhos de buffer para AFRINIC Reverse DNS

Em 15 de junho de 2020, 54 ccTLDs atendidos por 225 NS exclusivos eram contados no continente africano. Apenas um dos NS do ccTLD .cm (benoue.camnet.cm.) Não tinha registro do tipo A ou AAAA. 81 NS eram IPv4 apenas e 143 eram de empilhamento duplo.

Não foi possível recuperar os tamanhos do buffer EDNS para 53.8% dos NS em ccTLDs africanos devido a um problema de rede ou tempo limite, o que foi bastante surpreendente. Os resultados para o resto da distribuição são os seguintes: 82 (36.4%) 4096, 16 (7.1%) 512, 5 (2.2%) 1680 e 1 (0.4%) 512 bytes.

Figura 2. Distribuição de tamanhos de buffer para ccTLDs

Quando se trata de conformidade com TCP para ccTLDs africanos, é muito difícil avaliar com precisão o número real de servidores de nomes autorizados que podem responder às solicitações de DNS usando TCP. No entanto, recebemos respostas de 43.55% desses servidores que utilizam TCP.

Outro elemento importante do DNS é que os servidores de nomes devem ser capazes de processar consultas DNS no modo TCP. O RFC1035 especifica que um servidor de nomes DNS deve ser capaz de lidar com consultas DNS usando TCP ou UDP na porta 53. No entanto, o protocolo UDP tem sido historicamente usado predominantemente por sua simplicidade e velocidade.

Com a introdução do DNSSEC em particular, a necessidade de se comunicar por TCP tornou-se necessária porque as respostas do DNS agora podem ter mais de 512 bytes. No total, descobrimos que 71.7% dos servidores de nomes de zona reversa AFRINIC resolvem solicitações enviadas por TCP. No entanto, é difícil esclarecer se é o servidor que não está configurado para responder às solicitações de TCP ou se um firewall localizado entre o cliente e o servidor que rejeita este tipo de tráfego (infelizmente, vários administradores de rede ainda consideram que o DNS deve apenas trabalhar sobre UDP).

Para resumir, no grupo NS da zona reversa, 25.4% dos servidores não suportam a extensão EDNS. Do lado dos ccTLDs, o percentual é o dobro, em torno de 54%. Em ambos os casos, esses são servidores executando com uma versão de software desatualizada ou porque a configuração EDNS está desabilitada em sua configuração, o que não é recomendado. No total, descobrimos que 71.7% dos servidores de nome de zona reversa AFRINIC resolvem solicitações enviadas por TCP, em comparação com 43.55% no caso de ccTLDs. Este estudo permitiu obter resultados relevantes e ter uma melhor visibilidade sobre o nível de implementação de várias recomendações e boas práticas atuais em Sistema de Nomes de Domínio no continente africano, tais como EDNS e suporte de TCP entre outros.

O relatório a seguir foi gerado em um momento específico e visa fornecer uma visão geral da conformidade com o EDNS na África. Os resultados dependem da acessibilidade do servidor DNS. Problemas de rede no momento do experimento podem ter introduzido alguns falsos positivos.

Este estudo foi patrocinado pela AFRINIC em 2019 Programa AFRINIC Research Collaboration (ARC).

Gostaríamos de agradecer a Amreesh Phokeer, Gerente de Pesquisa da AFRINIC, por seu apoio e orientação neste projeto.