Solução de problemas

Nesta página, descrevemos os erros que podem ocorrer ao usar o Cloud DNS e como solucioná-los.

Zonas gerenciadas

Esta seção lista os erros relacionados a zonas gerenciadas.

invalidFieldValue

Valor inválido para "entity.managedZone.name"

A criação da zona gerenciada pode falhar e exibir este erro se o nome da zona não começar com uma letra, terminar com uma letra ou um dígito e conter apenas letras, dígitos ou traços.

managedZoneDnsNameNotAvailable

A zona gerenciada especificada não está disponível para criação.

A operação de criação da zona gerenciada pode falhar e exibir esse erro pelos seguintes motivos:

  • O nome de DNS da zona a ser criada está reservado. Por exemplo, ponto (.), .com ou .co.uk.
  • Não há mais servidores de nomes disponíveis para hospedar o nome de DNS da zona. O Cloud DNS usa um pool de servidores de nomes, e esse pool é finito. Uma consulta DNS em qualquer servidor de nomes precisa ser mapeada inequivocamente em uma zona gerenciada.

Ação recomendada: se você for o proprietário registrado do nome DNS em questão, verifique se não há sobreposição de zonas. Para configurar o DNS para um domínio e os subdomínios dele, recomendamos que você crie uma única zona raiz e adicione registros para cada subdomínio nessa zona.

verifyManagedZoneDnsNameOwnership

Verifique quem é o proprietário do domínio "EXAMPLE.COM" (ou de um domínio pai) em http://www.google.com/webmasters/verification/ e tente novamente.

Ação recomendada: ao receber esse erro, verifique quem é o proprietário do domínio e tente novamente.

Registros

Os erros desta seção são relacionados a registros.

containerNotEmpty

O registro especificado não pode ser excluído porque não está em branco.

Ação recomendada: se você quiser excluir o registro, será preciso esvaziá-lo primeiro.

invalidZoneApex

O conjunto de registros de recurso especificado é inválido porque a zona precisa conter exatamente um conjunto de registros de recurso de um determinado tipo no apex.

"Apex", neste contexto, significa apenas o nome de DNS com o menor número de rótulos permitido na zona. O apex de uma zona é o nome de DNS igual a ManagedZone.dnsName.

Esse erro indica que você tentou fazer uma mudança que violaria uma regra de DNS do apex da zona. As seguintes ações podem causar esse erro:

  • Você tentou excluir o conjunto de registros de recurso NS obrigatório no apex.
  • Você tentou excluir o conjunto de registros de recurso SOA obrigatório no apex.
  • Você tentou criar um conjunto de registros de recurso do tipo SOA fora do apex.

Ação recomendada: se você recebeu esse erro, significa que está tentando fazer algo que não é permitido pelas regras de DNS. Verifique se há erros na sua solicitação. Não é necessário excluir esses conjuntos de registros de recurso obrigatórios.

invalidRecordCount

O conjunto de registros de recursos "entity.change.additions[XX]" só pode ter um registro, porque é do tipo "<SOA_OR_CNAME>".

As regras de DNS especificam que determinados conjuntos de registros de recurso só podem ter um tipo de registro. Atualmente, esse tipo pode ser SOA ou CNAME. Você receberá esse erro se tentar fazer uma mudança que viole essas regras. Por exemplo:

{
  kind: "dns#rrset"
  name: "blog.foo.com.",
  type: "CNAME",
  rrdata: [ "www.foo.com.", "www2.foo.com." ],
  ...
}

Ação recomendada: se receber este erro, verifique sua solicitação. Você está tentando fazer algo que não é permitido.

cnameResourceRecordSetConflict

O conjunto de registros de recurso "entity.change.additions[XX]" é inválido porque o nome de DNS "EXAMPLE.COM" pode ter um conjunto de registros de recurso CNAME ou de outros tipos, mas não ambos.

Este erro pode ocorrer quando você cria dois tipos de conjuntos de registros de recursos, como um registro A e um CNAME, para o mesmo nome de DNS. Uma causa comum desse erro é tentar criar um registro CNAME no apex da zona. Isso não é possível porque entraria em conflito com os registros obrigatórios SOA e NS de mesmo nome.

Ação recomendada: escolha um dos dois tipos.

wildcardNotAllowed

O conjunto de registros de recurso tem o tipo errado para ser curinga.

