{"id":36194,"date":"2019-10-31T22:10:13","date_gmt":"2019-10-31T19:10:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020\/"},"modified":"2019-10-31T22:10:13","modified_gmt":"2019-10-31T19:10:13","slug":"reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","title":{"rendered":"Lan\u00e7amento do PowerDNS Recursor 4.2 e iniciativa DNS flag day 2020","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ap\u00f3s um ano e meio de desenvolvimento apresentado<\/a><\/noindex> lan\u00e7amento do servidor DNS em cache PowerDNS Recursor 4.2<\/a><\/noindex>, respons\u00e1vel pela resolu\u00e7\u00e3o recursiva de nomes. PowerDNS Recursor \u00e9 constru\u00eddo sobre a mesma base de c\u00f3digo que o PowerDNS Authoritative Server, mas os servidores DNS recursivos e autorit\u00e1rios da PowerDNS evoluem em ciclos de desenvolvimento diferentes e s\u00e3o lan\u00e7ados como produtos separados. O c\u00f3digo do projeto \u00e9 distribu\u00eddo<\/a><\/noindex> sob a licen\u00e7a GPLv2. <\/p>\n

Na nova vers\u00e3o, todos os problemas relacionados ao processamento de pacotes DNS com os flags EDNS foram corrigidos. Nas vers\u00f5es antigas do PowerDNS Recursor at\u00e9 2016, era comum ignorar pacotes com flags EDNS n\u00e3o suportados, sem enviar uma resposta no formato antigo, descartando os flags EDNS, conforme exigido pela especifica\u00e7\u00e3o. Anteriormente, esse comportamento n\u00e3o padr\u00e3o era suportado no BIND como um contorno, mas dentro da iniciativa<\/a><\/noindex> em fevereiro DNS flag day<\/a><\/noindex>, os desenvolvedores de servidores DNS decidiram abandonar esse contorno. <\/p>\n

No PowerDNS, os principais problemas no processamento de pacotes com EDNS foram resolvidos j\u00e1 em 2017 com o lan\u00e7amento da vers\u00e3o 4.1, enquanto na vers\u00e3o 4.0 lan\u00e7ada em 2016 surgiram algumas incompatibilidades isoladas, que em geral n\u00e3o interferiam no funcionamento normal. No PowerDNS Recursor 4.2, assim como no BIND 9.14<\/a><\/noindex>, foram removidos os contornos de suporte a servidores autorit\u00e1rios que respondiam incorretamente a consultas com flags EDNS. At\u00e9 agora, se ap\u00f3s o envio de uma consulta com flags EDNS n\u00e3o houvesse resposta em um determinado intervalo de tempo, o servidor DNS considerava que os flags estendidos n\u00e3o eram suportados e enviava uma nova consulta sem os flags EDNS. Esse comportamento agora est\u00e1 desativado, pois a presen\u00e7a de tal c\u00f3digo aumentava a lat\u00eancia devido ao reenvio de pacotes, aumentava a carga na rede e causava ambiguidade na aus\u00eancia de resposta devido a falhas de rede, al\u00e9m de dificultar a implementa\u00e7\u00e3o de recursos baseados em EDNS, como a utiliza\u00e7\u00e3o de Cookies DNS para prote\u00e7\u00e3o contra ataques DDoS. <\/p>\n

No ano seguinte, foi decidido realizar um evento Dia da Flag DNS 2020<\/a><\/noindex>, que visa chamar a aten\u00e7\u00e3o para a solu\u00e7\u00e3o<\/a><\/noindex> problemas<\/a><\/noindex> com fragmenta\u00e7\u00e3o de IP ao processar mensagens DNS de grande tamanho. No \u00e2mbito da iniciativa est\u00e3o programados<\/a><\/noindex> registrar o tamanho recomendado dos buffers para EDNS at\u00e9 valores em torno de 1200 bytes, al\u00e9m de tornar<\/a><\/noindex> A manipula\u00e7\u00e3o de requisi\u00e7\u00f5es via TCP \u00e9 considerada obrigat\u00f3ria em servidores. Neste momento, \u00e9 essencial que haja suporte para o manuseio de requisi\u00e7\u00f5es via UDP, enquanto o TCP \u00e9 desej\u00e1vel, mas n\u00e3o obrigat\u00f3rio para o funcionamento (o padr\u00e3o prescreve a possibilidade de desativar o TCP). Prop\u00f5e-se a remo\u00e7\u00e3o da op\u00e7\u00e3o de desativa\u00e7\u00e3o do TCP do padr\u00e3o e a padroniza\u00e7\u00e3o da transi\u00e7\u00e3o do envio de requisi\u00e7\u00f5es via UDP para a aplica\u00e7\u00e3o do TCP em casos onde o tamanho de buffer EDNS configurado \u00e9 insuficiente.<\/p>\n

As altera\u00e7\u00f5es propostas no \u00e2mbito da iniciativa eliminar\u00e3o a confus\u00e3o quanto \u00e0 escolha do tamanho do buffer EDNS e resolver\u00e3o o problema da fragmenta\u00e7\u00e3o de grandes mensagens UDP, cuja manipula\u00e7\u00e3o frequentemente resulta na perda de pacotes e timeouts do lado do cliente. Do lado do cliente, o tamanho do buffer EDNS ser\u00e1 constante, enquanto as respostas grandes ser\u00e3o enviadas imediatamente ao cliente via TCP. A exclus\u00e3o do envio de mensagens grandes por UDP tamb\u00e9m permitir\u00e1 bloqueios. ataques<\/a><\/noindex> evita\u00e7\u00f5es de cache DNS baseadas na manipula\u00e7\u00e3o de pacotes UDP fragmentados (como na fragmenta\u00e7\u00e3o, o segundo fragmento n\u00e3o inclui o cabe\u00e7alho com o identificador, podendo ser forjado, pois s\u00f3 precisa coincidir com a soma de verifica\u00e7\u00e3o).<\/p>\n

No PowerDNS Recursor 4.2, foram consideradas as quest\u00f5es relacionadas a grandes pacotes UDP e feita a transi\u00e7\u00e3o 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 \u00e9 o m\u00e1ximo que garante que o tamanho da resposta DNS, considerando IPv6, se encaixe no valor m\u00ednimo de MTU (1280). O par\u00e2metro truncation-threshold tamb\u00e9m foi reduzido para 1232, que controla o corte de respostas enviadas ao cliente.<\/p>\n

Outras altera\u00e7\u00f5es no PowerDNS Recursor 4.2:<\/p>\n