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 particulares, 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

Primeiro, verifique se você está realizando o teste na mesma rede.

Verifique se a interface principal da instância de VM está na mesma rede que a zona particular que você criou.

Uma instância de máquina virtual (VM) envia todo o tráfego da interface principal, a menos que ele seja destinado a uma sub-rede anexada a uma das outras interfaces ou se a VM tiver o roteamento de 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 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

OCloud de Confiance resolve um registro de acordo com a ordem de resolução de nomes, usando a zona com o sufixo mais longo para decidir qual zona consultar para 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 sua rede VPC. Por exemplo, Cloud de Confianceprimeiro procura myapp.dev.gcp.example.lan em uma zona que atende a dev.gcp.example.lan, se acessível, antes de procurar em uma zona que atende a 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 DNS usando o servidor de metadados

Use dig para enviar a consulta de nome DNS diretamente ao servidor de metadados do Cloud de Confiance, 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. Se não for, você configurou o sistema operacional convidado para usar um servidor de nomes DNS personalizado em vez do servidor de metadadosCloud de Confiance padrão. As zonas particulares do Cloud DNS exigem que você use o servidor de metadados na resolução de nomes. Os ambientes de convidado do Linux e do Windows fazem isso por 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. Embora as solicitações do Cloud DNS não sejam enviadas para VMs do Cloud de Confiance , testar a conectividade com uma VM de amostra permite verificar a conectividade por um túnel do Cloud VPN ou uma conexão do Cloud Interconnect. Configure uma regra de firewall de permissão de entrada adequada para a VM de amostraCloud de Confiance , porque, caso contrário, a regra de negação de entrada implícita vai bloquear 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.

Verifique se a rede autorizada é uma rede 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 você não encontrar um endereço IP na rede ou região esperada, abra um tíquete com o suporte daCloud de Confiance .

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

Se você tiver um endereço não RFC 1918, reconcilie a VM.

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 de consumidor para uma rede VPC de produtor e, em seguida, para um ou mais servidores de nomes locais, verifique se um dos seguintes pré-requisitos foi 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 que o túnel de VPN ou o Cloud Interconnect na VPC do produtor.

  • (Somente rotas estáticas ou próximos saltos personalizados) A rede VPC do produtor tem uma rota estática configurada para enviar tráfego destinado aos servidores de nomes locais pelo túnel de VPN clássica, uma VPN autogerenciada ou um gateway não BGP. A rede VPC do produtor também precisa ter 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 a um servidor de nomes local usando um túnel de VPN clássica.

      Para que uma VM localizada em us-east1 na VPC1 consiga consultar example.com., a VPC2 precisa ter uma VM 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. Você também precisa tentar consultar o servidor de nomes local diretamente de uma VM de amostra doCloud de Confiance 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 177.222.82.0/25.

Confira os registros no firewall local e procure as solicitações de DNS de 177.222.82.0/25. 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 não há nenhuma ACL configurada no servidor de nomes local que bloqueie consultas de 177.222.82.0/25.

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

sudo tcpdump port 53 and tcp -vv

Verificar rotas de retorno

Sua rede local precisa ter uma rota para o destino 177.222.82.0/25 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 à sua rede local, verifique se as respostas de DNS não são enviadas para a rede errada.O Cloud de Confiance descarta as respostas de DNS enviadas para a rede VPC errada. Para uma solução recomendada, consulte nosso guia de Práticas recomendadas.

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 Cloud de Confiance e firewalls locais para permitir o tráfego de 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. Este é um comportamento de DNS normal e se aplica a 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.

Endpoints de saída

Nesta seção, descrevemos os problemas que podem ser encontrados ao usar endpoints de saída e como resolvê-los.

As consultas DNS não estão sendo encaminhadas para os servidores de destino

Há várias causas possíveis para esse problema.

Configuração incorreta de recursos

Seu endpoint e a zona de encaminhamento ou a política do servidor precisam estar configurados corretamente. Isso inclui a associação do endpoint à rede VPC e à região corretas ou a configuração da zona de encaminhamento ou da política de servidor para usar os endpoints de saída certos.

Verifique se a sub-rede somente proxy regional está configurada corretamente e tem endereços IP suficientes disponíveis para consultas de proxy. Também é possível ativar o registro em log de consultas e verificar o campo jsonPayload.egressPath. Esse campo é definido como OUTBOUND_ENDPOINT se a consulta encaminhada estiver usando endpoints de saída. Se os registros de consulta não incluírem esse campo ou se ele não estiver definido como OUTBOUND_ENDPOINT, o tráfego será padronizado como 35.199.192.0/19.