No contexto de DNS, um conjunto curinga (em inglês) é um tipo especial de conjunto de registros de recurso que corresponde a solicitações por nomes de domínio não existentes. Uma limitação do Cloud DNS é que não é possível criar um conjunto de registros de recurso curinga com o tipo NS.

Ação recomendada: os conjuntos de registros de recurso NS curinga não são aceitos no momento. Entre em contato com o suporte ou entre no grupo cloud-dns-discuss e compartilhe o que você está tentando fazer.

invalidValue

Esse é um erro genérico que indica que há algo inválido na sua solicitação, independentemente do estado do servidor. A mensagem de erro inclui o caminho para a parte da solicitação que apresenta problemas, assim como o valor inválido. Este erro pode ser gerado por diferentes fatores. Veja alguns deles abaixo:

  • Você especificou um conjunto de registros de recursos com um nome inválido. Por exemplo: "foo..bar" não é um nome DNS válido (marcador do meio em branco).
  • Você especificou um conjunto de registros de recurso com um tipo inválido. Por exemplo: A e CNAME são tipos válidos, mas "XXX" não.
  • Você especificou um conjunto de registros de recurso sem registros.
  • Você especificou dados de registros de recurso inválidos. Por exemplo: “1.1.1.1” é um dado de registros de recurso válido para o tipo A. Por outro lado, “XXX” é um dado de registros de recurso inválido para o tipo A.
  • Você especificou um conjunto de registros de recurso com TTL inválido. O TTL precisa ser um número inteiro não negativo.
  • Você especificou um nome de recurso muito longo.

Ação recomendada: corrija sua solicitação.

Erros gerais

Esta seção descreve erros gerais.

alreadyExists

O recurso especificado já existe. Não é possível criar uma cópia.

Ação recomendada: ao criar um recurso, use a API get/list adequada para descobrir quais já existem.

Se você recebeu esse erro ao incluir registros, é porque um registro individual é tratado como um conjunto de registros. Isso significa que cada entrada (se houver mais de uma) funciona como um registro diferente. Você tem a opção de incluir dois valores ou strings ao conjunto de registros do mesmo nome de DNS. Para fazer isso, insira um espaço entre o primeiro e o segundo valor.

accessNotConfigured

Acesso não configurado

Para resolver esse erro, ative a API do Cloud DNS no seu projeto.

inactiveBillingState

O projeto EXAMPLE_PROJECT não pode aceitar solicitações enquanto estiver em um estado de faturamento inativo. A atualização do estado de faturamento pode levar alguns minutos.

Ação recomendada: ative o faturamento do projeto na seção Configurações do Console do Cloud.

preconditionFailed

Esse é um erro genérico que indica que algo na solicitação não é compatível com o estado atual do recurso do servidor. O cliente precisa fazer algo para corrigir isso e tentar novamente. Isso poderá acontecer se você enviar uma solicitação de mudança create que tente excluir um conjunto de registros de recurso sem qualquer correspondente dentre os que já existem (mesmo nome e tipo).

Leia novamente o estado atual da zona e decida o que você quer excluir. Pode ter havido alguma mudança desde sua última consulta.

A mensagem de erro inclui o caminho para a parte da solicitação que apresenta o problema. Por exemplo, entity.change.deletions[6] indica o sétimo elemento da matriz “deletions” do objeto de mudança no corpo POST da solicitação.

Ação recomendada: corrija a parte da solicitação sinalizada como problemática.

required

Este é um erro genérico que indica a falta de uma parte obrigatória na solicitação. Por exemplo, a solicitação de criação de zona gerenciada exige um nome, um nome DNS e uma descrição. Se alguma dessas partes não constar na solicitação, o seguinte erro será mostrado.

Ação recomendada: preencha o parâmetro obrigatório e tente novamente.

notFound

O recurso especificado não existe.

Ação recomendada: verifique se você usou o nome de um recurso que existe.

quotaExceeded

Você recebe esse erro quando uma mudança iminente excede sua cota atual. Por exemplo, você só pode usar um número definido de conjuntos de registros de recursos em cada zona. A cota é associada ao projeto. Se você precisar aumentá-la, envie uma solicitação para o atendimento ao cliente do Google. Projetos novos têm uma cota padrão. Veja a operação Projects.get para todas as limitações impostas pelo DNS.

