Solução de problemas

Esta página fornece soluções para problemas comuns que você pode encontrar ao usar o Cloud DNS para criar zonas particulares, zonas de pesquisa inversas, zonas de encaminhamento e registros de recurso.

Zonas particulares

Nesta seção, são abordados os problemas com as zonas particulares.

Problemas de zona particular em projetos de serviço de VPC compartilhada

Para informações importantes sobre o uso de zonas particulares com redes VPC compartilhadas, consulte Zonas particulares e VPC compartilhada.

Não é possível criar uma zona particular/listar ou criar políticas

É necessário ter o papel de administrador do DNS para executar várias ações em zonas particulares, como listar as políticas do servidor do Sistema de Nome de Domínio (DNS, na sigla em inglês) ou criar uma zona desse tipo. Esse papel é concedido por meio da ferramenta Gerenciamento de identidade e acesso (IAM, na sigla em inglês).

Zonas particulares não resolvidas na mesma rede VPC

Verifique se você está realizando o teste de uma instância de VM em que a interface principal está na mesma rede que a zona particular que você criou

Uma instância de máquina virtual (VM, na sigla em inglês) envia todo o tráfego para fora da interface principal, a menos que o tráfego seja destinado a uma sub-rede anexada a uma das outras interfaces ou se a VM tiver roteamento baseado em política configurado. Verifique se a VM de teste tem a interface principal na mesma rede que a zona particular que você está testando.

Determine se sua VM está usando:

gcloud compute instances describe ${VM_NAME} \
     --zone=${GCE_ZONE} \
     --format="csv[no-heading](networkInterfaces['network'])"

Verifique se a rede está na lista de redes autorizadas para pesquisar a zona particular:

gcloud dns managed-zones describe ${PRIVATE_ZONE_NAME} \
     --format="csv(privateVisibilityConfig['networks'])"

Verifique se o nome DNS na consulta corresponde à zona

O Google Cloud usa correspondência com base no sufixo mais longo para decidir qual zona será consultada nas solicitações a um determinado nome de DNS. Verifique se o sufixo do registro que você está consultando corresponde a pelo menos uma zona particular acessível na rede VPC. Por exemplo, o Google Cloud procura primeiro por myapp.dev.gcp.example.lan em uma zona que exibe dev.gcp.example.lan, se acessível, antes de procurar em uma zona que exibe gcp.example.lan, se acessível.

A saída do comando a seguir mostra o sufixo DNS de uma determinada zona particular:

gcloud dns managed-zones describe ${PRIVATE_ZONE_NAME} \
--format="csv[no-heading](dnsName)"

Consultar o nome de DNS usando o servidor de metadados

Use dig para enviar a consulta de nome de DNS diretamente ao servidor de metadados do Google Cloud, 169.254.169.254:

dig ${DNS_NAME} @169.254.169.254

Use dig para consultar o servidor de nomes padrão da VM:

dig ${DNS_NAME}

Se a saída dos dois comandos dig produzir respostas diferentes, verifique a seção ;; SERVER: do segundo comando. O servidor que responde precisa ser o de metadados: 169.254.169.254. Caso não seja, isso significa que você configurou o sistema operacional convidado para usar um servidor de nomes de DNS personalizado, em vez do servidor de metadados padrão do Google Cloud. As zonas particulares do Cloud DNS exigem que você use o servidor de metadados na resolução de nomes. Os ambientes convidados do Linux e do Windows (em inglês) fazem isso para você. Se você importou a imagem que está usando para uma VM, verifique se o ambiente convidado apropriado foi instalado.

Zonas particulares não resolvidas por meio do Cloud VPN ou Cloud Interconnect

Primeiro, verifique se você consegue consultar e resolver o nome de DNS em uma rede VPC autorizada.

Verifique a conectividade por meio do Cloud VPN ou Cloud Interconnect

Garanta que a conectividade de um sistema local com rede VPC esteja funcionando. Especificamente, o tráfego TCP e UDP na porta 53 precisa ser capaz de sair da rede local e ser entregue à rede VPC. Verifique a configuração dos firewalls locais para garantir que esse tráfego de saída seja permitido.