Para verificar sua configuração, execute o comando gcloud beta dns outbound-endpoints describe:

gcloud beta dns outbound-endpoints describe ENDPOINT_NAME \
    --project=PROJECT_ID \
    --location=REGION

Substitua:

  • ENDPOINT_NAME: nome do endpoint.
  • PROJECT_ID: ID do projeto
  • REGION: região em que o endpoint está localizado.

Conectividade de rede

Verifique se há uma rota da rede VPC para os servidores DNS locais ou remotos e se as regras de firewall locais permitem o tráfego da porta TCP/UDP 53 do intervalo de IP da sub-rede somente proxy. Verifique também se há uma rota da rede local de volta para o intervalo de IP da sub-rede somente proxy.

Problema de peering ou VPC compartilhada

  • Problema da VPC compartilhada: os endpoints de saída precisam ser criados no projeto host em que a rede VPC e as sub-redes da VPC compartilhada estão localizadas. Ao associar uma zona de encaminhamento ou uma política de servidor DNS em um projeto de serviço com um endpoint de saída no projeto host, verifique se o usuário tem dns.outboundEndpoints.bindPrivateDNSZone ou dns.outboundEndpoints.bindPrivateDNSPolicy no projeto host.
  • Problema de peering: verifique se o status do peering de rede VPC está definido como Active.

Verifique também se as rotas e as regras de firewall permitem o tráfego DNS (porta UDP e TCP 53) entre o intervalo de IP da sub-rede somente de proxy regional na rede VPC do endpoint e os servidores DNS de destino.

Tempo limite das consultas DNS

As seções a seguir descrevem por que as consultas DNS podem expirar ao usar endpoints de saída.

Problema de latência de rede entre o endpoint de saída e os servidores de destino

Verifique a latência entre sua rede VPC e os servidores DNS de destino. Mover os servidores DNS de destino para mais perto do projeto doCloud de Confiance também pode ajudar.

Esgotamento da sub-rede somente proxy

Verifique a utilização do endereço IP da sub-rede somente proxy na região em que as consultas estão falhando com o Monitoring. Se a sub-rede estiver quase esgotada, migre para uma sub-rede somente proxy maior seguindo as etapas em Modificação de sub-rede.

Configuração incorreta da política de geolocalização

Verifique se a política de roteamento por geolocalização tem uma entrada para a região em que o endpoint de saída está localizado. Verifique também se o destino do FQDN na zona de encaminhamento corresponde ao nome DNS da zona da política de geolocalização.

Não é possível criar um endpoint de saída

As seções a seguir descrevem por que talvez não seja possível criar um endpoint de saída.

Problema de permissão do IAM

Verifique se a conta de usuário ou de serviço tem os papéis roles/dns.admin e roles/compute.networkAdmin (ou permissões para dns.outboundEndpoints.create, compute.networks.get, compute.subnetworks.get e compute.subnetworks.use). Para uma VPC compartilhada, os endpoints de saída precisam ser criados no projeto host (não é possível criar um endpoint de saída em um projeto de serviço).

A string de endereço IP fornecida em endpointIp não corresponde ao intervalo CIDR da sub-rede normal especificada ou está corrompida

Verifique o intervalo CIDR da sub-rede regular especificada na região de destino e confira se a string IP fornecida em endpointIp (--endpoint-ip) está dentro do intervalo CIDR principal da sub-rede. Verifique também se o endereço IP não é um endereço reservado na sub-rede (por exemplo, gateway ou transmissão).

A string de endereço IP fornecida é válida, mas já está em uso por outro recurso

Verifique no console Cloud de Confiance os endereços IP da sua rede VPC ou use o comando gcloud compute addresses list e forneça um endereço IPv4 não alocado diferente da sub-rede normal com --endpoint-ip.

O sistema não encontrou uma sub-rede regional ativa somente proxy

Verifique se existe uma sub-rede regional ativa somente proxy na rede VPC e na região especificadas. Se não houver uma, crie uma sub-rede regional somente proxy (mínimo /26) com --purpose=REGIONAL_MANAGED_PROXY e --role=ACTIVE (consulte Sub-redes somente proxy para balanceadores de carga baseados no Envoy).

Falha na exclusão de recursos

Se não for possível excluir um recurso, talvez ele esteja sendo usado por um endpoint de saída.

Tentativa de excluir um recurso que está em uso ativo

Siga as etapas descritas em Gerenciar recursos de rede associados a endpoints de saída.

A seguir