Ação recomendada: verifique seu projeto para entender por que o recurso em questão está sendo tão usado. Acesse a página de cotas do respectivo projeto no Console do Cloud para solicitar um aumento na cota. Consulte também Como trabalhar com cotas.

Zonas particulares

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

Problemas com zonas particulares em projetos de serviço de VPC compartilhada

Consulte Zonas particulares e VPC compartilhada na página de visão geral para mais informações importantes sobre o uso desses elementos.

Não é possível criar uma zona particular nem 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 políticas de servidor DNS ou criar uma zona desse tipo. Esse papel é concedido por meio da ferramenta Cloud IAM.

As zonas particulares não resolvem na mesma rede VPC

Verifique se você está realizando o teste em uma VM que tenha a interface principal na mesma rede que a zona particular criada

A VM envia todo o tráfego para fora da interface principal. Para que isso não aconteça, o tráfego precisa ser destinado a uma sub-rede conectada a uma das outras interfaces, ou a VM precisa ter roteamento baseado em política. Verifique se a VM de teste tem a interface principal na mesma rede que a zona particular que você está testando.

Determine a rede que a 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'])"

Verificar se o nome de 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 consultado 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 para a 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 em uma VM, verifique se o ambiente convidado correto foi instalado.

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

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

Verificar a conectividade por meio do Cloud VPN ou do 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 com um túnel do Cloud VPN ou o Cloud Interconnect. É importante configurar uma regra de firewall adequada que permita a entrada do tráfego na VM de exemplo do Google Cloud, já que a regra de negação de entrada implícita bloqueia todo o tráfego recebido.

Garantir 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.

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

Use o comando abaixo para ver todos os endereços IP do encaminhador de DNS reservados no projeto.

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

É possível incluir uma cláusula AND ao filtro para limitar os resultados apenas à sub-rede do seu interesse.

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 Cloud.

Execute o comando "dig" apontando a consulta para o endereço que você encontrou acima. Faça isso a partir de uma VM na mesma rede. Esse teste verifica se o encaminhamento de entrada está funcionando, e se o problema tem outro motivo.

dig ${dns-name} @10.150.0.1 # - address returned by command above.

Execute novamente o mesmo comando "dig", mas a partir de uma VM 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 compatíveis. Já os registros CNAME que apontam para nomes de domínio definidos em outras zonas particulares, em zonas internas ou na Internet, 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. Consulte a seção de solução de problemas em zonas particulares para mais dicas.

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

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

Se você criou uma instância de VM durante a versão Alfa não RFC 1918, antes do Cloud DNS oferecer compatibilidade, talvez ela não seja resolvida corretamente. Para solucionar esse problema, basta pausar e reiniciar a VM, que ela será resolvida corretamente.

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. Consulte a seção de solução de problemas em zonas particulares para mais dicas.

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 provenientes de VMs em uma rede VPC consumidora para uma produtora e, em seguida, para um ou mais servidores de nomes locais, 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 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 privada 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.

Verificar a conectividade por meio do Cloud VPN ou do 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. Tente também consultar o servidor de nomes local diretamente a partir de uma VM de exemplo do Google Cloud usando uma ferramenta como dig:

dig ${dns-name} @192.168.x.x # - address of the onprem DNS server.

Verificar 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 pesquisar usando uma expressão regex, use "35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*".

Verificar 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 um próximo salto sendo um túnel de VPN para a mesma rede VPC que enviou a solicitação DNS, conforme descrito na página Como criar de zonas de encaminhamento.

Se você usar vários túneis VPN para conectar a mesma rede VPC à sua rede local, a resposta não precisará ser entregue usando o mesmo túnel de envio. 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, 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 de endereços IP recursivamente por meio de 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 resolverá 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 busca registros CNAME 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

O Cloud DNS sempre encaminha consultas por meio da Internet pública quando o servidor de nomes de destino tem um endereço IP não RFC 1918. Os servidores de nomes com endereços não RFC 1918 que são inacessíveis na Internet pública não podem ser usados como destino de encaminhamento.

Essa limitação se aplica mesmo se houver uma rota de VPC para o servidor de nomes de destino. 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 esses destinos. É possível ver um ou mais destes sinais:

  • 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 para os destinos de encaminhamento (por exemplo, dig @<TARGET> <QNAME>) podem ser bem-sucedidas.

Para resolver esse 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 VPC que usa intervalos de endereços não RFC 1918

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

Próximas etapas