Solucionar problemas de DNS na nuvem, Solucionar problemas de DNS na nuvem

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

Zonas públicas

Esta seção aborda problemas com zonas públicas.

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

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

Para habilitar a API do Cloud DNS, siga estas etapas:

  1. No Google Cloud console, vá para a página da Biblioteca de API .

    Vá para a Biblioteca de API

  2. Para selecionar um projeto recente , selecione o Google Cloud projeto onde você deseja habilitar a API.

  3. Na página da biblioteca de APIs , use a caixa Pesquisar APIs e Serviços para pesquisar Cloud DNS API . Uma página descrevendo a API será exibida.

  4. Clique em Habilitar .

Zonas privadas

Esta seção aborda questões com zonas privadas.

Problemas de zona privada em projetos de serviço de VPC compartilhada

Para obter informações importantes sobre o uso de zonas privadas com redes VPC compartilhadas, consulte Zonas privadas e VPC compartilhadas .

Não é possível criar uma zona privada, não é possível listar ou criar políticas

Você precisa ter a função de Administrador de DNS para executar diversas ações de zona privada, como listar políticas de servidor do Sistema de Nomes de Domínio (DNS) ou criar uma zona privada. Essa função pode ser concedida por meio da ferramenta Gerenciamento de Identidade e Acesso (IAM) .

Zonas privadas não resolvidas na mesma rede VPC

Certifique-se de que você está executando o teste a partir de uma instância de VM cuja interface primária esteja na mesma rede que a zona privada que você criou

Uma instância de máquina virtual (VM) envia todo o tráfego para fora de sua interface primária, a menos que o tráfego seja destinado a uma sub-rede conectada a uma das outras interfaces ou se a VM tiver roteamento de políticas configurado. Certifique-se de que a interface primária da VM de teste esteja na mesma rede que a zona privada 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'])"

Certifique-se de que a rede esteja na lista de redes autorizadas a consultar 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 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 DNS. Certifique-se de que o sufixo do registro que você está consultando corresponda a pelo menos uma zona privada acessível na sua rede VPC. Por exemplo, Google Cloudprimeiro procura por myapp.dev.gcp.example.lan em uma zona que serve dev.gcp.example.lan , se acessível, antes de procurá-lo em uma zona que serve gcp.example.lan , se acessível.

A saída do comando a seguir 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 usando o servidor de metadados

Use dig para enviar a consulta de nome DNS diretamente para o Google Cloudservidor de metadados, 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 de resposta deve ser o servidor de metadados, 169.254.169.254 . Caso contrário, você configurou o sistema operacional convidado para usar um servidor de nomes DNS personalizado em vez do padrão.Google Cloud Servidor de metadados. As zonas privadas do Cloud DNS exigem que você use o servidor de metadados para resolução de nomes. Tanto o ambiente convidado do Linux quanto o ambiente convidado 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 privadas não resolvidas por meio de Cloud VPN ou Cloud Interconnect

Primeiro, certifique-se de que você consegue consultar e resolver com sucesso o nome DNS de dentro de uma rede VPC autorizada .

Verifique a conectividade por meio do Cloud VPN ou do Cloud Interconnect

Certifique-se de que a conectividade de um sistema local com sua rede VPC esteja operacional. Especificamente, o tráfego TCP e UDP na porta 53 deve poder sair da sua rede local e ser entregue à sua rede VPC. Verifique a configuração dos firewalls locais para garantir que esse tráfego de saída seja permitido.

Você pode usar qualquer protocolo, como ping (ICMP), para testar a conectividade com uma VM de amostra na sua rede VPC local. Embora as solicitações do Cloud DNS não sejam enviadas para Google Cloud Em VMs, testar a conectividade com uma VM de exemplo permite verificar a conectividade por meio de um túnel VPN na Nuvem ou de uma conexão do Cloud Interconnect. Certifique-se de configurar uma regra de firewall de permissão de entrada apropriada para a VM de exemplo.Google Cloud VM porque a regra de negação de entrada implícita bloqueia todo o tráfego de entrada, caso contrário.

Certifique-se de que o encaminhamento de entrada esteja habilitado para a rede VPC autorizada

O encaminhamento de entrada deve ser habilitado para cada rede VPC autorizada a consultar sua zona privada do Cloud DNS. Use o seguinte comando 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 o encaminhamento está habilitado.

