Uma melhoria prática no Transporte DNS sobre UDP em IPv6″
21/08/2024
Por Hugo Salgado y Alejandro Acosta
Introdução e formulação do problema
Neste documento, queremos discutir acerca de um draft (rascunho de trabalho para se tornar um padrão) existente no IETF que chamou nossa atenção. Trata-se de um documento que envolve dois mundos muito interessantes: IPv6 e DNS. Este draft introduz melhores práticas para o transporte de DNS sobre IPv6.
O draft entitula-se “DNS over IPv6 Best Practices” e pode ser encontrado aqui.
Do que trata o documento e o que ele busca resolver?”
O documento descreve como o Protocolo de Nomes de Domínio (DNS) deve ser transmitido sobre o IPv6 [RFC8200].”
Ao enviar pacotes de DNS através do IPv6, foram identificados alguns problemas operacionais e o draft procura resolver esses problemas.
Contexto técnico
O protocolo IPv6 exige um tamanho mínimo de unidade de transmissão (MTU) de 1280 octetos. De acordo com a Seção 5 “Problemas de tamanho de pacote” do RFC8200, é estabelecido que cada enlace na Internet deva ter um MTU de 1280 octetos ou mais. Se um enlace não puder transmitir um pacote de 1280 octetos em uma única peça, deverá fornecer-se o serviço de fragmentação e remontagem específicos do enlace em uma camada inferior ao IPv6
Imagem tomada de: https://www.slideshare.net/slideshow/naveguemos-por-internet-con-ipv6/34651833#2
Usando a Descoberta de MTU de Rota (PMTUD) e a fragmentação em IPv6 (somente na origem), é possível enviar pacotes maiores. No entanto, a experiência operacional aponta que o envio de grandes pacotes de DNS sobre UDP em IPv6 resulta em altas taxas de prejuízo. Alguns estudos –de muitos anos atrás, mas que servem como contexto – evidenciaram que cerca de 10% dos roteadores em IPv6 descartam todos os fragmentos IPv6 e 40% deles bloqueiam as mensagens ‘Packet Too Big’, impossibilitando a negociação com os clientes.” (“M. de Boer, J. Bosma, ”Discovering Path MTU black holes on the Internet using RIPE Atlas”)
A maioria dos protocolos de transporte modernos, como TCP [TCP] e QUIC [QUIC], inclui técnicas de segmentação que permitem enviar fluxos de dados maiores sobre o IPv6.
Um pouco de história
O Sistema de Nomes de Domínio (DNS) foi definido originalmente nos documentos RFC 1034 e RFC 1035. Projetado para funcionar sobre diferentes protocolos de transporte, incluindo UDP e TCP, e mais recentemente foi estendido para operar sobre QUIC. Esses protocolos de transporte podem ser utilizados tanto em IPv4 quanto em IPv6.
Ao desenhar o DNS, foi estabelecido um limite de 512 bytes no tamanho dos pacotes DNS transmitidos mediante UDP. Se uma mensagem fosse mais longa, era truncada e o bit de Truncamento (TC) era acionado para indicar que a resposta estava incompleta, permitindo que o cliente tentasse novamente com TCP.
Com esse comportamento original, o UDP sobre o IPv6 não excedia o MTU (unidade máxima de transmissão) do enlace IPv6, evitando problemas operacionais devido à fragmentação. Porém, com a introdução das extensões EDNS0 (RFC6891), foi ampliado ao máximo para um teórico de 64KB, fazendo com que algumas respostas superassem o limite de 512 bytes para UDP, resultando em tamanhos que poderiam exceder o Path MTU, ocasionando conexões TCP e afetando a escalabilidade dos servidores DNS.
Vamos Falar de DNS sobre IPv6
O DNS sobre IPv6 foi desenhado para funcionar sobre UDP, bem como TCP ou QUIC. O UDP fornece apenas portas de origem e destino, um campo de longitude e uma soma de verificação simples, sendo um protocolo sem conexão. Em contraste, TCP e QUIC oferecem características adicionais como segmentação de pacotes, confiabilidade, correção de erros e estado de conexão.
O funcionamento do DNS sobre UDP em IPv6 é adequado para tamanhos de pacotes pequenos, mas se torna menos confiável com tamanhos maiores, principalmente quando for necessária a fragmentação de datagramas IPv6.
Por outro lado, o DNS sobre TCP ou QUIC em IPv6 funciona bem com todos os tamanhos de pacotes. Entretanto, o uso de um protocolo com estado como TCP ou QUIC exige mais recursos do servidor DNS (e de outros equipamentos como firewalls, DPIs, IDS, etc.), podendo atingir a escalabilidade. Isto pode ser uma compensação razoável para servidores que precisam enviar pacotes de resposta DNS maiores.
A sugestão do draft quanto ao DNS sobre o UDP, orienta a limitar o tamanho dos pacotes DNS sobre o UDP no IPv6 a 1280 octetos. Isso evita a necessidade de fragmentação do IPv6 ou de descoberta do MTU do caminho (Path MTU Discovery), garantindo uma maior confiabilidade.
A maioria das consultas e respostas DNS se encaixarão dentro desse limite de tamanho de pacote, portanto, poderá ser enviada através do UDP. Pacotes DNS maiores não devem ser enviados mediante o UDP; em vez disso, devem ser enviados através deTCP ou QUIC, como será mencionado na seção a seguir.
DNS sobre TCP e QUIC
Quando é necessário transportar pacotes DNS maiores, recomenda-se utilizar DNS sobre TCP ou QUIC. Esses protocolos gerenciam a segmentação e ajustam de maneira confiável o tamanho de seus segmentos para diferentes valores de MTU do enlace e do caminho, tornando-os muito mais confiáveis que o uso de UDP com fragmentação IPv6.
A seção 4.2.2 do [RFC1035] descreve o uso de TCP para transportar mensagens DNS, enquanto o [RFC9250] explica como implementar DNS sobre QUIC para fornecer confidencialidade no transporte. Além disso, os requisitos operacionais para DNS sobre TCP estão descritos no [RFC9210].
Segurança
A mudança de UDP para TCP/QUIC para respostas grandes implica que o servidor DNS deve manter um estado adicional para cada consulta recebida através de TCP/QUIC. Isso consumirá recursos adicionais nos servidores e afetará a escalabilidade do sistema DNS. Além disso, essa situação pode deixar os servidores vulneráveis a ataques de Negação de Serviço (DoS).
Esta é a forma correta?
Embora acreditemos que essa solução trará muitos benefícios para o ecossistema do IPv6 e do DNS, trata-se de um remendo operacional temporário, mas que não resolve o problema da raiz.
Acreditamos que a solução correta seja que a fragmentação na origem funcione, que o PMTUD não esteja quebrado no caminho e que os cabeçalhos de fragmentação sejam permitidos pelos dispositivos de segurança. Isso requer mudanças em diversos atores da Internet, o que poderia levar bastante tempo, mas isso não significa que devemos abandonar a educação e os esforços para conseguir fazer o que é certo.