É possível usar qualquer protocolo, como o ping (ICMP), para testar a conectividade do ambiente local com uma VM de exemplo na rede VPC. As solicitações do Cloud DNS não são enviadas para as VMs do Google Cloud, mas ao testar a conectividade com uma VM de exemplo, você conseguirá verificar se ela está funcionando por meio de um túnel do Cloud VPN ou da conexão do Cloud Interconnect. Configure uma regra de firewall de permissão de entrada apropriada para a VM de exemplo do Google Cloud, porque a regra de negação de entrada implícita bloqueia todo o tráfego de entrada.

Garanta que o encaminhamento de entrada esteja ativado na rede VPC autorizada

O encaminhamento de entrada precisa estar ativado em cada rede VPC autorizada a consultar a zona particular do Cloud DNS. Use o comando a seguir para listar todas as políticas:

gcloud dns policies list

Identifique a rede na tabela de saída e verifique o campo Encaminhamento para ver se ele está ativado.

Verificar se a rede autorizada é VPC

O encaminhamento de DNS requer sub-redes, que estão disponíveis apenas para redes VPC, e não para redes legadas.

gcloud compute networks list \
     --format="csv[no-heading](name, SUBNET_MODE)"

As redes legadas são identificadas na saída como LEGACY.

Verifique se há um endereço de encaminhamento de DNS válido reservado na rede

O comando a seguir mostra todos os endereços IP de encaminhamento de DNS reservados no projeto.

gcloud compute addresses list \
     --filter="purpose=DNS_RESOLVER" \
     --format='csv[no-heading](address, subnetwork)'

É possível adicionar uma cláusula AND ao filtro para limitar a saída apenas à sub-rede relevante.

Exemplo:

--filter="name ~ ^dns-forwarding AND subnetwork ${subnetwork-name}"

Se um endereço IP não for exibido na rede/região esperada, abra um tíquete com o Suporte do Google Cloud.

Execute o comando dig que aponta a consulta no endereço encontrado no comando anterior. Para isso, use uma VM na mesma rede. Esse teste verifica se o encaminhamento de entrada está funcionando e se o problema está em outro lugar.

dig ${DNS_NAME} @10.150.0.1 # address returned by previous command

Repita o mesmo comando dig, mas a partir de um host local na VPN.

O registro CNAME definido em uma zona particular não está funcionando

Registros CNAME que se referem a outros registros na mesma zona particular são aceitos. Já os registros CNAME que apontam para nomes de domínio definidos em outras zonas particulares, na Internet ou em zonas internas não são aceitos.

Zonas de pesquisa inversa

Nesta seção, você encontra dicas de solução de problemas com zonas de pesquisa inversa. Alguns problemas de zona particular também se aplicam a zonas de pesquisa inversa. Para ver mais dicas, consulte a seção de solução de problemas em Zonas particulares.

VM com endereço não RFC 1918 não resolvida

Reconcilie sua VM com um endereço não RFC 1918

Se você criou uma VM durante a versão Alfa não RFC 1918, antes do Cloud DNS oferecer compatibilidade, talvez a VM não seja resolvida corretamente. Para resolver este problema, pause e reinicie as VMs.

Zonas de encaminhamento

Nesta seção, você encontra dicas de solução de problemas com zonas de encaminhamento. Alguns problemas da zona particular também se aplicam a zonas de encaminhamento. Para ver mais dicas, consulte a seção de solução de problemas em Zonas particulares.

As zonas de encaminhamento (de saída) não estão funcionando

Primeiro, verifique se você consegue consultar e resolver o nome de DNS em uma rede VPC autorizada.

O encaminhamento de consultas de VMs em uma rede VPC consumidora para produtora não está funcionando

Se você estiver usando peering de DNS e quiser encaminhar consultas de VMs em uma rede VPC consumidora para produtora e, em seguida, para um ou mais servidores de nomes no local, garanta que a rede VPC produtora tenha uma VM ou um túnel de VPN na mesma região da sub-rede usada pelas VMs do cliente.