Certifique-se de que a rede autorizada seja uma rede VPC

O encaminhamento de DNS requer sub-redes, que estão disponíveis apenas para redes VPC , não para redes legadas .

gcloud compute networks list \
    --format="csv[no-heading](name, SUBNET_MODE)"

Redes legadas são identificadas na saída como LEGACY .

Certifique-se de que haja um endereço de encaminhamento DNS válido reservado nessa rede

O comando a seguir mostra todos os endereços IP de encaminhamento de DNS reservados no seu projeto.

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

Você pode adicionar uma cláusula AND ao filtro para limitar a saída somente à sub-rede com a qual você se importa.

Exemplo:

--filter="name ~ ^dns-forwarding AND subnetwork ~ SUBNETWORK_NAME "

Se você não vir um endereço IP na rede/região que esperava, abra um tíquete com Google Cloud Apoiar .

Execute o comando dig apontando a consulta para o endereço encontrado no comando anterior. Faça isso a partir de uma VM na mesma rede. Este teste verifica se o encaminhador 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 de um host local pela VPN.

O registro CNAME definido em uma zona privada não está funcionando

O Cloud DNS somente rastreia registros CNAME conforme descrito em Rastreamento de CNAME .

Zonas de pesquisa reversa

Esta seção fornece dicas de solução de problemas para zonas de pesquisa reversa. Alguns problemas de zonas privadas também se aplicam a zonas de pesquisa reversa. Para dicas adicionais, consulte a seção Solução de problemas de zonas privadas .

VM com endereço não RFC 1918 não está sendo resolvida

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

Se você criou uma VM durante o alfa não RFC 1918, antes do lançamento do suporte ao Cloud DNS, essas VMs podem não ser resolvidas corretamente. Para resolver esse problema, reinicie suas VMs.

Zonas de encaminhamento

Esta seção fornece dicas de solução de problemas para zonas de encaminhamento. Alguns problemas de zonas privadas também se aplicam a zonas de encaminhamento. Para dicas adicionais, consulte a seção Solução de problemas de zonas privadas .

Zonas de encaminhamento (encaminhamento de saída) não funcionam

Primeiro, certifique-se de que você consegue consultar e resolver com sucesso o nome DNS de dentro de uma rede VPC autorizada .

O encaminhamento de consultas de VMs em uma rede VPC de consumidor para uma rede VPC de produtor 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, depois, para um ou mais servidores de nomes locais, certifique-se de que um dos seguintes pré-requisitos seja atendido:

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

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

  • ( Somente VPN Clássica ) A rede VPC produtora tem uma rota estática configurada para enviar tráfego destinado aos servidores de nomes locais através do túnel VPN Clássica. A rede VPC produtora também deve ter uma VM ou um túnel VPN na mesma região que a sub-rede usada pelas VMs clientes.

    • Por exemplo, suponha que a VPC1 use uma zona de peering que envia consultas para example.com. para 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 VPN clássico.

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

Verifique a conectividade por meio do Cloud VPN ou do Cloud Interconnect

Você pode usar qualquer protocolo, como ping (ICMP), para testar a conectividade com uma VM de exemplo na sua rede VPC a partir do local. Você também deve tentar consultar seu servidor de nomes local diretamente de uma VM de exemplo.Google Cloud VM usando 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 implícita de firewall de permissão de saída permite conexões de saída e respostas estabelecidas de VMs na sua rede VPC, a menos que você tenha criado regras personalizadas para negar a saída. Se você criou regras personalizadas de negação de saída, precisará criar regras de permissão de prioridade mais alta que permitam a saída pelo menos para seus servidores de nomes locais.

Verifique o firewall local

Certifique-se de que o firewall local esteja configurado para permitir o tráfego de entrada e saída35.199.192.0/19 .

Verifique os logs no seu firewall local, procurando por solicitações de DNS de35.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 local

Verifique se você não tem nenhuma ACL configurada no seu servidor de nomes local que possa bloquear consultas de35.199.192.0/19 .

Verifique seu servidor de nomes local para ver se ele está recebendo pacotes de35.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 para35.199.192.0/19 : 

sudo tcpdump port 53 and tcp -vv

Verificar rotas de retorno

