Esta página fornece soluções para problemas comuns que você pode encontrar ao usar o Cloud DNS para criar zonas públicas ou particulares, zonas de pesquisa inversas, 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:
No console do Google Cloud, acesse a página Biblioteca de APIs.
Em Selecionar um projeto recente, selecione o projeto do Google Cloud em que você quer ativar a API.
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.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 maior sufixo para decidir qual zona deve ser consultada para um determinado nome de DNS. Confirme se
se o sufixo do registro consultado corresponde a pelo menos um
zona acessível na sua rede VPC. Por exemplo, o Google Cloud
procura myapp.dev.gcp.example.lan
em uma zona que veicula
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ê usa peering de DNS e quer encaminhar consultas de VMs de uma rede VPC do consumidor para uma rede VPC do produtor, e, em seguida, para um ou mais servidores de nomes no local, confirme se um dos os seguintes pré-requisitos são atendidos:
A rede VPC do produtor tem o modo de roteamento dinâmico Defina como
GLOBAL
A VM na rede VPC do consumidor está na mesma região que a Túnel VPN ou Cloud Interconnect na VPC do produtor
(Somente VPN clássica) A rede VPC do produtor tem uma rota estática configurado para enviar tráfego destinado aos servidores de nomes no local por meio da túnel da VPN clássica. A rede VPC do produtor também precisa ter uma VM Túnel VPN na mesma região da sub-rede usada pelas VMs de 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 paraexample.com.
, que encaminha as consultas para um servidor de nomes local usando um túnel da VPN clássica.Para que uma VM localizada em
us-east1
na VPC1 consiga consultarexample.com.
, VPC2 precisa ter uma VM localizada emus-east1
. Uma rota estática também precisam ser configuradas abrangendo os intervalos CIDR dos servidores de nomes no local, com o próximo salto configurado como o túnel da 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:
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 zonaexample.com.
, um conjunto de registros criado para o QNAME@
é interpretado como@.example.com.
em vez deexample.com.
. Para resolver esse problema, crie conjuntos de registros sem o símbolo@
. Todos os nomes são relativos ao apex da zona.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.
retornaNOERROR
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.
A VM do Google Cloud mostra registros de ponteiro incorretos (PTR)
Quando uma VM é migrada durante um evento de manutenção, a lógica do registro PTR não lida com alguns casos extremos corretamente e reverte os registros PTR de DNS para o nome de domínio totalmente qualificado (FQDN, na sigla em inglês) googleusercontent.com
. Para restaurar a funcionalidade, aplique o registro PTR novamente.
Para detalhes sobre como aplicar registros PTR em uma VM, consulte Como criar um registro PTR para uma instância de VM.
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 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
- Para saber mais sobre os recursos, consulte a Visão geral do Cloud DNS.
- Para resolver erros, consulte Mensagens de erro.
- Se precisar de mais ajuda, consulte Suporte.