Canton: /* 2020-10-01 (1º de outubro de 2020) */

2020-09-09T16:02:51Z

2020-10-01 (1º de outubro de 2020)

Canton: Criou página com ' ==A data exata== ====2020-10-01 (1º de outubro de 2020)==== ==DNS Flag Day 2020== A comunidade DNS tem discutido problemas persistentes de interoperabilidade e desempenho co...'

2020-09-09T16:01:38Z

Criou página com ' ==A data exata== ====2020-10-01 (1º de outubro de 2020)==== ==DNS Flag Day 2020== A comunidade DNS tem discutido problemas persistentes de interoperabilidade e desempenho co...'

Página nova

==A data exata==
====2020-10-01 (1º de outubro de 2020)====
==DNS Flag Day 2020==
A comunidade DNS tem discutido problemas persistentes de interoperabilidade e desempenho com o sistema DNS em listas de mala direta do setor e em conferências como o painel de discussão DNS-OARC 30 ( vídeo , slides ).

O plano proposto para o DNS Flag Day 2020 foi anunciado em outubro de 2019 em RIPE78 por Petr Špaček, CZ.NIC e Ondřej Surý, ISC ( vídeo , slides ). Este ano, estamos nos concentrando em problemas com fragmentação de IP de pacotes DNS.

A fragmentação de IP não é confiável na Internet hoje e pode causar falhas de transmissão quando grandes mensagens de DNS são enviadas via UDP. Mesmo quando a fragmentação funciona, ela pode não ser segura; é teoricamente possível falsificar partes de uma mensagem DNS fragmentada, sem fácil detecção na extremidade receptora.

Bonica R. et al, " IP Fragmentation Considered Fragile ", Work in Progress, July 2018 Huston G., " IPv6, Large UDP Packets and the DNS ", agosto de 2017 Fujiwara K., “ Measures against cache poisoning attack using IP fragmentation in DNS ”, maio de 2019 Fujiwara K. et al, " Avoid IP fragmentation in DNS ", setembro de 2019 Recentemente, houve um artigo e uma apresentação Desfragmentando DNS - Determinando o tamanho de resposta UDP máximo ideal para DNS por Axel Koolhaas e Tjeerd Slokker em colaboração com NLnet Labs que explorou os dados do mundo real usando as sondas RIPE Atlas e os pesquisadores sugeriram diferentes valores para IPv4 e IPv6 e em diferentes cenários. Isso é prático para os operadores de servidor que conhecem seu ambiente, e os padrões no software DNS devem refletir o tamanho mínimo seguro que é 1232 .

Esses problemas podem ser resolvidos a) configurando servidores para limitar as mensagens DNS enviadas por UDP a um tamanho que não acione a fragmentação em links de rede típicos e b) garantindo que os servidores DNS possam mudar de UDP para TCP quando uma resposta DNS for muito grande para caber neste tamanho de buffer limitado.
==Considerações sobre o tamanho da mensagem==
O tamanho ideal da mensagem DNS para evitar a fragmentação de IP e, ao mesmo tempo, minimizar o uso de TCP dependerá da Unidade Máxima de Transmissão (MTU) dos links de rede física que conectam dois terminais de rede. Infelizmente, ainda não existe um mecanismo padrão para que os implementadores de servidor DNS acessem essas informações. Até que tal padrão exista, recomendamos que o tamanho do buffer EDNS seja, por padrão , definido como um valor pequeno o suficiente para evitar a fragmentação na maioria dos links de rede em uso hoje.

Um tamanho de buffer EDNS de 1232 bytes evitará a fragmentação em quase todas as redes atuais. Isso é baseado em um MTU de 1280, que é exigido pela especificação IPv6, menos 48 bytes para os cabeçalhos IPv6 e UDP e a pesquisa mencionada.