Sua rede local deve ter uma rota para o35.199.192.0/19 destino com o próximo salto sendo um túnel VPN ou uma conexão de interconexão para a mesma rede VPC que enviou a solicitação DNS. Esse comportamento é descrito em Criação 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 precisa ser entregue usando o mesmo túnel que a enviou. No entanto, a resposta deve ser entregue usando um túnel VPN com um próximo salto na mesma rede VPC de origem da solicitação.

Se você tiver conectado mais de uma rede VPC à sua rede local, deverá garantir que as respostas de DNS não sejam enviadas para a rede errada. Google Cloud descarta respostas DNS enviadas para a rede VPC errada. Para uma solução recomendada, consulte 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 padrão, o Cloud DNS usa o roteamento padrão, que encaminha 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 oferece suporte ao encaminhamento de consultas para servidores de nomes com endereços não RFC 1918 que não podem ser acessados ​​pela 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 do Cloud DNS ou a política do servidor para usar o roteamento privado para o servidor de nomes de destino.

Para obter uma explicação das diferenças entre roteamento padrão e privado, consulte destinos de encaminhamento e métodos de roteamento .

Essa limitação se aplica mesmo se houver uma rota VPC para o servidor de nomes de destino; 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 roteamento padrão é configurado.

O encaminhamento de saída para uma NIC secundária falha

Certifique-se de ter configurado seu controlador de interface de rede secundário (NIC) corretamente.

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

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 deles, ele retornará um erro SERVFAIL .

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 do intervalo de endereços do Cloud DNS descrito em Open. Google Cloude firewalls locais para permitir tráfego DNS em até 4 segundos. Se seus servidores de nomes locais consultarem servidores de nomes upstream (por exemplo, por estarem configurados como resolvedores de cache), verifique se não há problemas com os servidores de nomes upstream.

Além disso, se o destino do encaminhamento for um sistema local, esteja ciente de que as rotas configuradas para esse caminho podem ser rotas dinâmicas personalizadas ou rotas estáticas personalizadas, com a importante exceção de que rotas estáticas personalizadas com tags de rede 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 recursos

Esta seção fornece dicas de solução de problemas para registros de recursos.

Dados inesperados ao consultar conjuntos de registros de recursos presentes na zona

Há vários motivos pelos quais você pode receber dados inesperados ao consultar conjuntos de registros de recursos presentes em uma zona gerenciada do Cloud DNS:

  1. Conjuntos de registros de recursos criados usando a sintaxe @ especificada na RFC 1035 não são suportados. O Cloud DNS interpreta o símbolo @ nesses conjuntos de registros de recursos literalmente; 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, certifique-se de criar conjuntos de registros sem o símbolo @ ; todos os nomes são relativos ao ápice da zona.

  2. Como todos os registros, os registros CNAME curinga estão sujeitos às regras de existência descritas no RFC 4592. Por exemplo, suponha que você defina os seguintes conjuntos de registros 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á nenhum registro que corresponda exatamente ao QNAME, então o Cloud DNS retorna uma resposta vazia. Este é o comportamento padrão do DNS.

Google Cloud A VM mostra registros de ponteiros (PTR) incorretos

Quando uma VM é migrada durante um evento de manutenção, a lógica do registro PTR não lida corretamente com alguns casos extremos e reverte os registros PTR do DNS para o nome de domínio totalmente qualificado (FQDN) googleusercontent.com . Para restaurar a funcionalidade, aplique o registro PTR novamente.

Para obter detalhes sobre como aplicar registros PTR em uma VM, consulte Criando um registro PTR para uma instância de VM .

Conjuntos de registros de recursos de DNS em nuvem retornados em ordem aleatória

Em consonância com as práticas do setor de DNS, os servidores de nomes Cloud DNS agora randomizam a ordem dos conjuntos de registros de recursos e ignoram a ordem fornecida pelo servidor autoritativo. Este é um comportamento normal do DNS e se aplica a tanto público quanto zonas DNS de nuvem privada.

Tipo de recurso zonal não suportado

Ao inserir o sinalizador --location em um comando gcloud ou solicitação de API para um recurso direcionado a uma zona diferente do Cloud DNS, a solicitação será rejeitada. Por exemplo, se você enviar uma solicitação de recurso somente zonal para um servidor global ou uma solicitação de recurso somente global para um servidor zonal, o servidor rejeitará a solicitação e gerará o erro _UNSUPPORTED_ZONAL_RESOURCE TYPE .

Para obter uma lista de recursos e funcionalidades compatíveis com o Cloud DNS zonal, consulte Suporte ao Cloud DNS zonal .