Por exemplo, suponha que a VPC1 use uma zona de peering que envia consultas para example.com. a VPC2. Suponha também que a VPC2 tenha uma zona de encaminhamento particular para example.com. que encaminha as consultas para um servidor de nomes local usando um túnel do Cloud VPN ou o Cloud Interconnect. Para que uma VM localizada em us-east1 na VPC1 consiga consultar example.com., a VPC2 também precisa ter uma VM ou um túnel de VPN em us-east1.

Verifique a conectividade por meio do Cloud VPN ou Cloud Interconnect

É possível usar qualquer protocolo, como o ping (ICMP), para testar a conectividade do ambiente local com uma VM de exemplo na rede VPC. Também é preciso consultar o servidor de nomes local diretamente de uma VM de amostra do Google Cloud usando uma ferramenta como dig:

dig ${DNS_NAME} @192.168.x.x # address of the onprem DNS server

Verifique as regras de firewall na rede VPC

A regra de firewall implícita de permissão de saída de tráfego permite conexões de saída e respostas estabelecidas de VMs na rede VPC, a menos que você tenha criado regras personalizadas para negar a saída. Nesse caso, é necessário criar regras de permissão com prioridade mais alta que autorizem a saída para pelo menos os servidores de nomes locais.

Verificar o firewall local

Verifique se o firewall local está configurado para permitir tráfego de entrada e saída em 35.199.192.0/19.

Confira os registros no firewall local e procure as solicitações de DNS de 35.199.192.0/19. Para usar uma expressão regex na pesquisa, use o seguinte:

"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"

Verifique o servidor de nomes local

Verifique se você não tem nenhuma ACL configurada no servidor de nomes local que pode bloquear as consultas de 35.199.192.0/19.

Confira o servidor de nomes local para ver se ele está recebendo pacotes de 35.199.192.0/19. Se você tiver acesso ao shell, poderá usar uma ferramenta como tcpdump para procurar pacotes de entrada e de saída em 35.199.192.0/19:

sudo tcpdump port 53 and tcp -vv

Verificar rotas de retorno

Sua rede local precisa ter uma rota para o destino 35.199.192.0/19 com o próximo salto sendo um túnel VPN para a mesma rede VPC que enviou a solicitação DNS. Este comportamento é descrito em Como criar zonas de encaminhamento.

Se você usar vários túneis VPN para conectar a mesma rede VPC à rede local, a resposta não precisará ser entregue usando o mesmo túnel que a enviou. No entanto, a resposta precisa ser entregue usando um túnel VPN com o próximo salto na mesma rede VPC em que a solicitação foi originada.

Se você conectou mais de uma rede VPC à rede local, garanta que as respostas de DNS não sejam enviadas para a rede errada. O Google Cloud descarta as respostas de DNS enviadas para a rede VPC incorreta.

O registro CNAME definido em uma zona particular não está funcionando

O Cloud DNS não é compatível com a resolução recursiva de endereços IP usando um CNAME que aponta para um registro A em outra zona particular gerenciada (busca de CNAME). Por exemplo, suponha que você tenha duas zonas particulares gerenciadas, zone-a.private e zone-b.private, e crie registros como estes:

  • CNAME cname.zone-a.private apontando para target.zone-b.private
  • Registro A target.zone-b.private apontando para 192.168.1.9

O Cloud DNS não resolve cname.zone-a.private como 192.168.1.9 porque os dois registros não estão na mesma zona (zone-a.private e zone-b.private são diferentes).

O Cloud DNS pesquisa CNAMEs em uma zona particular gerenciada.

Falha no encaminhamento de saída para um servidor de nomes que usa um endereço IP não RFC 1918

Por padrão, o Cloud DNS usa o roteamento padrão, que encaminha as consultas pela Internet pública quando o servidor de nomes de destino tem um endereço IP não RFC 1918. O roteamento padrão não é compatível com consultas de encaminhamento para servidores de nomes com endereços não RFC 1918 que não são acessíveis na Internet pública.

Para encaminhar consultas para um servidor de nomes que usa um endereço IP não RFC 1918 por meio da sua rede VPC, configure a zona de encaminhamento ou a política de servidor do Cloud DNS de modo a usar o roteamento privado para o servidor de nomes de destino.

