Quando o DNS público do Google não consegue resolver um domínio, isso ocorre geralmente devido a um problema com esse domínio ou com os servidores de nomes autoritativos dele. As etapas a seguir ajudam a determinar a causa do problema para que os administradores de domínio possam resolvê-lo por conta própria.
Antes de iniciar estas etapas, verifique o domínio em dns.google conforme descrito na página de solução de problemas gerais, que pode direcionar você a uma etapa de diagnóstico específica abaixo. Caso contrário, tente todas as etapas a seguir até encontrar a causa.
Etapa 1: verificar problemas de validação das DNSSEC
Se as buscas na Web do dns.google para o domínio mostrarem "Status": 2 (SERVFAIL) e as
consultas sem DNSSEC forem concluídas, pode haver um problema de DNSSEC
com servidores de nomes do domínio ou o registro de domínio de nível superior (TLD),
que publica registros DS para validação de domínios registrados pelo DNSSEC.
- Alterações no registrador ou no serviço DNS
Os problemas de DNSSEC podem ocorrer depois que um domínio muda de um registrador ou serviço DNS compatível com as DNSSEC para um que não é. Se o serviço anterior deixar registros
DSdesatualizados no registro de TLD e o novo serviço não criar novos registrosDNSKEYcom registrosDScorrespondentes no registro de TLD, validar resolvedores, como o DNS público do Google, não resolve o domínio.Caso isso aconteça, peça para seu registrador de domínio remover registros DS desatualizados do registro TLD.
- As respostas das DNSSEC são muito grandes
Outra causa de problemas de DNSSEC podem ser respostas muito grandes de DNSSEC em um pacote de IP, criando respostas fragmentadas que podem ser descartadas. Se a DNSViz mostrar erros "nenhuma resposta recebida até que o tamanho do payload UDP foi diminuído", as falhas de DNSSEC podem ser causadas por respostas muito grandes. Os tamanhos das respostas podem ser reduzidos por uma ou mais das seguintes ações:
- Configurar "respostas mínimas" para servidores de nomes autoritativos
- Reduzir o número de registros
DNSKEYativos para dois ou três - Usar registros
DNSKEYde 1.280 ou 2.048 bits (RFC 6781, StackExchange) - Mudar de assinaturas RSA para assinaturas menores de ECDSA (RFC 8624)
Confira também se há outros problemas de DNSSEC relatados pelas ferramentas na etapa 2. Exemplos incluem registros de negação de existência da NSEC ou NSEC3 que comprovam a ausência de subdomínios (PowerDNS com zonas armazenadas em bancos de dados externos) ou assinaturas RRSIG expiradas (com processos de assinatura configurados manualmente corrompidos).
Etapa 2: verificar os servidores de nomes autoritativos
Se o DNS público do Google (ou qualquer resolvedor aberto) tiver um problema para resolver um domínio, o DNSViz mostrará problemas de servidor de nome e domínio que o causam. Acesse a página da Web do DNSViz e digite o nome de domínio problemático. Se o DNSViz não tiver dados históricos ou tiver apenas dados com mais de um dia, como o mostrado na página aqui, clique no botão Analisar grande para revelar um botão de "Analisar" menor abaixo (se ainda não estiver visível) e clique nele. Quando a análise estiver concluída, clique em "Continuar" para exibir os resultados. Clique nos erros vermelhos e nos avisos amarelos na barra lateral esquerda para revelar detalhes ou mantenha o ponteiro sobre objetos no diagrama para exibir essas informações em pop-up no contexto.
Se os diagnósticos anteriores indicarem possíveis problemas de DNSSEC com o domínio,
acesse a página da Web do DNSSEC Analyzer
e insira o nome de domínio. Se esse analisador relatar erros ou avisos de DNSSEC,
mantenha o ponteiro sobre os ícones vermelhos
A página da Web intoDNS informa problemas não DNSSEC com o domínio inserido na página principal e também mostra sugestões para corrigi-los.
Os administradores do domínio precisam corrigir a maioria dos erros que essas ferramentas reportam, já que podem causar problemas não apenas no DNS público do Google, mas também em outros resolvedores.
Etapa 3: verificar se há problemas de delegação
O DNS público do Google é um resolvedor "centrado em pais", que usa apenas os servidores de nomes retornados em referências do domínio pai. Se os nomes dos servidores de nomes e os endereços IP no TLD estiverem desatualizados ou incorretos, isso pode causar problemas de delegação.
Se o DNSViz ou o intoDNS informarem avisos sobre inconsistências entre os servidores de nomes delegados no TLD e os que estão presentes no próprio domínio filho, talvez eles precisem ser resolvidos antes que o DNS público do Google resolva o domínio. Se essas ferramentas informarem que o domínio registrado não existe (NXDOMAIN), verifique se o domínio não expirou ou está em espera de registro por algum motivo.
Problemas de delegação também podem ser causados por uma falha na resolução dos nomes dos
servidores de nomes de um domínio. Verifique os registros A e AAAA dos servidores de nomes
em dns.google para ver se há problemas com os domínios dos servidores.
Etapa 4: conferir se há respostas grandes
O DNS depende do UDP para transportar a maior parte do tráfego. Os datagramas grandes do UDP estão sujeitos à fragmentação, e o UDP fragmentado tem problemas de confiabilidade na entrega. Esse foi o foco do DNS Flag Day 2020, um esforço para melhorar a confiabilidade do DNS globalmente. O DNS público do Google participou desse esforço e limita o tamanho das respostas UDP aceitas por UDP. Tente uma consulta como as mostradas abaixo com seu próprio prompt de comando ou um Google Cloud Shell:
$ dig +short example.com NS ns1.example.com ns2.example.com $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY ...
Essas consultas para vários tipos de registro especificam:
+dnssec- Ative DNSSEC, especialmente retornando os registros necessários para validação quando elas estiverem disponíveis. Isso pode aumentar significativamente o tamanho do resultado. Isso emula o comportamento do DNS público do Google.
+bufsize=1400- Limite o tamanho permitido do buffer UDP. Isso emula o comportamento do DNS público do Google, a partir do esforço do DNS Flag Day 2020.
+timeout=1- Defina o tempo limite como um segundo. Isso emula o comportamento do DNS público do Google.
@ns1.example.com- Qual servidor autoritativo consultar: mantenha o sinal
@, mas substitua pelo servidor autoritativo do seu domínio, conforme mostrado no primeiro comando.
Observe a saída. Você vê uma linha como esta?
;; Truncated, retrying in TCP mode.- Isso indica que a resposta era maior que o tamanho solicitado de buffer do UDP, por isso, ela foi truncada e, em resposta, o cliente mudou para o TCP. Seus servidores autoritativos precisam ser capazes de processar o tráfego DNS na porta TCP 53. Consulte a RFC 7766, que estipula que as "implementações PRECISAM oferecer suporte ao transporte UDP e TCP".
;; MSG SIZE rcvd: 2198- Para números acima de 1.400? Isso indica novamente uma grande resposta.
;; Query time: 727 msec- Para números acima de 500? Respostas lentas (especialmente aquelas próximas ou acima de 1 segundo) podem ser descartadas pelo DNS público do Google. Isso ocorre principalmente se algum tempo for gasto em uma tentativa de UDP seguida por uma tentativa de TCP. A localização geográfica do servidor e do cliente pode afetar muito a latência.
;; connection timed out; no servers could be reached- Especialmente quando acontece apenas em algumas consultas, isso indica um problema em que o servidor não consegue responder a consultas DNS em tempo hábil.
Tente as seguintes variações de consulta:
- adicionar um parâmetro
+tcp. - Isso força
diga usar imediatamente o TCP. Verifique se seu servidor autoritativo lida com consultas TCP diretamente dessa maneira. - remover o parâmetro
+bufsize=1400. - Isso restaura o comportamento padrão do
dig(um bufsize de 4096). Se as consultas falham com essa configuração, mas funcionam sem ela, essa é uma dica de que seu servidor não processa bem o failover de TCP. Confiar no UDP para responder a respostas grandes só funciona às vezes. A melhor opção é oferecer suporte ao transporte TCP para DNS. - repetir em cada servidor de nomes.
- O exemplo acima tem dois servidores de nomes autoritativos (
ns1ens2). Alguns problemas são causados por servidores diferentes que retornam respostas distintas. Verifique se todos eles respondem de maneira consistente repetindo as mesmas consultas em todos os servidores autoritativos.
Se as respostas de todas as consultas forem pequenas (1.400 bytes ou menos), rápidas (preferencialmente 500 milissegundos ou mais rápidas) e confiáveis (funcionam de forma consistente por TCP e UDP), o tamanho da resposta não será sua preocupação. Leia as outras seções de solução de problemas. Mesmo que suas respostas sejam rápidas, as consultas de localizações geográficas distantes podem ser mais lentas.
Se alguma dessas verificações falhar (grande? lenta? não confiável?), a melhor maneira de agir é A) garantir que seu servidor responda com truncamento UDP, quando a resposta exceder o tamanho do buffer UDP solicitado e B) garantir que ele pode lidar com a nova tentativa de consulta TCP. Várias ferramentas podem ajudar a diagnosticar problemas de confiabilidade do DNS:
- DNSViz
- Depurador DNSSEC
- Testador de conformidade com EDNS
- Verificador DNS: desmarque a caixa "CD" (desativar a verificação de DNSSEC).
Se algum erro ou aviso for revelado por essas ferramentas, resolva o problema. Leia também todas as outras instruções para solução de problemas neste site.
Etapa 5: verificar se outros resolvedores públicos resolvem o domínio
Se você não encontrou nenhuma causa do problema depois de seguir as etapas acima,
execute os seguintes comandos em um prompt de comando, substituindo example.test. pelo
domínio em questão (e preservando os pontos à direita):
Windows
nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.
macOS ou Linux
dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'
Esses comandos usam os resolvedores de DNS do OpenDNS, Quad9 e Cloudflare 1.1.1.1. Se você receber falhas de resolução de dois desses casos, bem como do DNS público do Google, o problema provavelmente é com o domínio ou os servidores de nomes dele.
Se você receber um resultado de mais de um resolvedor público, pode haver um problema com o DNS público do Google. Se nenhum problema semelhante tiver sido relatado para o domínio (ou o TLD dele) no Issue Tracker, você deve informar o problema incluindo a saída do comando e o texto da página de diagnóstico ou as capturas de tela no seu relatório.