O que vem a seguir

,

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

Zonas públicas

Esta seção aborda problemas com zonas públicas.

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

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

Para habilitar a API do Cloud DNS, siga estas etapas:

  1. No Google Cloud console, vá para a página da Biblioteca de API .

    Vá para a Biblioteca de API

  2. Para selecionar um projeto recente , selecione o Google Cloud projeto onde você deseja habilitar a API.

  3. Na página da biblioteca de APIs , use a caixa Pesquisar APIs e Serviços para pesquisar Cloud DNS API . Uma página descrevendo a API será exibida.

  4. Clique em Habilitar .

Zonas privadas

Esta seção aborda questões com zonas privadas.

Problemas de zona privada em projetos de serviço de VPC compartilhada

Para obter informações importantes sobre o uso de zonas privadas com redes VPC compartilhadas, consulte Zonas privadas e VPC compartilhadas .

Não é possível criar uma zona privada, não é possível listar ou criar políticas

Você precisa ter a função de Administrador de DNS para executar diversas ações de zona privada, como listar políticas de servidor do Sistema de Nomes de Domínio (DNS) ou criar uma zona privada. Essa função pode ser concedida por meio da ferramenta Gerenciamento de Identidade e Acesso (IAM) .

Zonas privadas não resolvidas na mesma rede VPC

Certifique-se de que você está executando o teste a partir de uma instância de VM cuja interface primária esteja na mesma rede que a zona privada que você criou

Uma instância de máquina virtual (VM) envia todo o tráfego para fora de sua interface primária, a menos que o tráfego seja destinado a uma sub-rede conectada a uma das outras interfaces ou se a VM tiver roteamento de políticas configurado. Certifique-se de que a interface primária da VM de teste esteja na mesma rede que a zona privada 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'])"

Certifique-se de que a rede esteja na lista de redes autorizadas a consultar 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 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 DNS. Certifique-se de que o sufixo do registro que você está consultando corresponda a pelo menos uma zona privada acessível na sua rede VPC. Por exemplo, Google Cloudprimeiro procura por myapp.dev.gcp.example.lan em uma zona que serve dev.gcp.example.lan , se acessível, antes de procurá-lo em uma zona que serve gcp.example.lan , se acessível.

A saída do comando a seguir 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 usando o servidor de metadados

Use dig para enviar a consulta de nome DNS diretamente para o Google Cloudservidor de metadados, 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 de resposta deve ser o servidor de metadados, 169.254.169.254 . Caso contrário, você configurou o sistema operacional convidado para usar um servidor de nomes DNS personalizado em vez do padrão.Google Cloud Servidor de metadados. As zonas privadas do Cloud DNS exigem que você use o servidor de metadados para resolução de nomes. Tanto o ambiente convidado do Linux quanto o ambiente convidado 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 privadas não resolvidas por meio de Cloud VPN ou Cloud Interconnect

Primeiro, certifique-se de que você consegue consultar e resolver com sucesso o nome DNS de dentro de uma rede VPC autorizada .

Verifique a conectividade por meio do Cloud VPN ou do Cloud Interconnect

Certifique-se de que a conectividade de um sistema local com sua rede VPC esteja operacional. Especificamente, o tráfego TCP e UDP na porta 53 deve poder sair da sua rede local e ser entregue à sua rede VPC. Verifique a configuração dos firewalls locais para garantir que esse tráfego de saída seja permitido.

Você pode usar qualquer protocolo, como ping (ICMP), para testar a conectividade com uma VM de amostra na sua rede VPC local. Embora as solicitações do Cloud DNS não sejam enviadas para Google Cloud Em VMs, testar a conectividade com uma VM de exemplo permite verificar a conectividade por meio de um túnel VPN na Nuvem ou de uma conexão do Cloud Interconnect. Certifique-se de configurar uma regra de firewall de permissão de entrada apropriada para a VM de exemplo.Google Cloud VM porque a regra de negação de entrada implícita bloqueia todo o tráfego de entrada, caso contrário.

Certifique-se de que o encaminhamento de entrada esteja habilitado para a rede VPC autorizada

O encaminhamento de entrada deve ser habilitado para cada rede VPC autorizada a consultar sua zona privada do Cloud DNS. Use o seguinte comando 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 o encaminhamento está habilitado.

Certifique-se de que a rede autorizada seja uma rede VPC

