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

23

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

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

O servidor de nomes ns1.bluehost.com (74.220.195.31) não responde a consultas por TCP.

O servidor de nomes falhou ao responder às perguntas enviadas pelo TCP. Provavelmente, o servidor de nomes não foi configurado corretamente ou a filtragem incorreta em um firewall. É um equívoco bastante comum que o DNS não precise do TCP, a menos que ele forneça transferências de zona - talvez o administrador do servidor de nomes não esteja ciente de que o TCP geralmente é um requisito.

Eu gostaria de saber o seguinte:

Até que ponto a afirmação acima é verdadeira?
Quais são as implicações de um servidor de nomes não responder a consultas por TCP?

domain-name-system nameserver

— Taras Mankovski
fonte

47

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

As implementações de servidor DNS agora são "necessárias" (na medida em que qualquer RFC exige alguma coisa) para oferecer suporte ao TCP, de acordo com a RFC 5966 , "Transporte de DNS sobre TCP - Requisitos de Implementação".

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

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

ob isenção de responsabilidade: eu escrevi que RFC.

EDIT RFC 5966 foi substituído pelo RFC 7766

— Alnitak
fonte

RE: prática operacional, alguém que odeia o DNSSEC poderia simplesmente desativar o TCP e colocá-lo no firewall por uma boa medida. Sem surpresa, há consequências. Nenhuma quantidade de suporte para EDNS0 em dois pontos de extremidade pode forçar os dispositivos entre eles a não interferir de alguma forma. (fragmentação, sinalização falsa por firewalls antigos etc.) Se você tiver grandes registros DNS no servidor de autenticação (TXT inchado), o TCP será necessário se você não desejar excluir um segmento do seu público. Da mesma forma, desabilitá-lo em um servidor recursivo o isola das respostas DNS de que seu cluster de email pode precisar lidar com spam.

— Andrew B

3

ele deve suportar TCP e UDP - o TCP é para tamanhos de respostas> 512 bytes (o que incluiria transferências de zona) (de acordo com as informações que li, de qualquer maneira. Normalmente, habilito o TCP e o UDP para os NS's que corro ...)

— Mark Regensberg
fonte

-2

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

http://cr.yp.to/djbdns/tcp.html#why (2003-01-16)

Quando as consultas TCP são enviadas?

Se você estiver em uma das seguintes situações, precisará configurar o servidor DNS para responder a consultas TCP:

Você deseja publicar conjuntos de registros maiores que 512 bytes. (Isso quase sempre é um erro.)

Você deseja permitir transferências de zona de saída, por exemplo, para um servidor de terceiros.

Um servidor pai se recusa a delegar um nome para você até você configurar o serviço TCP.

Se você não estiver em nenhuma dessas situações, não precisará fornecer o serviço TCP e não deverá configurá-lo. O DNS sobre TCP é muito mais lento que o DNS sobre UDP e é inerentemente muito mais vulnerável a ataques de negação de serviço. (Isso também se aplica ao BIND.)

Observe que ele omite uma menção explícita ao DNSSEC; o motivo é que, de acordo com a DJB, o DNSSEC se enquadra na categoria "sempre um erro". Consulte https://cr.yp.to/djbdns/forgery.html para obter mais detalhes. O DJB possui um padrão alternativo, chamado DNSCurve - http://dnscurve.org/ - que já foi adotado independentemente por alguns provedores (como o OpenDNS). De interesse: /security/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption .

Observe que, se a documentação acima na configuração do DJBDNS for uma indicação de seus recursos, parece que ele suporta apenas o AXFR para TCP. Como muitos provedores ainda usam o DJBDNS, é improvável que eles ofereçam suporte ao DNS sobre TCP sem esforços extras.

PS Observe que, de fato, o DJB pratica o que ele prega. Seus próprios servidores, (1), executam DNSCurve, (2), não respondem adequadamente ao TCP. Somente o +notcpseria bem-sucedido (que é o 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 +tcpfalharia (aparentemente com uma mensagem de erro diferente, dependendo de qual servidor dele é 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

— cnst
fonte

2

Seu ato de fã do DJB está ficando cada vez mais desgastante. A comunidade DNS escolheu o DNSSEC, e grande parte da literatura sobre o DNSCurve confunde completamente os requisitos ortogonais de autenticidade dos dados e criptografia dos dados . IMNSHO, a maior parte da sua resposta não contribui em nada para esta pergunta.

— Alnitak

@Alnitak, sua insistência em que o TCP é necessário para o DNS não o torna um requisito real para o DNS. Claramente, muitas pessoas correm sem o TCP e não enfrentam QUALQUER problema com a disponibilidade de seus próprios sites. No entanto, você continua promovendo desinformação e FUD.

— CNST

2

Esse documento é realmente de 2003? Como você pode afirmar com franqueza que ainda é relevante em 2017?

— Michael Hampton

1

@ MichaelHampton, sim, de todo o coração e absolutamente. Algumas coisas não mudam, e o DJB pode ser um idiota, mas ele é bastante inteligente nisso. Todos os argumentos que ele apresenta são de natureza filosófica e não mudam como a tecnologia. Enquanto isso, (1), por que é tão difícil de acreditar, (2), por que está vinculado a RFCs ainda mais antigas feitas com a cara séria e sem você ser um hipócrita, (3), que contrargumentos reais você tem além de um encontro"? As pessoas continuam dizendo que seu caminho tem problemas de interoperabilidade, mas os próprios argumentos propostos (por exemplo, correspondência devolvida) ele desmascarou em 2003!

— CNST

-5

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

Com a introdução das respostas DNS assinadas, houve um requisito para afrouxar o limite de 512 bytes às respostas UPD. O EDNS0 fornece o mecanismo para respostas UDP mais longas. Falha ao permitir o DNS sobre TCP é altamente provável que interrompa uma implementação de DNS segura.

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

Há um RFC596 mais recente que agora requer TCP para uma implementação completa do DNS. Isso é destinado a implementadores. Os documentos especificamente não tratam dos operadores, mas alertam que não permitir o TCP pode resultar em vários cenários de falha. Ele detalha uma ampla variedade de falhas que podem resultar 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.

— BillThor
fonte

O DNSSEC não diminuiu o limite, o EDNS0, em 1999 (consulte a RFC 2671).

— Alnitak

Não, como explicado por Alnitak, TCP é necessária na maioria dos casos (a menos que você pode estar absolutamente certo de que você nunca terá uma resposta> 512 bytes, algo que você normalmente não sabe com antecedência)

— Bortzmeyer

Eu executei o DNS com êxito através de um firewall, permitindo apenas UDP. Exceto nas configurações patológicas, as pesquisas de endereço terão menos de 512 caracteres. Vi referências de que os caminhos DNS estão limitados a 256 caracteres. As evidências no banco de dados do meu servidor de email sugerem que os caminhos DNS do servidor raramente excedem 100 caracteres, e sites com vários nomes retornados por um registro PTR raramente retornam mais de 256 caracteres. Todas essas respostas seriam executadas no UDP. Alguém tem um caso razoável que executa perto de 512 caracteres sem DNSSEC ou uma transferência de zona.

— BillThor

Em relação ao DNSSEC, não verifiquei o RFC para tamanhos estendidos, mas as únicas referências que vi para usar tamanhos de pacotes estendidos no UDP têm o DSNSEC.

— BillThor

Um dos grandes provedores de conteúdo voltou a funcionar há alguns anos quando adicionou tantos registros A para um de seus webfarms que excedia 512 bytes. Isso causou problemas reais de interoperabilidade.

— Alnitak