Após um ano e meio de desenvolvimento lançamento do servidor DNS em cache , responsável pela resolução recursiva de nomes. PowerDNS Recursor é construído sobre a mesma base de código que o PowerDNS Authoritative Server, mas os servidores DNS recursivos e autoritários da PowerDNS evoluem em ciclos de desenvolvimento diferentes e são lançados como produtos separados. O código do projeto sob a licença GPLv2.
Na nova versão, todos os problemas relacionados ao processamento de pacotes DNS com os flags EDNS foram corrigidos. Nas versões antigas do PowerDNS Recursor até 2016, era comum ignorar pacotes com flags EDNS não suportados, sem enviar uma resposta no formato antigo, descartando os flags EDNS, conforme exigido pela especificação. Anteriormente, esse comportamento não padrão era suportado no BIND como um contorno, mas dentro em fevereiro , os desenvolvedores de servidores DNS decidiram abandonar esse contorno.
No PowerDNS, os principais problemas no processamento de pacotes com EDNS foram resolvidos já em 2017 com o lançamento da versão 4.1, enquanto na versão 4.0 lançada em 2016 surgiram algumas incompatibilidades isoladas, que em geral não interferiam no funcionamento normal. No PowerDNS Recursor 4.2, assim como no , foram removidos os contornos de suporte a servidores autoritários que respondiam incorretamente a consultas com flags EDNS. Até agora, se após o envio de uma consulta com flags EDNS não houvesse resposta em um determinado intervalo de tempo, o servidor DNS considerava que os flags estendidos não eram suportados e enviava uma nova consulta sem os flags EDNS. Esse comportamento agora está desativado, pois a presença de tal código aumentava a latência devido ao reenvio de pacotes, aumentava a carga na rede e causava ambiguidade na ausência de resposta devido a falhas de rede, além de dificultar a implementação de recursos baseados em EDNS, como a utilização de Cookies DNS para proteção contra ataques DDoS.
No ano seguinte, foi decidido realizar um evento , que visa chamar a atenção para com fragmentação de IP ao processar mensagens DNS de grande tamanho. No âmbito da iniciativa registrar o tamanho recomendado dos buffers para EDNS até valores em torno de 1200 bytes, além de A manipulação de requisições via TCP é considerada obrigatória em servidores. Neste momento, é essencial que haja suporte para o manuseio de requisições via UDP, enquanto o TCP é desejável, mas não obrigatório para o funcionamento (o padrão prescreve a possibilidade de desativar o TCP). Propõe-se a remoção da opção de desativação do TCP do padrão e a padronização da transição do envio de requisições via UDP para a aplicação do TCP em casos onde o tamanho de buffer EDNS configurado é insuficiente.
As alterações propostas no âmbito da iniciativa eliminarão a confusão quanto à escolha do tamanho do buffer EDNS e resolverão o problema da fragmentação de grandes mensagens UDP, cuja manipulação frequentemente resulta na perda de pacotes e timeouts do lado do cliente. Do lado do cliente, o tamanho do buffer EDNS será constante, enquanto as respostas grandes serão enviadas imediatamente ao cliente via TCP. A exclusão do envio de mensagens grandes por UDP também permitirá bloqueios. 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).
No PowerDNS Recursor 4.2, foram consideradas as questões relacionadas a grandes pacotes UDP e feita a transição para o uso do tamanho de buffer EDNS (edns-outgoing-bufsize) de 1232 bytes, em vez do limite previamente utilizado de 1680 bytes, o que deve reduzir significativamente a probabilidade de perda de pacotes UDP. O valor de 1232 foi escolhido, pois é o máximo que garante que o tamanho da resposta DNS, considerando IPv6, se encaixe no valor mínimo de MTU (1280). O parâmetro truncation-threshold também foi reduzido para 1232, que controla o corte de respostas enviadas ao cliente.
Outras alterações no PowerDNS Recursor 4.2:
- Adicionada a suporte ao mecanismo (X-Proxied-For), que é equivalente ao cabeçalho HTTP X-Forwarded-For para DNS, permitindo transmitir informações sobre o endereço IP e o número da porta do iniciador original da requisição, redirecionada por meio de proxies intermediários e balanceadores de carga (por exemplo, dnsdist). Para habilitar o XPF, estão previstas opções como” e “«;
- Melhor suporte para extensão EDNS (ECS), que permite transmitir em requisições DNS ao servidor DNS autoritativo informações sobre a sub-rede da qual foi enviado o pedido original, que foi retransmitido em cadeia (dados sobre a sub-rede original do cliente são necessários para o funcionamento eficaz das redes de entrega de conteúdo). Na nova versão, foram adicionadas configurações para controle seletivo da aplicação do EDNS Client Subnet:» com a lista de máscaras de rede para as quais o IP será utilizado no ECS em solicitações de saída. Para endereços que não se enquadram nas máscaras especificadas, será utilizado o endereço geral indicado na diretiva ««. Através da diretiva «» é possível definir as sub-redes das solicitações de entrada com valores ECS que não serão substituídos;
- Para servidores que processam um grande número de solicitações por segundo (mais de 100 mil), a diretiva ««, define 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 modo ««).
- Adicionada a configuração de para definir seu próprio arquivo com de domínios nos quais os usuários podem registrar seus subdomínios, em vez da lista incorporada do PowerDNS Recursor.
O projeto PowerDNS também anunciou a transição para um ciclo de desenvolvimento de seis meses, de acordo com o qual o próximo lançamento significativo do PowerDNS Recursor 4.3 é esperado para janeiro de 2020. Atualizações para lançamentos significativos serão formadas ao longo do ano, após o qual correções de vulnerabilidades serão lançadas por mais seis meses. Assim, o suporte para a versã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, cuja versão 4.2 é esperada em breve.
Principais recursos do PowerDNS Recursor:
- Ferramentas para coleta remota de estatísticas;
- Reinício instantâneo;
- Motor embutido para conexão de manipuladores na linguagem Lua;
- Apoio completo a DNSSEC e ;
- Suporte a RPZ (Response Policy Zones) e possibilidade de definição de listas de bloqueio;
- Mecanismos de combate a spoofing;
- Capacidade de registrar os resultados da resolução em arquivos de zona BIND.
- Para garantir alta performance, são utilizados modernos mecanismos de multiplexação de conexões no FreeBSD, Linux e Solaris (kqueue, epoll, /dev/poll), assim como um parser de pacotes DNS de alta performance, capaz de processar dezenas de milhares de solicitações paralelas.
Fonte: opennet.ru