O encaminhamento de DNS requer sub-redes, que estão disponíveis apenas para redes VPC , não para redes legadas .

gcloud compute networks list \
    --format="csv[no-heading](name, SUBNET_MODE)"

Redes legadas são identificadas na saída como LEGACY .

Certifique-se de que haja um endereço de encaminhamento DNS válido reservado nessa rede

O comando a seguir mostra todos os endereços IP de encaminhamento de DNS reservados no seu projeto.

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

Você pode adicionar uma cláusula AND ao filtro para limitar a saída somente à sub-rede com a qual você se importa.

Exemplo:

--filter="name ~ ^dns-forwarding AND subnetwork ~ SUBNETWORK_NAME "

Se você não vir um endereço IP na rede/região que esperava, abra um tíquete com Google Cloud Apoiar .

Execute o comando dig apontando a consulta para o endereço encontrado no comando anterior. Faça isso a partir de uma VM na mesma rede. Este teste verifica se o encaminhador 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 de um host local pela VPN.

O registro CNAME definido em uma zona privada não está funcionando

O Cloud DNS somente rastreia registros CNAME conforme descrito em Rastreamento de CNAME .

Zonas de pesquisa reversa

Esta seção fornece dicas de solução de problemas para zonas de pesquisa reversa. Alguns problemas de zonas privadas também se aplicam a zonas de pesquisa reversa. Para dicas adicionais, consulte a seção Solução de problemas de zonas privadas .

VM com endereço não RFC 1918 não está sendo resolvida

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

Se você criou uma VM durante o alfa não RFC 1918, antes do lançamento do suporte ao Cloud DNS, essas VMs podem não ser resolvidas corretamente. Para resolver esse problema, reinicie suas VMs.

Zonas de encaminhamento

Esta seção fornece dicas de solução de problemas para zonas de encaminhamento. Alguns problemas de zonas privadas também se aplicam a zonas de encaminhamento. Para dicas adicionais, consulte a seção Solução de problemas de zonas privadas .

Zonas de encaminhamento (encaminhamento de saída) não funcionam

Primeiro, certifique-se de que você consegue consultar e resolver com sucesso o nome DNS de dentro de uma rede VPC autorizada .

O encaminhamento de consultas de VMs em uma rede VPC de consumidor para uma rede VPC de produtor 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, depois, para um ou mais servidores de nomes locais, certifique-se de que um dos seguintes pré-requisitos seja atendido:

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

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

  • ( Somente VPN Clássica ) A rede VPC produtora tem uma rota estática configurada para enviar tráfego destinado aos servidores de nomes locais através do túnel VPN Clássica. A rede VPC produtora também deve ter uma VM ou um túnel VPN na mesma região que a sub-rede usada pelas VMs clientes.

    • Por exemplo, suponha que a VPC1 use uma zona de peering que envia consultas para example.com. para 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 VPN clássico.

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

Verifique a conectividade por meio do Cloud VPN ou do Cloud Interconnect

Você pode usar qualquer protocolo, como ping (ICMP), para testar a conectividade com uma VM de exemplo na sua rede VPC a partir do local. Você também deve tentar consultar seu servidor de nomes local diretamente de uma VM de exemplo.Google Cloud VM usando 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 implícita de firewall de permissão de saída permite conexões de saída e respostas estabelecidas de VMs na sua rede VPC, a menos que você tenha criado regras personalizadas para negar a saída. Se você criou regras personalizadas de negação de saída, precisará criar regras de permissão de prioridade mais alta que permitam a saída pelo menos para seus servidores de nomes locais.

Verifique o firewall local

Certifique-se de que o firewall local esteja configurado para permitir o tráfego de entrada e saída35.199.192.0/19 .

Verifique os logs no seu firewall local, procurando por solicitações de DNS de35.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 local

Verifique se você não tem nenhuma ACL configurada no seu servidor de nomes local que possa bloquear consultas de35.199.192.0/19 .

Verifique seu servidor de nomes local para ver se ele está recebendo pacotes de35.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 para35.199.192.0/19 : 

sudo tcpdump port 53 and tcp -vv

Verificar rotas de retorno

Sua rede local deve ter uma rota para o35.199.192.0/19 destino com o próximo salto sendo um túnel VPN ou uma conexão de interconexão para a mesma rede VPC que enviou a solicitação DNS. Esse comportamento é descrito em Criação 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 precisa ser entregue usando o mesmo túnel que a enviou. No entanto, a resposta deve ser entregue usando um túnel VPN com um próximo salto na mesma rede VPC de origem da solicitação.