Observe que esta recomendação é para um valor padrão , a ser usado quando melhores informações não estiverem disponíveis. Os operadores ainda podem configurar valores maiores se suas redes suportarem quadros de dados maiores e eles tiverem certeza de que não há risco de fragmentação de IP. Os fornecedores de servidor DNS podem usar tamanhos de pacote maiores (ou menores) se melhores informações sobre o MTU estiverem disponíveis no kernel.
==Ações==
===Operadores de DNS Autoritativo:===
#Garantir que a porta TCP 53 esteja disponível e respondendo em seu servidor, livre de qualquer firewall.
#Configurar o buffer EDNS para no máximo de 1232 bytes.
#O servidor não deve enviar respostas maiores do que o buffer definido.
Para testar seu servidor execute o comando a seguir, inserindo o IP do seu equipamento:
====Autoritativo do seu domínio====
<pre>
dig seudominio.tld. TXT @IP_SERVER_AUTORITATIVO
</pre>A resposta esperada deverá ter a mensagem ";; Truncated, retrying in TCP mode."<pre>
dig +tcp seudominio.tld. TXT @IP_SERVER_AUTORITATIVO
</pre>Não pode ocorrer falhas.

Para ambos espera-se ver algo como "udp: 1232" na resposta.

Todas as consultas DNS devem ser bem-sucedidas e os comandos devem retornar os mesmos resultados com e sem a opção +tcp.
====Recursão para seu domínio====
<pre>
dig seudominio.tld. TXT @IP_SERVER_RECURSIVO
</pre>A resposta esperada deverá ter a mensagem ";; Truncated, retrying in TCP mode."<pre>
dig +tcp seudominio.tld. TXT @IP_SERVER_RECURSIVO
</pre>Não pode ocorrer falhas.

Para ambos espera-se ver algo como "udp: 1232" na resposta.

Todas as consultas DNS devem ser bem-sucedidas e os comandos devem retornar os mesmos resultados com e sem a opção +tcp.
===Operadores de DNS Recursivo:===
#Garantir que a porta TCP 53 esteja disponível e respondendo em seu servidor, livre de qualquer firewall.
#Configurar o buffer EDNS para no máximo de 1232 bytes.
#O servidor não deve enviar respostas maiores do que o buffer definido.
#Consultas UDP devem retornar "truncated" (com TC = 1), no caso ele deve retentar em TCP
Para testar seu servidor execute o comando a seguir, inserindo o IP do seu equipamento:<pre>
dig test.knot-resolver.cz. TXT @IP_SERVER_RECURSIVO
</pre>A resposta esperada deverá ter a mensagem ";; Truncated, retrying in TCP mode."<pre>
dig +tcp test.knot-resolver.cz. TXT @IP_SERVER_RECURSIVO
</pre>Não pode ocorrer falhas.

Para ambos espera-se ver algo como "udp: 1232" na resposta.
==Como configurar o EDNS Buffer==
*BIND
<pre>
options {
edns-udp-size 1232;
max-udp-size 1232;
};
</pre>
*Knot DNS
<pre>
server:
max-udp-payload: 1232
</pre>
*Knot Resolver
<pre>
net.bufsize(1232)
</pre>
*PowerDNS Authoritative
<pre>
udp-truncation-threshold=1232
</pre>
*PowerDNS Recursor
<pre>
edns-outgoing-bufsize=1232
udp-truncation-threshold=1232
</pre>
*Unbound
<pre>
server:
edns-buffer-size: 1232
</pre>
*NSD
<pre>
server:
ipv4-edns-size: 1232
ipv6-edns-size: 1232
</pre>Para mais informações, visite: https://dnsflagday.net/2020/

@@ Linha 1: / Linha 1: @@
 ==A data exata==
-====2020-10-01 (1º de outubro de 2020)====
+-10-01 (1º de outubro de 2020)
 ==DNS Flag Day 2020==
 A comunidade DNS tem discutido problemas persistentes de interoperabilidade e desempenho com o sistema DNS em listas de mala direta do setor e em conferências como o painel de discussão DNS-OARC 30 ( vídeo , slides ).

Dns flag day 2020 - Histórico de revisão

Canton: /* 2020-10-01 (1º de outubro de 2020) */

Canton: Criou página com ' ==A data exata== ====2020-10-01 (1º de outubro de 2020)==== ==DNS Flag Day 2020== A comunidade DNS tem discutido problemas persistentes de interoperabilidade e desempenho co...'