Para ver uma explicação sobre as diferenças entre o roteamento padrão e o particular, consulte Destinos de encaminhamento e métodos de roteamento.

Esta limitação se aplica mesmo se houver uma rota de VPC para o servidor de nomes de destino. Quando o roteamento padrão está configurado, as rotas para endereços não RFC 1918 não afetam o comportamento do encaminhamento de saída do Cloud DNS.

Falha no encaminhamento de saída para uma placa de rede secundária

No momento, o Cloud DNS não é compatível com o encaminhamento para placas de rede (NICs, na sigla em inglês) secundárias de VMs do Compute Engine.

As consultas de encaminhamento de saída recebem erros SERVFAIL

O plano de controle do Cloud DNS usa um algoritmo para determinar a capacidade de resposta de um destino de encaminhamento. A pontuação de capacidade de resposta é baseada no número de erros SERVFAIL e na latência das respostas recebidas. Os erros SERVFAIL têm um impacto maior na pontuação que a latência. As pontuações são redefinidas a cada hora.

Se todos os destinos de uma zona tiverem pontuações baixas, o Cloud DNS não enviará consultas para eles. É possível que você veja um ou mais dos sintomas a seguir:

  • Usar o encaminhamento do Cloud DNS resulta em um erro SERVFAIL rápido (cerca de 2 ms).
  • Nos registros do Cloud Logging para as consultas, os campos destinationIP, egressIP e egressError não são preenchidos.
  • Você não vê as tentativas de consulta nos seus servidores DNS.
  • As consultas que você envia diretamente aos destinos de encaminhamento (como dig @<TARGET> <QNAME>) podem ser bem-sucedidas.

Para resolver este problema, verifique se os servidores de nomes locais estão configurados corretamente. Em seguida, verifique se os servidores de nomes locais respondem às consultas em quatro segundos. Por exemplo, se os servidores de nomes locais consultarem servidores de nomes upstream por estarem configurados como resolvedores de armazenamento em cache, verifique se não há problemas com servidores de nomes upstream.

Falha no encaminhamento de entrada em uma rede VPC que usa intervalos de endereços IP não RFC 1918

O Cloud DNS não aceitará o encaminhamento de entrada se a rede VPC estiver usando um intervalo de endereços IP não RFC 1918.

Registros de recurso

Nesta seção, você encontra dicas de solução de problemas para registros de recurso.

Dados inesperados ao consultar conjuntos de registros de recurso presentes na zona

Há vários motivos para você receber dados inesperados ao consultar conjuntos de registros de recursos presentes em uma zona gerenciada do Cloud DNS:

  1. Os conjuntos de registros de recurso criados com a sintaxe @ especificada em RFC 1035 não são compatíveis. O Cloud DNS interpreta de forma literal o símbolo @ nesses conjuntos de registros de recurso. Portanto, na zona example.com., um conjunto de registros criado para o QNAME @ é interpretado como @.example.com. em vez de example.com.. Para resolver esse problema, crie conjuntos de registros sem o símbolo @. Todos os nomes são relativos ao apex da zona.

  2. Como todos os outros, os registros CNAME de caractere curinga estão sujeitos às regras de existência descritas na RFC 4592 (em inglês): por exemplo, suponha que você definiu os conjuntos de registros a seguir na zona example.com.:

    *.images.example.com. IN CNAME _static.example.com.

    srv1.images.example.com. IN A 192.0.2.91

    _static.example.com. IN A 192.0.2.92

    Uma consulta para public.srv1.images.example.com. retorna NOERROR com uma seção de resposta vazia. A existência de um registro entre o CNAME e o QNAME impede que o CNAME seja retornado, mas não há registro que corresponda exatamente ao QNAME. Sendo assim, o Cloud DNS retornará uma resposta vazia. Este é o comportamento de DNS padrão.

Conjuntos de registros de recurso do Cloud DNS retornados em ordem aleatória

De acordo com as práticas do setor de DNS, agora os servidores de nomes do Cloud DNS definem a ordem dos conjuntos de registros de recurso em ordem aleatória e ignoram a ordem determinada pelo servidor autoritativo. Este é um comportamento de DNS normal e se aplica a zonas públicas e particulares do Cloud DNS.

A seguir