Se você tiver conectado mais de uma rede VPC à sua rede local, deverá garantir que as respostas de DNS não sejam enviadas para a rede errada. Google Cloud descarta respostas DNS enviadas para a rede VPC errada. Para uma solução recomendada, consulte 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 padrão, o Cloud DNS usa o roteamento padrão, que encaminha 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 oferece suporte ao encaminhamento de consultas para servidores de nomes com endereços não RFC 1918 que não podem ser acessados ​​pela 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 do Cloud DNS ou a política do servidor para usar o roteamento privado para o servidor de nomes de destino.

Para obter uma explicação das diferenças entre roteamento padrão e privado, consulte destinos de encaminhamento e métodos de roteamento .

Essa limitação se aplica mesmo se houver uma rota VPC para o servidor de nomes de destino; 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 roteamento padrão é configurado.

O encaminhamento de saída para uma NIC secundária falha

Certifique-se de ter configurado seu controlador de interface de rede secundário (NIC) corretamente.

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

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 deles, ele retornará um erro SERVFAIL .

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 do intervalo de endereços do Cloud DNS descrito em Open. Google Cloude firewalls locais para permitir tráfego DNS em até 4 segundos. Se seus servidores de nomes locais consultarem servidores de nomes upstream (por exemplo, por estarem configurados como resolvedores de cache), verifique se não há problemas com os servidores de nomes upstream.

Além disso, se o destino do encaminhamento for um sistema local, esteja ciente de que as rotas configuradas para esse caminho podem ser rotas dinâmicas personalizadas ou rotas estáticas personalizadas, com a importante exceção de que rotas estáticas personalizadas com tags de rede 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 recursos

Esta seção fornece dicas de solução de problemas para registros de recursos.

Dados inesperados ao consultar conjuntos de registros de recursos presentes na zona

Há vários motivos pelos quais você pode receber dados inesperados ao consultar conjuntos de registros de recursos presentes em uma zona gerenciada do Cloud DNS:

  1. Conjuntos de registros de recursos criados usando a sintaxe @ especificada na RFC 1035 não são suportados. O Cloud DNS interpreta o símbolo @ nesses conjuntos de registros de recursos literalmente; 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, certifique-se de criar conjuntos de registros sem o símbolo @ ; todos os nomes são relativos ao ápice da zona.

  2. Como todos os registros, os registros CNAME curinga estão sujeitos às regras de existência descritas no RFC 4592. Por exemplo, suponha que você defina os seguintes conjuntos de registros 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á nenhum registro que corresponda exatamente ao QNAME, então o Cloud DNS retorna uma resposta vazia. Este é o comportamento padrão do DNS.

Google Cloud A VM mostra registros de ponteiros (PTR) incorretos

Quando uma VM é migrada durante um evento de manutenção, a lógica do registro PTR não lida corretamente com alguns casos extremos e reverte os registros PTR do DNS para o nome de domínio totalmente qualificado (FQDN) googleusercontent.com . Para restaurar a funcionalidade, aplique o registro PTR novamente.

Para obter detalhes sobre como aplicar registros PTR em uma VM, consulte Criando um registro PTR para uma instância de VM .

Conjuntos de registros de recursos de DNS em nuvem retornados em ordem aleatória

Em consonância com as práticas do setor de DNS, os servidores de nomes Cloud DNS agora randomizam a ordem dos conjuntos de registros de recursos e ignoram a ordem fornecida pelo servidor autoritativo. Este é um comportamento normal do DNS e se aplica a tanto público quanto zonas DNS de nuvem privada.

Tipo de recurso zonal não suportado

Ao inserir o sinalizador --location em um comando gcloud ou solicitação de API para um recurso direcionado a uma zona diferente do Cloud DNS, a solicitação será rejeitada. Por exemplo, se você enviar uma solicitação de recurso somente zonal para um servidor global ou uma solicitação de recurso somente global para um servidor zonal, o servidor rejeitará a solicitação e gerará o erro _UNSUPPORTED_ZONAL_RESOURCE TYPE .

Para obter uma lista de recursos e funcionalidades compatíveis com o Cloud DNS zonal, consulte Suporte ao Cloud DNS zonal .

O que vem a seguir