As consultas DNS sempre trafegam pelo UDP?

Passei um tempo pesquisando esse tópico e não consigo encontrar uma resposta exata, por isso estou bastante confiante de que não é uma duplicata e, embora minha pergunta seja baseada em uma necessidade de segurança, acho que ainda é seguro pergunte aqui, mas deixe-me saber se eu preciso movê-lo para a comunidade de segurança.

Essencialmente, as consultas DNS usam TCP (se sim, qual cenário isso pode ocorrer)? Mais uma vez, estou falando apenas de consultas. É possível que eles viajem pelo TCP? Se os domínios tiverem apenas no máximo 253 bytes de comprimento e os pacotes UDP puderem ter até 512 bytes, as consultas sempre serão exibidas como UDP? Não achei que uma consulta resolvível pudesse ser grande o suficiente para exigir o uso do TCP. Se um servidor DNS recebesse uma solicitação para um domínio maior que 253 bytes, o servidor eliminaria / não tentaria resolvê-lo? Estou certo de que fiz algumas suposições falsas aqui.

Para algum contexto, estou trabalhando com o grupo de segurança para integrar consultas DNS em sua ferramenta de monitoramento de segurança e, por vários motivos, decidimos capturar esse tráfego via captura de pacote padrão em servidores DNS e controladores de domínio. O principal requisito é capturar todas as consultas DNS para que eles possam identificar qual cliente tentou resolver qualquer domínio. Com base nesse requisito, não estamos preocupados em capturar respostas DNS ou outro tráfego, como transferências de zona, o que também é motivado pelo fato de que precisamos limitar o volume de log o máximo possível. Assim, planejamos capturar apenas consultas DNS destinadas ao servidor DNS e enviadas por UDP. Para mais contexto (tipo de escopo de pergunta que se arrasta aqui), agora foi levantado que podemos precisar expandir a segurança ' s visibilidade para que eles possam monitorar atividades como canais secretos em execução no DNS (que também apresentariam a necessidade de capturar respostas DNS e, posteriormente, o tráfego TCP). Mas, mesmo nesse tipo de cenário, pensei que qualquer tráfego DNS de saída teria a forma de pesquisas / consultas, e que eles sempre seriam sobre UDP, mesmo que de uma fonte maliciosa (por causa do meu raciocínio no primeiro parágrafo). Portanto, isso traz algumas perguntas adicionais:

• No mínimo, não estaríamos capturando metade da conversa com a abordagem que descrevi? Ou um cliente enviaria tráfego DNS que não está na forma de uma consulta? (talvez como algum tipo de resposta à resposta de um servidor DNS e talvez acabe saindo pelo TCP)

• As consultas DNS podem ser modificadas para usar o TCP? Um servidor DNS aceitaria e responderia a uma consulta DNS vinda do TCP?

Não tenho certeza se é relevante, mas limitamos as solicitações de DNS a servidores DNS autorizados e bloqueamos todo o tráfego de saída pela porta 53. Sou definitivamente um novato, então, desculpe se minha pergunta não é compatível e avise-me. como eu deveria modificar.

As consultas DNS normais usam a porta UDP 53, mas as consultas mais longas (> 512 octetos) receberão uma resposta 'truncada', que resulta em uma conversa TCP 53 para facilitar o envio / recebimento de toda a consulta. Além disso, o servidor DNS se liga à porta 53, mas a própria consulta se origina em uma porta de número alto aleatória (49152 ou superior) enviada à porta 53. A resposta será retornada para essa mesma porta da porta 53.

Portas de rede usadas pelo DNS | Docs da Microsoft

Portanto, se você estiver planejando fazer uma espionagem de segurança nas consultas DNS da sua rede, precisará levar isso em consideração.

Quanto ao tráfego sem pesquisa, considere que o DNS também usa transferências de zona (tipo de consulta AXFR) para atualizar outros servidores DNS com novos registros. Um homem no ataque do meio pode começar com essa transferência, executando DDOS em um servidor de nomes Primário, para que fique muito ocupado para responder a um Secundário solicitando registros atualizados. O hacker então falsifica o mesmo Primário para alimentar registros 'envenenados' para o Secundário, que redireciona domínios DNS populares para hosts comprometidos.

Portanto, sua auditoria de segurança deve prestar muita atenção ao tipo de consulta AXFR, e seus sistemas DNS devem aceitar apenas trocas AXFR de endereços IP específicos.

Instituto SANS InfoSec - Sala de Leitura | sans.org

Isso começou como um comentário à resposta de George, mas demorou muito. O quadro geral é um pouco complicado, pois requer a compreensão de um pouco de história.

• O RFC 1035 originalmente exigia um limite de 512 bytes para evitar a fragmentação do UDP. Os datagramas UDP fragmentados e o TCP foram escolhidos como as opções de último recurso, a fim de minimizar a sobrecarga das transações DNS. As transferências de zona sempre usam TCP, devido a transferências de zona que ocupam> 512 bytes por natureza. (seria um desperdício de largura de banda começar com o UDP)

• A nova tentativa de TCP no truncamento é amplamente suportada, pois foi especificada na RFC 1123 desde 1989.

