Como os tempos limite do DNS devem funcionar?

Recentemente, tive um problema em que um serviço remoto solicitando o endereço IP do meu servidor (com um provedor DNS hospedado) estava respondendo com:

DNS problem: SERVFAIL looking up A for mysql.xavamedia.nl

(Atualização: o serviço remoto mencionado aqui é Let's Encrypt; arquivei um bug no rastreador de problemas, o que me levou a esse caminho.)

Nos testes na minha rede local, pude ver que às vezes recebo uma resposta DNS vazia do servidor DNS hospedado. Aparentemente, isso é intermitente, porque acontece apenas quando os registros DNS não estão no cache e é apenas um problema quando o servidor DNS está realmente ocupado.

Aqui está uma descrição do Wireshark de uma mensagem de resposta vazia:

Obviamente, como a maioria das consultas e respostas DNS são enviadas pelo UDP, um resolvedor local apenas espera um pouco pela resposta e desiste. O que agora me pergunto é: existem diretrizes para os tempos de resposta do DNS? Meu hoster DNS meio que deu de ombros e disse que meu resolvedor local enviou a resposta vazia muito cedo. Eu nunca tive esse problema antes, mas estou surpreso com o modo de falha - uma resposta DNS vazia sem um código de erro.

Alguém conhece algumas diretrizes sobre como isso deve funcionar e quando / como posso provar que minha hospedagem DNS está fazendo algo errado?

domain-name-system dns-hosting

— djc
fonte

Você pode atualizar a pergunta para fornecer mais informações sobre a resposta vazia? Isso pode significar várias coisas, dependendo dos sinalizadores definidos e da aparência da seção de autoridade. Nós precisaríamos ver a saída de dig/ nslookupou uma dissecção do Wireshark. ( tcpdumpnão será bom o suficiente) Se você estiver usando nslookup, execute set debugprimeiro.

— Andrew B

Eu tenho um pcap, mas não sei como posso mostrá-lo aqui?

— DJC

Abra-o no Wireshark, clique no pacote e expanda as informações do protocolo DNS. Expanda também as subcategorias e publique uma captura de tela na sua pergunta usando o botão Inserir imagem. Você pode cortar a captura de tela para o material do protocolo DNS.

— Andrew B

Respostas:

A resposta vazia que você está vendo é um estado sintético conhecido como NODATA. NODATAe NXDOMAINambos indicam que o nome não existe, mas NXDOMAINse aplica a todos os nomes abaixo do registro indicado. NODATArecomenda que esse nome esteja associado a registros de um tipo não solicitado ou que haja outros registros abaixo do que você está solicitando. (ie example.test.xavamedia.nl.)

Sua aceitação NODATAe NXDOMAINefetivamente é a mesma neste contexto: o registro do nome e do tipo solicitado não existia. Um servidor de nomes autoritativo foi encontrado para o domínio solicitado e ele respondeu afirmando que não existia um registro desse nome e tipo. Este não é um erro de comunicação. O servidor autoritário disse que não tinha os dados. É mais provável que o servidor com o qual você estava falando já tenha processado essa solicitação e que tenha sido negativo em cache a ausência desse registro nas últimas quatro horas. (14400 segundos é o intervalo de cache negativo definido pelo registro SOA para xavamedia.nl.)

Nenhum delesNXDOMAIN ou NODATA por si só resultará em um tempo limite quando encontrado nesta instância, mas sua biblioteca de resolvedores provavelmente passará daqui para anexar o sufixo de pesquisa DNS, que por sua vez pode desencadear um tempo limite para os servidores DNS autoritativos do domínio de pesquisa.

Note-se que nada disso explica por que você encontrou uma SERVFAILresposta ao olhar para cima mysql.xavamedia.nl.. Isso aponta para um problema com o servidor recursivo que obtém a resposta dos servidores autorizados. O servidor autoritativo respondeu com SERVFAIL, o servidor recursivo não pôde acessar nenhum dos servidores autoritativos ou o servidor recursivo determinou que os dados retornados eram inválidos. Nada disso pode ser comprovado com as informações que você forneceu.

— Andrew B
fonte

Obrigado pela sua resposta detalhada! Algumas coisas ainda não estão claras: se a resposta NODATA for iniciada pelo servidor autoritário de alguma forma, minha hospedagem DNS terá um problema, porque esses domínios já existem há muito tempo (em virtude de um registro curinga A). Então, minha outra pergunta é: como posso provar se o servidor autoritário fez algo errado?

— DJC

A NODATAcaptura de pacotes é a prova. A pergunta pertinente é "por que um servidor autoritário respondeu e disse que esse registro não existia?" . Infelizmente, é um problema difícil de pressionar, a menos que você possa provar isso com pesquisas diretas nos servidores autoritativos (removendo a capacidade de encolher e culpar os operadores dos servidores recursivos), lembrando que apenas um dos três pode estar se comportando de vez em quando.

— Andrew B

NODATAsignifica que o nome não existe, mas não tem um registro do tipo solicitado. Por exemplo, você pede Aregistro, mas ele só possui MXregistro. Também pode acontecer se o nome for de um nó intermediário na hierarquia DNS e não possuir registros próprios.

— Barmar

@ Barmar Sim, o que está sendo dito aqui é que o servidor autoritário está relatando uma ausência desse nome de registro + par de tipos, e o djc está expressando confusão sobre isso devido a um registro curinga que está presente há algum tempo.

— Andrew B

Meu comentário é direcionado ao seu primeiro ponto "NODATA e NXDOMAIN indicam que o nome não existe". NXDOMAINsignifica que o nome não existe, NODATAsignifica que o nome existe, mas o tipo de registro solicitado não existe.

— 226 Barmar

Não conheço diretrizes específicas, exceto as definidas na seção "6.1.3.3 Uso eficiente de recursos" da RFC 1123 http://tools.ietf.org/rfcmarkup?rfc=1123#page-77

Um valor de tempo limite de "não menos que 5 segundos" é especificado. O RFC também afirma que falhas temporárias devem ser armazenadas em cache. Isso evita uma quantidade excessiva de solicitações de DNS se os clientes violarem a seção 2.2 da RFC. Essa seção afirma que os clientes devem esperar um período "razoável" de tempo entre tentativas em caso de falhas leves.

Há também um encadeamento Stackoverflow sobre esse tópico, mas ele não contém muito mais informações, exceto algumas observações do mundo real. /programming/3036054/ideal-timeout-period-for-dns-lookup

É tudo o que posso dizer sobre esse tópico. Se alguém tiver mais a acrescentar, eu também estaria interessado.

— Janek Bevendorff
fonte