As consultas DNS sempre viajam pelo UDP?

Question

Eu gastei um pouco de tempo pesquisando esse tópico e não consigo encontrar uma resposta exata, então estou bastante confiante de que não é uma duplicata, e embora minha pergunta seja baseada em uma necessidade de segurança, eu acho que é ainda é seguro perguntar aqui, mas me avise se eu precisar mover a comunidade de segurança.

Essencialmente, as consultas DNS sempre usam TCP (em caso afirmativo, que cenário isso poderia ocorrer)? Mais uma vez, estou falando apenas de consultas. É possível para eles viajarem pelo TCP? Se os domínios só puderem ter no máximo 253 bytes de comprimento, e os pacotes UDP puderem ter até 512 bytes, as consultas não sairão sempre como UDP? Não achei que uma consulta solucionável pudesse ser grande o suficiente para exigir o uso do TCP. Se um servidor DNS obtivesse uma solicitação para um domínio com mais de 253 bytes, o servidor o descartaria ou não tentaria resolvê-lo? Tenho certeza de que fiz algumas suposições falsas aqui.

Para algum contexto, estou trabalhando com o grupo de segurança para integrar as consultas DNS em sua ferramenta de monitoramento de segurança e, por várias razões, decidimos capturar esse tráfego por meio da captura padrão de pacotes em servidores DNS e controladores de domínio. O requisito principal é capturar todas as consultas do DNS para que elas possam identificar qual cliente tentou resolver qualquer domínio. Com base nesse requisito, não estamos preocupados em capturar respostas de DNS ou outro tráfego, como transferências de zona, o que também é impulsionado pelo fato de que precisamos limitar o volume de logs o máximo possível. Como tal, estamos planejando capturar somente consultas DNS destinadas ao servidor DNS e enviadas por UDP. Para mais contexto (tipo de escopo de pergunta rastejando aqui), foi levantado que talvez precisássemos expandir a visibilidade da segurança para que eles pudessem monitorar atividades como canais secretos rodando sobre DNS (o que apresentaria a necessidade de capturar respostas de DNS também, e, posteriormente, o tráfego TCP). Mas mesmo nesse tipo de cenário, eu pensei que qualquer tráfego de saída de DNS seria na forma de pesquisas / consultas, e que estas seriam sempre sobre UDP, mesmo que de uma fonte maliciosa (por causa do meu raciocínio no primeiro parágrafo). Isso traz algumas perguntas adicionais:

• Será que no mínimo estaríamos capturando metade da conversa com a abordagem que descrevi? Ou um cliente enviaria algum tráfego de DNS que não estivesse na forma de uma consulta? (talvez como algum tipo de resposta à resposta de um servidor DNS, e talvez acabe saindo por 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 todos os outros tráfegos pela porta 53. Definitivamente, sou um novato, por isso lamento se minha pergunta não for compatível e deixe-me saber como devo modificar.

    

Answer 1

As consultas normais de DNS usam a porta UDP 53, mas 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 vincula à porta 53, mas a própria consulta se origina em uma porta aleatória de número alto (49152 ou superior) enviada para a porta 53. A resposta será retornada para essa mesma porta da porta 53.

Portas de rede usadas pelo DNS | Microsoft Docs

Então, se você está planejando fazer alguma espionagem de segurança nas consultas DNS de sua rede, você 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 tal transferência, DDOS usando um servidor de nomes da Primária de modo que esteja muito ocupado para responder a um Secundário solicitando registros atualizados. O hacker então falsifica a mesma Primária para alimentar registros 'envenenados' para o Secondary, que redirecionam domínios DNS populares para hosts comprometidos.

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

Sala de leitura do InfoSec do Instituto SANS | sans.org

    

Answer 2

Isso começou como um comentário para a resposta de George, mas ficou muito tempo. A imagem maior é um pouco complicada, pois requer a compreensão de um pouco da história.

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

• A repetição de TCP no truncamento é amplamente suportada, conforme especificado em RFC 1123 desde 1989.

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

Se dividirmos isso nos comportamentos observados:

1. As consultas DNS geralmente começam 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 disparar uma nova tentativa TCP no cliente se uma resposta truncada for vista. Isso é bastante bem suportado.
3. Uma resposta UDP de mais de 512 bytes pode ser vista se o cliente usou EDNS (0) para anunciar uma carga útil maior, e o servidor de recebimento a suporta. Isso só acontecerá se o hardware entre os dois não interferir e resultar em um pacote descartado ou destroçado.
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 os detalhes variarão entre as implementações.
   • É importante observar que a resposta que finalmente é obtida pode ser muito grande para caber no tamanho solicitado, o que resulta no comportamento # 2 acima. (tente novamente o TCP)
   • O lado do cliente pode escolher lembrar o tamanho que finalmente resultou em um sucesso. Isso permite evitar o desperdício de consultas desnecessárias, analisando-as novamente. Fazer o contrário seria um grande desperdício, especialmente se o resultado final exigisse o fallback do TCP.

Você também deve ter em mente que a RFC 7766 permite a reutilização de conexões via TCP , e É possível encontrar pipelining de consulta sobre TCP no estado selvagem. Algumas ferramentas não detectam consultas DNS além do primeiro visto em uma sessão TCP, sendo o dnscap um exemplo disso.

    

Answer 3

RFC 7766, Transporte DNS sobre TCP - Requisitos de Implementação .

1. Introduction

Most DNS [RFC1034] transactions take place over UDP [RFC768]. TCP [RFC793] is always used for full zone transfers (using AXFR) and is often used for messages whose sizes exceed the DNS protocol's original 512-byte limit. The growing deployment of DNS Security (DNSSEC) and IPv6 has increased response sizes and therefore the use of TCP. The need for increased TCP use has also been driven by the protection it provides against address spoofing and therefore exploitation of DNS in reflection/amplification attacks. It is now widely used in Response Rate Limiting [RRL1] [RRL2]. Additionally, recent work on DNS privacy solutions such as [DNS-over-TLS] is another motivation to revisit DNS-over-TCP requirements.

Section 6.1.3.2 of [RFC1123] states:

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

However, some implementors have taken the text quoted above to mean that TCP support is an optional feature of the DNS protocol.

The majority of DNS server operators already support TCP, and the default configuration for most software implementations is to support TCP. The primary audience for this document is those implementors whose limited support for TCP restricts interoperability and hinders deployment of new DNS features.

This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation.

There are several advantages and disadvantages to the increased use of TCP (see Appendix A) as well as implementation details that need to be considered. This document addresses these issues and presents TCP as a valid transport alternative for DNS. It extends the content of [RFC5966], with additional considerations and lessons learned from research, developments, and implementation of TCP in DNS and in other Internet protocols.

Whilst this document makes no specific requirements for operators of DNS servers to meet, it does offer some suggestions to operators to help ensure that support for TCP on their servers and network is optimal. It should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) will probably result in resolution failure and/or application-level timeouts.

    

Answer 4

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

Além disso, há mais e mais trabalho em relação ao DNS sobre TLS, portanto, o TCP será necessário em ambas as direções. Veja RFC7858.