• O EDNS (0) é definido pela RFC 6891 (2013) e, antes disso, existia como uma Norma proposta desde 1999 . Ele define um mecanismo no qual clientes e servidores podem negociar tamanhos de UDP maiores que 512. Devido à novidade do EDNS (0), muitos dispositivos de hardware fazem suposições sobre a estrutura dos pacotes DNS que fazem com que os pacotes compatíveis sejam descartados. O motivo mais frequente é a suposição de que mensagens DNS com mais de 512 bytes são inválidas, mas essa é uma dentre várias.

Se dividirmos isso nos comportamentos observados:

1. As consultas DNS geralmente iniciam como UDP, a menos que seja conhecido antecipadamente que a resposta será muito grande para começar. (transferências de zona)
2. A resposta pode acionar uma nova tentativa de TCP no cliente se uma resposta truncada for vista. Isso é razoavelmente bem suportado.
3. Uma resposta UDP maior que 512 bytes pode ser vista se o cliente usou o EDNS (0) para anunciar uma carga útil maior e o servidor receptor a suporta. Isso só acontecerá se o hardware entre os dois não interferir e resultar em um pacote descartado ou mutilado.
4. O cliente pode optar por tentar novamente uma consulta EDNS (0) com uma carga útil anunciada menor se uma resposta não for vista, mas as especificidades variarão entre as implementações.
   • É importante observar que a resposta que finalmente chega pode ser muito grande para caber no tamanho solicitado, o que resulta no comportamento nº 2 acima. (tente novamente o TCP)
   • O lado do cliente pode optar por lembrar o tamanho que finalmente resultou em um sucesso. Isso permite que você evite desperdiçar consultas desnecessárias sondando-as novamente. Fazer o contrário seria um grande desperdício, principalmente se o resultado final exigisse o fallback do TCP.

Você também deve ter em mente que o RFC 7766 permite a reutilização de conexão pelo TCP , e é possível encontrar um pipeline de consulta sobre o TCP em estado selvagem. Algumas ferramentas não detectam consultas DNS além da primeira vista em uma sessão TCP, sendo o dnscap um exemplo disso.

Não é RFC 7766, Transporte DNS sobre TCP - requisitos de implementação .

1. Introdução

A maioria das transações de DNS [ RFC1034 ] ocorre no UDP [ RFC768 ]. O TCP [ RFC793 ] é sempre usado para transferências de zona completa (usando o AXFR) e geralmente é usado para mensagens cujos tamanhos excedem o limite original de 512 bytes do protocolo DNS. A crescente implantação da Segurança DNS (DNSSEC) e do IPv6 aumentou os tamanhos de resposta e, portanto, o uso do TCP. A necessidade de aumentar o uso do TCP também foi motivada pela proteção oferecida contra falsificação de endereço e, portanto, exploração do DNS em ataques de reflexão / amplificação. Agora é amplamente utilizado no Limite de taxa de resposta [ RRL1 ] [ RRL2 ]. Além disso, trabalhos recentes sobre soluções de privacidade de DNS, como [ DNS-over-TLS] é outra motivação para revisar os requisitos de DNS sobre TCP.

Seção 6.1.3.2 de [RFC1123] afirma:

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

No entanto, alguns implementadores consideraram o texto citado acima como significando que o suporte ao TCP é um recurso opcional do protocolo DNS.

A maioria dos operadores de servidores DNS já suporta TCP, e a configuração padrão para a maioria das implementações de software é oferecer suporte ao TCP. O público-alvo principal deste documento são os implementadores cujo suporte limitado ao TCP restringe a interoperabilidade e dificulta a implantação de novos recursos de DNS.

Portanto, este documento atualiza as principais especificações do protocolo DNS, de modo que o suporte ao TCP é uma parte NECESSÁRIA de uma implementação completa do protocolo DNS.

Existem várias vantagens e desvantagens no aumento do uso do TCP (consulte o Apêndice A ), bem como detalhes da implementação que precisam ser considerados. Este documento aborda esses problemas e apresenta o TCP como uma alternativa de transporte válida para o DNS. Ele estende o conteúdo do [ RFC5966 ], com considerações e lições adicionais aprendidas com pesquisas, desenvolvimentos e implementação do TCP no DNS e em outros protocolos da Internet.

Embora este documento não exija requisitos específicos para os operadores de servidores DNS, ele oferece algumas sugestões aos operadores para ajudar a garantir que o suporte ao TCP em seus servidores e na rede seja ideal. Deve-se observar que a falha no suporte ao TCP (ou o bloqueio do DNS sobre TCP na camada de rede) provavelmente resultará em falha na resolução e / ou tempos limite no nível do aplicativo.

Você não deve filtrar o TCP / 53 em nenhuma direção. Por exemplo, as nsupdateconsultas podem usar o TCP assim que a solicitação for muito grande (o que pode acontecer rapidamente). Portanto, você deve permitir que o UDP e o TCP da porta 53 (no IPv4 e V6!) Fluam em todas as direções.

Além disso, há cada vez mais trabalho para o DNS sobre TLS, portanto, o TCP será necessário nas duas direções. Veja RFC7858.