Esta página oferece soluções para problemas comuns que pode encontrar quando usa o Cloud DNS para criar zonas públicas, zonas privadas, zonas de pesquisa inversa, zonas de encaminhamento e registos de recursos.
Zonas públicas
Esta secção aborda problemas com zonas públicas.
Não é possível criar uma zona pública
Se receber um erro attempted action failed, significa que a API Cloud DNS não está ativada no seu projeto.
Para ativar a API Cloud DNS, siga estes passos:
Na Google Cloud consola, aceda à página Biblioteca de APIs.
Para Selecionar um projeto recente, selecione o Google Cloud projeto onde quer ativar a API.
Na página Biblioteca de APIs, use a caixa Pesquisar APIs e serviços para pesquisar
Cloud DNS API. É apresentada uma página que descreve a API.Clique em Ativar.
Zonas privadas
Esta secção aborda problemas com zonas privadas.
Problemas de zona privada em projetos de serviço de VPC partilhada
Para ver informações importantes sobre a utilização de zonas privadas com redes de VPC partilhada, consulte o artigo Zonas privadas e VPC partilhada.
Não é possível criar uma zona privada, nem listar ou criar políticas
Tem de ter a função de administrador de DNS para realizar várias ações de zona privada, como listar políticas de servidor do Sistema de Nomes de Domínio (DNS) ou criar uma zona privada. Esta função pode ser concedida através da ferramenta de gestão de identidade e de acesso (IAM).
Zonas privadas que não estão a ser resolvidas na mesma rede VPC
Primeiro, certifique-se de que está a realizar o teste a partir da mesma rede.
Verifique se a interface principal da instância de VM está na mesma rede que a zona privada que criou
Uma instância de máquina virtual (VM) envia todo o tráfego para fora da respetiva interface principal, a menos que o tráfego se destine a uma sub-rede associada a uma das outras interfaces ou se a VM tiver o encaminhamento de políticas configurado. Certifique-se de que a VM de teste tem a respetiva interface principal na mesma rede que a zona privada que está a testar.
Determine que a sua VM está a usar:
gcloud compute instances describe VM_NAME \
--zone=GCE_ZONE \
--format="csv[no-heading](networkInterfaces['network'])"
Certifique-se de que a rede está na lista de redes autorizadas a consultar a sua zona privada:
gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
--format="csv(privateVisibilityConfig['networks'])"
Verifique se o nome DNS na consulta corresponde à sua zona
Google Cloud resolve um registo de acordo com a ordem de resolução de nomes, usando a zona com o sufixo mais longo para decidir que zona consultar para um determinado nome DNS. Certifique-se de que o sufixo do registo que está a consultar corresponde a, pelo menos, uma zona privada acessível na sua rede da VPC. Por exemplo, Google Cloud
procura primeiro myapp.dev.gcp.example.lan numa zona que publica
dev.gcp.example.lan, se acessível, antes de o procurar numa zona que
publica gcp.example.lan, se acessível.
O resultado do seguinte comando mostra o sufixo DNS para uma determinada zona privada:
gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
--format="csv[no-heading](dnsName)"
Consultar o nome DNS através do servidor de metadados
Use dig para enviar a consulta de nome DNS diretamente para o Google Cloud
servidor de metadados, 169.254.169.254:
dig DNS_NAME @169.254.169.254
Use dig para consultar o servidor de nomes predefinido da VM:
dig DNS_NAME
Se a saída dos dois comandos dig produzir respostas diferentes, verifique a secção ;; SERVER: do segundo comando. O servidor de resposta tem de ser o servidor de metadados, 169.254.169.254. Se não for, significa que configurou o sistema operativo convidado para usar um servidor de nomes DNS personalizado em vez doGoogle Cloud servidor de metadados predefinido. As zonas privadas do Cloud DNS requerem que use o servidor de metadados para a resolução de nomes. Tanto o ambiente convidado do Linux como o ambiente convidado do Windows
fazem isto por si. Se importou a imagem que está a usar para uma MV,
verifique se o ambiente convidado adequado foi instalado.
Zonas privadas que não estão a ser resolvidas através do Cloud VPN ou do Cloud Interconnect
Primeiro, certifique-se de que consegue consultar e resolver o nome DNS a partir de uma rede de VPC autorizada.
Valide a conetividade através do Cloud VPN ou do Cloud Interconnect
Certifique-se de que a conetividade de um sistema no local para a sua rede VPC está operacional. Especificamente, o tráfego TCP e UDP na porta 53 tem de poder sair da sua rede no local e ser entregue na sua rede VPC. Verifique a configuração das firewalls no local para se certificar de que esse tráfego de saída é permitido.
Pode usar qualquer protocolo, como ping (ICMP), para testar a conetividade a uma VM de exemplo na sua rede VPC a partir de um local. Embora os pedidos do Cloud DNS não sejam enviados para as VMs, testar a conetividade a uma VM de exemplo permite-lhe validar a conetividade através de um túnel do Cloud VPN ou de uma ligação do Cloud Interconnect. Google Cloud Certifique-se de que configura uma regra de firewall de permissão de entrada adequada para a VM de exemplo, uma vez que a regra de negação de entrada implícita bloqueia todo o tráfego de entrada.Google Cloud
Certifique-se de que o encaminhamento de entrada está ativado para a rede de VPC autorizada
O encaminhamento de entrada tem de estar ativado para cada rede VPC autorizada a consultar a sua zona privada do Cloud DNS. Use o seguinte comando para apresentar uma lista de todas as políticas:
gcloud dns policies list
Identifique a rede na tabela de saída e verifique o campo Encaminhamento para ver se o encaminhamento está ativado.
Certifique-se de que a rede autorizada é uma rede de VPC
O encaminhamento de DNS requer sub-redes, que só estão disponíveis para redes VPC e não para redes antigas.
gcloud compute networks list \
--format="csv[no-heading](name, SUBNET_MODE)"
As redes antigas são identificadas na saída como LEGACY.
Certifique-se de que existe um endereço de encaminhamento DNS válido reservado nessa rede
O comando seguinte mostra todos os endereços IP de encaminhamento DNS reservados no seu projeto.
gcloud compute addresses list \
--filter="purpose=DNS_RESOLVER" \
--format='csv[no-heading](address, subnetwork)'
Pode adicionar uma cláusula AND ao filtro para limitar o resultado apenas à sub-rede que lhe interessa.
Exemplo:
--filter="name ~ ^dns-forwarding AND subnetwork ~ SUBNETWORK_NAME"
Se não vir um endereço IP na rede ou na região que esperava, apresente um pedido junto do Google Cloud apoio técnico.
Execute o comando dig direcionando a consulta para o endereço que encontrou no comando anterior. Faça-o a partir de uma VM na mesma rede. Este teste verifica se o encaminhador de entrada está a funcionar e se o problema reside noutro local.
dig DNS_NAME @10.150.0.1 # address returned by previous command
Repita o mesmo comando dig, mas a partir de um anfitrião no local através da VPN.
O registo CNAME definido numa zona privada não está a funcionar
O Cloud DNS só persegue registos CNAME, conforme descrito em Perseguição de CNAME.
Zonas de procura inversa
Esta secção fornece sugestões de resolução de problemas para zonas de pesquisa inversa. Alguns problemas de zonas privadas também se aplicam a zonas de pesquisa inversa. Para ver dicas adicionais, consulte a secção de resolução de problemas Zonas privadas.
A VM com um endereço não RFC 1918 não está a ser resolvida
Se tiver um endereço não RFC 1918, reconcilie a sua VM.
Reconcilie a sua VM com um endereço não RFC 1918
Se criou uma VM durante a versão alfa não RFC 1918 antes do lançamento do suporte do Cloud DNS, estas VMs podem não ser resolvidas corretamente. Para resolver este problema, reinicie as VMs.
Zonas de encaminhamento
Esta secção fornece dicas de resolução de problemas para zonas de encaminhamento. Alguns problemas de zonas privadas também se aplicam a zonas de encaminhamento. Para ver dicas adicionais, consulte a secção de resolução de problemas Zonas privadas.
As zonas de encaminhamento (encaminhamento de saída) não funcionam
Primeiro, certifique-se de que consegue consultar e resolver o nome DNS a partir de uma rede de VPC autorizada.
O encaminhamento de consultas de VMs numa rede VPC de consumidor para uma rede VPC de produtor não está a funcionar
Se estiver a usar o peering de DNS e quiser encaminhar consultas de VMs numa rede VPC de consumidor para uma rede VPC de produtor e, em seguida, para um ou mais servidores de nomes no local, certifique-se de que um dos seguintes pré-requisitos é cumprido:
A rede VPC do produtor tem o modo de encaminhamento dinâmico definido como
GLOBALA VM na rede da VPC do consumidor está na mesma região que o túnel de VPN ou o Cloud Interconnect na VPC do produtor
(Apenas 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 através do túnel da VPN clássica. A rede da VPC do produtor também tem de ter uma VM ou um túnel de VPN na mesma região que a sub-rede usada pelas VMs do cliente.
Por exemplo, suponha que a VPC1 usa uma zona de intercâmbio que envia consultas para
example.com.para a VPC2. Suponha também que a VPC2 tem uma zona de encaminhamento privada paraexample.com.que encaminha as consultas para um servidor de nomes no local através de um túnel de VPN clássica.Para que uma VM localizada em
us-east1na VPC1 possa consultarexample.com., a VPC2 tem de ter uma VM localizada emus-east1. Também tem de configurar uma rota estática que abranja os intervalos CIDR dos servidores de nomes no local, com o próximo salto configurado como o túnel da VPN clássica.Valide a conetividade através do Cloud VPN ou do Cloud Interconnect
Pode usar qualquer protocolo, como ping (ICMP), para testar a conetividade a uma VM de exemplo na sua rede VPC a partir de um local. Também tem de
tentar consultar o seu servidor de nomes no local diretamente a partir de uma amostra
Google Cloud de VM através de uma ferramenta como dig:
dig DNS_NAME @192.168.x.x # address of the onprem DNS server
Verifique as regras de firewall na sua rede VPC
A regra de firewall de saída permitida implícita permite ligações de saída e respostas estabelecidas de VMs na sua rede VPC, a menos que tenha criado regras personalizadas para negar a saída. Se criou regras de saída de negação personalizadas, tem de criar regras de autorização de prioridade mais elevada que permitam a saída para, pelo menos, os seus servidores de nomes no local.
Verifique a firewall no local
Certifique-se de que a sua firewall no local está configurada para permitir tráfego de entrada
de e tráfego de saída para 35.199.192.0/19.
Verifique os registos na sua firewall no local à procura de pedidos DNS de
35.199.192.0/19. Para usar uma expressão regex para pesquisar, use o seguinte:
"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"
Verifique o servidor de nomes nas instalações
Verifique se não tem nenhuma ACL configurada no seu servidor de nomes no local que bloqueie consultas de 35.199.192.0/19.
Verifique o seu servidor de nomes no local para ver se está a receber pacotes de
35.199.192.0/19. Se tiver acesso à shell, pode usar uma ferramenta como
tcpdump para procurar pacotes recebidos e enviados para
35.199.192.0/19:
sudo tcpdump port 53 and tcp -vv
Valide as rotas de regresso
A sua rede no local tem de ter uma rota para o destino 35.199.192.0/19 com o próximo salto a ser um túnel de VPN ou uma ligação Interconnect para a mesma rede VPC que enviou o pedido DNS. Este comportamento é descrito no artigo Criar zonas de encaminhamento.
Se usar vários túneis VPN para ligar a mesma rede VPC à sua rede no local, a resposta não tem de ser entregue através do mesmo túnel que a enviou. No entanto, a resposta tem de ser fornecida através de um túnel de VPN com um próximo salto na rede VPC mesma a partir da qual o pedido foi originado.
Se tiver ligado mais do que uma rede da VPC à sua rede no local, tem de garantir que as respostas DNS não são enviadas para a rede errada.O Google Cloud descarta as respostas DNS enviadas para a rede da VPC errada. Para uma solução recomendada, consulte o nosso guia de práticas recomendadas.
O encaminhamento de saída para um servidor de nomes que usa um endereço IP não RFC 1918 falha
Por predefinição, o Cloud DNS usa o encaminhamento padrão, que encaminha as consultas através da Internet pública quando o servidor de nomes de destino tem um endereço IP não RFC 1918. O encaminhamento padrão não suporta o encaminhamento de consultas para servidores de nomes com endereços não RFC 1918 que não sejam acessíveis a partir da Internet pública.
Para encaminhar consultas para um servidor de nomes que usa um endereço IP não RFC 1918 através da sua rede VPC, configure a zona de encaminhamento ou a política de servidor do Cloud DNS para usar o encaminhamento privado para o servidor de nomes de destino.
Para uma explicação das diferenças entre o encaminhamento padrão e o privado, consulte os destinos de encaminhamento e os métodos de encaminhamento.
Esta limitação aplica-se mesmo que exista uma rota de VPC para o servidor de nomes de destino. As rotas para endereços não RFC 1918 não têm efeito no comportamento de encaminhamento de saída do Cloud DNS quando o encaminhamento padrão está configurado.
O encaminhamento de saída para uma NIC secundária falha
Certifique-se de que configurou corretamente o controlador de interface de rede (NIC) secundário.
Para obter instruções sobre como configurar NICs adicionais, consulte o artigo Criar instâncias de máquinas virtuais com várias interfaces de rede.
As consultas encaminhadas 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, devolve um erro.SERVFAIL
Para resolver este problema, verifique se os servidores de nomes no local estão configurados corretamente. Em seguida, verifique se os seus servidores de nomes no local respondem a consultas do intervalo de endereços do Cloud DNS descrito em Abrir Google Cloud e firewalls no local para permitir o tráfego DNS no prazo de 4 segundos. Se os seus servidores de nomes no local consultarem servidores de nomes a montante (por exemplo, devido à configuração como resolvedores de cache), verifique se não existem problemas com os servidores de nomes a montante.
Além disso, se o destino do encaminhamento for um sistema no local, tenha em atenção que as rotas configuradas para esse caminho podem ser rotas dinâmicas personalizadas ou rotas estáticas personalizadas, com a exceção importante de que as rotas estáticas personalizadas com etiquetas de rede não são válidas para o encaminhamento de consultas DNS. Certifique-se de que a rota usada para alcançar o servidor de nomes no local não especifica uma etiqueta de rede.
Registos de recursos
Esta secção fornece sugestões de resolução de problemas para registos de recursos.
Dados inesperados ao consultar conjuntos de registos de recursos presentes na zona
Existem vários motivos pelos quais pode receber dados inesperados quando consulta conjuntos de registos de recursos presentes numa zona gerida do Cloud DNS:
Os conjuntos de registos de recursos criados através da sintaxe
@especificada na RFC 1035 não são suportados. O Cloud DNS interpreta o símbolo@em conjuntos de registos de recursos literalmente. Por conseguinte, na zonaexample.com., um conjunto de registos criado para o QNAME@é interpretado como@.example.com.em vez deexample.com.. Para resolver este problema, certifique-se de que cria conjuntos de registos sem o símbolo@. Todos os nomes são relativos ao vértice da zona.Tal como todos os registos, os registos CNAME de caráter universal estão sujeitos às regras de existência descritas na RFC 4592. Por exemplo, suponha que define os seguintes conjuntos de registos 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.92Uma consulta para
public.srv1.images.example.com.devolveNOERRORcom uma secção de resposta vazia. A existência de um registo entre o CNAME e o QNAME impede que o CNAME seja devolvido, mas não existe nenhum registo que corresponda exatamente ao QNAME, pelo que o Cloud DNS devolve uma resposta vazia. Este é o comportamento padrão do DNS.
Google Cloud A VM mostra registos de ponteiro (PTR) incorretos
Quando uma VM é migrada durante um evento de manutenção, a lógica do registo PTR não processa corretamente alguns casos extremos e reverte os registos PTR de DNS para o googleusercontent.comnome de domínio totalmente qualificado (FQDN). Para restaurar a funcionalidade, aplique novamente o registo PTR.
Para ver detalhes sobre como aplicar registos PTR numa VM, consulte o artigo Criar um registo PTR para uma instância de VM.
Conjuntos de registos de recursos do Cloud DNS devolvidos por ordem aleatória
De acordo com as práticas da indústria de DNS, os servidores de nomes do Cloud DNS agora aleatorizam a ordem dos conjuntos de registos de recursos e ignoram a ordem fornecida pelo servidor autoritário. Este é o comportamento normal do DNS e aplica-se às zonas do Cloud DNS públicase privadas.
Tipo de recurso zonal não suportado
Quando introduz a flag --location num comando gcloud ou num pedido de API para uma funcionalidade que segmenta uma zona do Cloud DNS diferente, o pedido é rejeitado. Por exemplo, se enviar um pedido de funcionalidade apenas zonal para um servidor global ou um pedido de funcionalidade apenas global para um servidor zonal, o servidor rejeita o pedido e devolve um erro _UNSUPPORTED_ZONAL_RESOURCETYPE.
Para ver uma lista de recursos e funcionalidades que o Cloud DNS zonal suporta, consulte o suporte do Cloud DNS zonal.
O que se segue?
- Para saber mais sobre as funcionalidades, consulte o artigo Vista geral do Cloud DNS.
- Para resolver erros, consulte o artigo Mensagens de erro.
- Para receber ajuda adicional, consulte Apoio técnico.