É verdade que um servidor de nomes precisa responder a consultas sobre TCP?

Question

Eu sou o processo de configurar um monitoramento de servidores DNS de vários grandes hosts da web. Meu objetivo é comparar os tempos de resposta de seus servidores de DNS rastreando sua resposta ao ping.

No processo, descobri que os servidores de nomes Bluehost não respondem ao ping. Eu tentei obter mais informações executando Pingdom DNS Check no bluehost.com e produziu o seguinte erro:

Name server ns1.bluehost.com (74.220.195.31) does not answer queries over TCP.

The name server failed to answer queries sent over TCP. This is probably due to the name server not correctly set up or due to misconfgured filtering in a firewall. It is a rather common misconception that DNS does not need TCP unless they provide zone transfers - perhaps the name server administrator is not aware that TCP usually is a requirement.

Eu gostaria de saber o seguinte:

• Até que ponto é a afirmação acima verdade?
• Quais são as implicações de um servidor de nomes não respondendo a perguntas sobre TCP?

Answer 1

O texto de diagnóstico do Pingdom está exatamente correto. TCP é não apenas para transferências de zona.

As implementações do servidor DNS são agora "obrigatórias" (na medida em que qualquer RFC requer alguma coisa) para suportar o TCP, por RFC 5966 ," Transporte de DNS sobre TCP - Requisitos de Implementação ".

Note que este é um requisito na implementação do software para servidores, ele não se aplica estritamente à operação de qualquer servidor - a prática operacional não é coberta.

Dito isto, se os servidores DNS específicos não estiverem configurados para suportar o TCP ou se estiverem bloqueados, o efeito a longo prazo será a incapacidade de suportar o DNSSEC corretamente. Da mesma forma, qualquer outro dado do DNS que faça com que as respostas excedam 512 bytes pode ser bloqueado.

ob disclaimer: Eu escrevi essa RFC.

EDIT RFC 5966 foi agora substituído por RFC 7766

    

Answer 2

ele deve suportar TCP e UDP - o TCP é para tamanhos de resposta > 512 bytes (o que incluiria transferências de zona) (de acordo com as coisas que eu li, de qualquer forma. Eu normalmente habilito TCP e UDP para os NS que eu executo. ..)

    

Answer 3

É bom saber o que as RFCs dizem sobre o assunto, e já temos uma boa resposta autoritária sobre isso, mas para fins práticos, eu acho o conselho do Prof. Daniel J. Bernstein, PhD, o autor do DJBDNS, muito divertido.

link (2003-01-16)

When are TCP queries sent?

If you're in one of the following situations, you need to configure your DNS server to answer TCP queries:

• You want to publish record sets larger than 512 bytes. (This is almost always a mistake.)
• You want to allow outgoing zone transfers, for example to a third-party server.
• A parent server refuses to delegate a name to you until you set up TCP service.

If you aren't in any of those situations, you have no need to provide TCP service, and you should not set it up. DNS-over-TCP is much slower than DNS-over-UDP and is inherently much more vulnerable to denial-of-service attacks. (This applies to BIND too.)

Observe que ele omite uma menção explícita ao DNSSEC; A razão disso é que, segundo a DJB, o DNSSEC se enquadra na categoria de "sempre um erro". Consulte o link para obter mais detalhes. O DJB tem um padrão alternativo, chamado DNSCurve - link - que já foi adotado de forma independente por alguns provedores (como o OpenDNS). De interesse: link .

Observe que, se a documentação acima na configuração DJBDNS for qualquer indicação de seus recursos, parece que ela suporta apenas o AXFR para TCP. Como muitos provedores ainda usam DJBDNS, eles dificilmente suportariam DNS sobre TCP sem esforços extras.

P.S. Note que DJB, de fato, pratica o que ele prega. Seus próprios servidores, (1), executam o DNSCurve, (2), não respondem adequadamente ao TCP. Somente o +notcp seria bem-sucedido (o que é padrão):

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

, enquanto um +tcp falharia (aparentemente com uma mensagem de erro diferente, dependendo de qual servidor foi selecionado):

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached

    

Answer 4

O TCP é necessário apenas e geralmente usado somente quando uma resposta longa é necessária. Pode haver impactos negativos. As transferências de zona são feitas pelo TCP, pois são grandes e precisam ser confiáveis. Não permitir TCP de servidores não confiáveis é uma maneira de garantir que apenas pequenas respostas sejam dadas.

Com a introdução de respostas de DNS assinadas, houve um requisito para o afrouxamento do limite de 512 bytes para as respostas do UPD. O EDNS0 fornece o mecanismo para respostas UDP mais longas. A falha em permitir que o DNS sobre TCP seja altamente provável de quebrar uma implementação segura do DNS.

É perfeitamente possível executar um servidor DNS que tenha apenas a porta UDP 53 aberta à Internet. O acesso TCP aos peers de DNS é necessário, mas esta é uma pequena lista de hosts.

Existe uma nova RFC596 que agora exige TCP para uma implementação completa do DNS. Isso é destinado a implementadores. Os documentos especificamente não abordam os operadores, mas avisam que não permitir o TCP pode resultar em vários cenários de falha. Ele detalha uma ampla variedade de falhas que podem ocorrer se o DNS sobre TCP não for suportado.

Houve discussões sobre o uso do TCP para impedir ataques de amplificação de DNS. O TCP tem seus próprios riscos de negação de serviço, mas a distribuição é mais difícil.