Resolver problemas do Cloud DNS

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

Zonas públicas

Nesta seção, abordamos os problemas com as zonas públicas.

Não é possível criar uma zona pública

Se você receber um erro attempted action failed, isso significa que a API Cloud DNS não está ativada no seu projeto.

Para ativar a API Cloud DNS, siga estas etapas:

  1. No console do Google Cloud, acesse a página Biblioteca de APIs.

    Acessar a Biblioteca de APIs

  2. Em Selecionar um projeto recente, selecione o projeto do Google Cloud em que você quer ativar a API.

  3. Na página Biblioteca de APIs, use a caixa Pesquisar APIs e serviços para pesquisar Cloud DNS API. Será exibida uma página descrevendo a API.

  4. Clique em Ativar.

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 de políticas configurados. 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 consultar a zona particular:

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

Verificar se o nome DNS na consulta corresponde à zona

O Google Cloud resolve um registro de acordo com a ordem de resolução de nome, usando a zona com o sufixo mais longo para decidir qual zona será consultada em busca de 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 primeiro procura 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

O Cloud DNS busca apenas registros CNAME, conforme descrito em Busca de CNAME.

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 esse problema, reinicie as VMs.

Zonas de encaminhamento

Nesta seção, você encontra dicas de solução de problemas para 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 o peering de DNS e quiser encaminhar consultas de VMs em uma rede VPC consumidora para uma rede VPC produtora e, em seguida, para um ou mais servidores de nomes locais, verifique se um dos seguintes pré-requisitos é atendido:

  • A rede VPC do produtor tem o modo de roteamento dinâmico definido como GLOBAL.

  • A VM na rede VPC do consumidor está na mesma região do túnel do VPN ou do Cloud Interconnect na VPC do produtor

  • (Somente VPN clássica) A rede VPC do produtor tem uma rota estática configurada para enviar tráfego destinado aos servidores de nomes no local pelo túnel da VPN clássica. A rede VPC produtora também precisa ter uma VM ou um túnel VPN na mesma região da sub-rede usada pelas VMs clientes.

    • 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 VPN clássica.

      Para que uma VM localizada em us-east1 na VPC1 consiga consultar example.com., a VPC2 precisa ter uma VM localizada em us-east1. Uma rota estática também precisa ser configurada para abranger os intervalos CIDR dos servidores de nomes locais, com o próximo salto configurado como o túnel de VPN clássica.

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 de permissão de saída implícita 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 ou conexão Interconnect 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 à 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. Para uma solução recomendada, consulte nosso guia de Práticas recomendadas.

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

Verifique se você configurou corretamente seu controlador de interface de rede (NIC) secundário.

Para instruções sobre como configurar NICs adicionais, consulte Como criar instâncias de máquina virtual com várias interfaces de rede.

As consultas de encaminhamento de saída recebem erros SERVFAIL

Se o Cloud DNS receber um erro de todos os servidores de nomes de destino ou não receber uma resposta de nenhum dos servidores de nomes de destino, ele retornará um erro SERVFAIL.

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 do intervalo de endereços do Cloud DNS descrito em Abrir o Google Cloud e os firewalls locais para permitir o tráfego DNS em até 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.

Além disso, se o destino do encaminhamento for um sistema local, saiba que as rotas configuradas para esse caminho podem ser rotas dinâmicas personalizadas ou rotas estáticas personalizadas, com a importante exceção de rotas estáticas personalizadas com as tags de rede que não são válidas para encaminhar consultas DNS. Certifique-se de que a rota usada para acessar o servidor de nomes local não especifique uma tag de rede.

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. Esse é um comportamento de DNS normal e se aplica a zonas públicas e privadas do Cloud DNS.

Tipo de recurso zonal incompatível

Quando você insere a sinalização --location em um comando gcloud ou solicitação de API de um recurso que segmenta uma zona diferente do Cloud DNS, a solicitação é rejeitada. Por exemplo, se você enviar uma solicitação de recurso somente por zona a um servidor global ou uma solicitação de recurso somente global para um servidor zonal, o servidor rejeitará a solicitação e fornecerá um erro _UNSUPPORTED_ZONAL_RESOURCETYPE.

Para ver uma lista de recursos e funcionalidades compatíveis com o Cloud DNS por zona, consulte Compatibilidade com o Cloud DNS por zona.

A seguir