A iniciativa DNS flag day 2020 para resolver problemas de fragmentação e suporte a TCP

Hoje, uma série de grandes serviços DNS e fabricantes de servidores DNS realizará um evento conjunto Dia da Flag DNS 2020, que visa chamar a atenção para a solução problemas para a fragmentação IP no processamento de mensagens DNS de grande tamanho. Este é o segundo evento desse tipo; no ano passado, o "Dia da Flag DNS" foi focado na correta manipulação de consultas EDNS.

Os participantes da iniciativa Dia da Flag DNS 2020 pedem para fixar os tamanhos de buffer recomendados para EDNS até valores de 1232 bytes (tamanho MTU de 1280 menos 48 bytes para cabeçalhos), além de tornar o processamento de consultas via TCP uma obrigatoriedade nos servidores. No RFC 1035 está obrigatoriamente marcada apenas a suporte ao processamento de consultas via UDP, enquanto o TCP é mencionado como desejável, mas não obrigatório para operação. Novos RFC 7766 e RFC 5966 explicitamente classificam o TCP como uma das capacidades obrigatórias necessárias para o funcionamento correto do DNS. No âmbito da iniciativa, propõe-se forçar a transição de enviar consultas via UDP para o uso de TCP em casos onde o tamanho do buffer EDNS estabelecido seja insuficiente.

As mudanças propostas eliminarão a confusão na escolha do tamanho do buffer EDNS e resolverão o problema da fragmentação de grandes mensagens UDP, cujo processamento muitas vezes leva à perda de pacotes e a timeouts do lado do cliente. Do lado do cliente, o tamanho do buffer EDNS será fixo, e grandes respostas serão imediatamente enviadas ao cliente via TCP. A exclusão do envio de grandes mensagens via UDP também resolverá problemas de descartar grandes pacotes em alguns firewalls e permitirá bloquear ataques evitações de cache DNS baseadas na manipulação de pacotes UDP fragmentados (como na fragmentação, o segundo fragmento não inclui o cabeçalho com o identificador, podendo ser forjado, pois só precisa coincidir com a soma de verificação).

A partir de hoje, os provedores de DNS envolvidos na iniciativa, incluindo CloudFlare, Quad 9, Cisco (OpenDNS) e Google, começarão a trocar gradualmente o tamanho do buffer EDNS será alterado de 4096 para 1232 bytes em seus servidores DNS (a mudança do EDNS será estendida por 4 a 6 semanas e gradualmente abrangerá um maior número de consultas). Respostas a consultas UDP que não se encaixam no novo limite serão enviadas via TCP. Os fabricantes de servidores DNS, incluindo BIND, Unbound, Knot, NSD e PowerDNS, lançarão atualizações alterando o tamanho do buffer EDNS padrão de 4096 para 1232 bytes.

No final, as mudanças introduzidas podem levar a problemas de resolução ao acessar servidores DNS cujas respostas por UDP superem 1232 bytes e que não consigam enviar respostas por TCP. Um experimento realizado pelo Google mostrou que a alteração do tamanho do buffer EDNS praticamente não afetará a taxa de falhas — com um buffer de 4096 bytes, o número de consultas UDP truncadas é 0,345%, e o número de respostas repetidas inatingíveis por TCP é 0,115%. Com um buffer de 1232 bytes, esses índices são 0,367% e 0,116%. A conversão do suporte TCP em um requisito obrigatório para DNS resultará em problemas na interação com cerca de 0,1% dos servidores DNS. Observa-se que, nas condições atuais, sem TCP, a operação desses servidores já é instável.

Os administradores de servidores DNS autoritativos devem garantir que seu servidor responda via TCP na porta de rede 53 e que esta porta TCP não esteja bloqueada por um firewall. O servidor DNS autoritativo também não deve enviar respostas UDP cujo tamanho exceda
o tamanho do buffer EDNS solicitado. No próprio servidor, o tamanho do buffer EDNS deve ser configurado para 1232 bytes. Os resolvedores também enfrentam requisitos semelhantes — a capacidade obrigatória de resposta via TCP, o suporte obrigatório para reenvio de consultas via TCP ao receber uma resposta UDP truncada e a configuração do buffer EDNS em 1232 bytes.

As configurações do tamanho do buffer EDNS em diversos servidores DNS são determinadas pelos seguintes parâmetros: