Após um ano e meio de desenvolvimento cache de lançamento do servidor DNS , que é responsável pela resolução recursiva de nomes. O PowerDNS Recursor é construído na mesma base de código do PowerDNS Authoritative Server, mas os servidores DNS recursivos e autoritativos do PowerDNS são desenvolvidos por meio de diferentes ciclos de desenvolvimento e lançados como produtos separados. Código do projeto licenciado sob GPLv2.
A nova versão elimina todos os problemas relacionados ao processamento de pacotes DNS com sinalizadores EDNS. Em versões mais antigas do PowerDNS Recursor anteriores a 2016, praticava-se ignorar pacotes com sinalizadores EDNS não suportados, sem enviar uma resposta no formato antigo, descartando sinalizadores EDNS, conforme exigido pela especificação. Anteriormente, esse comportamento fora do padrão era suportado no BIND na forma de uma solução alternativa, mas dentro da estrutura de iniciativas de fevereiro , os desenvolvedores de servidores DNS decidiram abandonar esse hack.
No PowerDNS, os principais problemas no processamento de pacotes com EDNS foram corrigidos em 2017 na versão 4.1, e na ramificação 2016 lançada em 4.0, surgiram incompatibilidades individuais que ocorreram em um determinado conjunto de circunstâncias e geralmente não interferiram na operação normal. No PowerDNS Recursor 4.2, como em , soluções alternativas removidas para oferecer suporte a servidores autoritativos que respondem incorretamente a consultas com sinalizadores EDNS. Até agora, se nenhuma resposta fosse recebida após um determinado período de tempo após o envio de uma solicitação com sinalizadores EDNS, o servidor DNS considerava que os sinalizadores estendidos não eram suportados e enviava uma segunda solicitação sem sinalizadores EDNS. Esse comportamento agora está desabilitado, pois ter esse código resultou em aumento de atrasos devido ao reenvio de pacotes, aumento da carga de rede e ambiguidade na ausência de resposta devido a falhas de rede e também interferiu na implementação de recursos baseados em EDNS, como o uso de Cookies DNS para proteção contra ataques DDoS.
No ano seguinte decidiu-se realizar um evento projetado para se concentrar em com fragmentação de IP ao processar grandes mensagens DNS. Como parte da iniciativa corrija os tamanhos de buffer recomendados para EDNS para 1200 bytes e processamento de solicitações sobre TCP na categoria necessariamente suportada em servidores. Agora é necessário suporte para processamento de solicitações em UDP e TCP é desejável, mas não necessário para operação (o padrão prescreve a capacidade de desabilitar o TCP). Propõe-se remover a opção de desativar o TCP do padrão e padronizar a transição do envio de solicitações por UDP para o uso de TCP nos casos em que o tamanho do buffer EDNS definido não é suficiente.
As mudanças propostas pela iniciativa eliminarão a confusão sobre a escolha do tamanho do buffer EDNS e resolverão o problema de fragmentação de grandes mensagens UDP, cujo processamento geralmente leva à perda de pacotes e timeouts no lado do cliente. No lado do cliente, o tamanho do buffer EDNS será constante e grandes respostas serão imediatamente enviadas ao cliente por TCP. Evitar o envio de mensagens grandes por UDP também bloqueará sobre envenenamento de cache DNS, baseado na manipulação de pacotes UDP fragmentados (quando dividido em fragmentos, o segundo fragmento não inclui cabeçalho com identificador, portanto pode ser forjado, para o que basta corresponder à soma de verificação).
O PowerDNS Recursor 4.2 resolveu problemas com grandes pacotes UDP e mudou para usar um tamanho de buffer EDNS (edns-outgoing-bufsize) de 1232 bytes em vez do limite usado anteriormente de 1680 bytes, o que deve reduzir significativamente a chance de perda de pacotes UDP. O valor 1232 é escolhido por ser o máximo em que o tamanho da resposta do DNS, considerando o IPv6, cabe no valor mínimo de MTU (1280). O valor do parâmetro truncation-threshold, responsável por truncar as respostas ao cliente, também foi reduzido para 1232.
Outras mudanças no PowerDNS Recursor 4.2:
- Adicionado suporte ao mecanismo (X-Proxied-For), que é o equivalente DNS do cabeçalho HTTP X-Forwarded-For, que permite passar informações sobre o endereço IP e o número da porta do solicitante original, encaminhados por meio de proxies intermediários e balanceadores de carga (para exemplo, dnsdist). Para ativar o XPF, as opções ""E"";
- Suporte aprimorado para extensão EDNS (ECS), que permite informações sobre a sub-rede da qual a consulta original foi envenenada em uma solicitação de DNS a um servidor DNS autoritativo (os dados sobre a sub-rede de origem do cliente são necessários para a operação eficaz das redes de entrega de conteúdo). A nova versão adiciona configurações para controle seletivo sobre o uso da sub-rede do cliente EDNS: «» com uma lista de máscaras de rede para as quais o IP será usado no ECS em solicitações de saída. Para endereços que não correspondem às máscaras especificadas, o endereço genérico especificado no campo "". Através da diretiva» você pode definir sub-redes, solicitações de entrada com valores ECS preenchidos dos quais não serão substituídos;
- Para servidores que processam um grande número de requisições por segundo (mais de 100 mil), a diretiva "", que determina o número de threads para receber solicitações de entrada e distribuí-las entre as threads de trabalho (só faz sentido ao usar o "").
- Configuração adicionada para definir seu próprio arquivo com domínios onde os usuários podem registrar seus subdomínios em vez da lista interna de PowerDNS Recursor.
O projeto PowerDNS também anunciou um ciclo de desenvolvimento de seis meses, com o próximo grande lançamento do PowerDNS Recursor 4.3 previsto para janeiro de 2020. As atualizações para os principais lançamentos serão lançadas ao longo de um ano, seguidas por outros seis meses para correções de vulnerabilidades. Assim, o suporte para a ramificação PowerDNS Recursor 4.2 durará até janeiro de 2021. Mudanças semelhantes no ciclo de desenvolvimento foram adotadas para o produto PowerDNS Authoritative Server, que deverá lançar a versão 4.2 em breve.
Principais recursos do PowerDNS Recursor:
- Ferramentas para coleta remota de estatísticas;
- Reinicialização instantânea;
- Mecanismo integrado para conectar manipuladores na linguagem Lua;
- Suporte completo para DNSSEC e ;
- Suporte para RPZ (Response Policy Zones) e a capacidade de definir listas negras;
- Mecanismos anti-spoofing;
- Capacidade de gravar resultados de resolução como arquivos de zona BIND.
- Para garantir alto desempenho, são utilizados mecanismos modernos de multiplexação de conexão em FreeBSD, Linux e Solaris (kqueue, epoll, /dev/poll), bem como um analisador de pacotes DNS de alto desempenho capaz de processar dezenas de milhares de consultas paralelas.
Fonte: opennet.ru