DNS interno

As redes de nuvem privada virtual no GCP têm um serviço DNS interno que permite que instâncias na mesma rede acessem umas às outras usando nomes DNS internos. Registros DNS internos são criados em uma zona .internal. Conforme você gerencia suas instâncias de VM, o GCP cria, atualiza e remove automaticamente os registros DNS internos.

Por exemplo, se você excluir uma instância de VM, o GCP removerá automaticamente o registro DNS interno da instância. Se você criar uma nova instância com o mesmo nome, o GCP criará um novo registro para a instância substituta.

Sobre o DNS interno

Os nomes DNS internos têm as seguintes especificações:

  • O nome DNS interno de uma instância de VM só é resolvido para o endereço IP interno principal dela. Nomes DNS internos não podem ser usados para conectar-se aos endereços IP externos de uma instância.

  • Os nomes DNS internos não podem ser configurados para resolver os IPs de alias secundários.

  • Os nomes DNS internos só podem ser resolvidos de outras VMs que estão no mesmo projeto e na rede VPC. Não é possível usar o DNS interno para conectar instâncias que estejam em outras redes VPC, mesmo se elas estiverem no mesmo projeto.

Tipos de nomes DNS internos

O GCP tem dois tipos de nomes DNS internos. O tipo de DNS interno padrão é definido com base em quando você ativou a API do Compute Engine. Também é possível especificar um nome DNS interno personalizado ao criar uma instância, consulte Como criar uma instância de VM com um nome de host personalizado.

Tipo de DNS interno Nome de domínio totalmente qualificado (FQDN) Tipo padrão do projeto
DNS por zona [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal Padrão para todas as organizações ou projetos independentes que ativaram a API do Compute Engine após 06 de setembro de 2018.
DNS global (em todo o projeto) [INSTANCE_NAME].c.[PROJECT_ID].internal Padrão para todas as organizações ou projetos independentes que ativaram a API do Compute Engine antes de 06 de setembro de 2018.

em que:

  • [INSTANCE_NAME] é o nome da instância;
  • [ZONE] é a zona em que o disco está;
  • [PROJECT_ID] é o projeto que contém a instância.

Você pode controlar qual tipo de nome DNS interno é usado no nível do projeto ou da instância. Consulte Como configurar nomes DNS para seu projeto ou instâncias.

Como determinar o nome DNS interno de uma VM

Use o procedimento a seguir para ler o nome DNS interno atribuído a uma VM. A fonte da verdade de um nome DNS interno é o servidor de metadados dele.

  1. Conecte-se à instância.
  2. Veja o nome do host nos metadados da instância:

    curl "http://metadata.google.internal/computeMetadata/v1/instance/hostname" \
    -H "Metadata-Flavor: Google"
    

O formato do nome do host indica o tipo de nome DNS interno que a VM usa.

Como acessar VMs pelo DNS interno

O servidor de metadados também é o resolvedor do servidor de nomes para consultas DNS emitidas pela VM. O servidor de metadados resolve todas as consultas DNS, tanto para nomes DNS internos quanto para nomes DNS externos. Para consultas externas de DNS, o servidor de metadados transmite solicitações para os servidores de nome público do Google.

O exemplo a seguir usa ping para conectar uma instância que usa DNS por zona. Esse método funciona, desde que você tenha criado uma regra de firewall que permita o tráfego ICMP de entrada para a instância.

$ ping [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal -c 1

PING [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal (10.240.0.17) 56(84) bytes of data.
64 bytes from [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal (10.240.0.17): icmp_seq=1 ttl=64 time=0.136 ms

em que:

  • [INSTANCE_NAME] é o nome da instância;
  • [ZONE] é a zona em que a instância está localizada;
  • [PROJECT_ID] é o projeto que contém a instância.

DNS interno e resolv.conf

Por padrão, a maioria das distribuições Linux armazena informações de DHCP no resolv.conf. As instâncias do Compute Engine estão configuradas para renovar as concessões de DHCP a cada 24 horas. No caso das instâncias ativadas para DNS por zona, a concessão de DHCP tem prazo de expiração de uma hora. A renovação do DHCP substitui o arquivo, desfazendo todas alterações que você fez. As instâncias que usam DNS por zona têm entradas globais e por zona no arquivo resolv.conf.

DNS por zona

Exemplo de arquivo resolv.conf por zona:

# Local domain name. Computed from your project name.
domain [ZONE].c.[PROJECT_ID].internal
# Search list for hostname lookup. Starting with entries that represent
# your project and ending with google.internal to facilitate metadata server requests.
search [ZONE].c.[PROJECT_ID].internal. c.[PROJECT_ID].internal. google.internal.
# Address of the DNS server to resolve project specific, and global domain names.
nameserver 169.254.169.254

em que:

  • [ZONE] é a zona em que a instância está localizada.
  • [PROJECT_ID] é o projeto que contém a instância.

Exemplo de arquivo dhcp.lease por zona:

lease {
  # What interface we are using for the network
  interface "eth0";
  fixed-address 10.128.0.9;
  option subnet-mask 255.255.255.255;
  option routers 10.128.0.1;
  # Lease timeout, older VM instances will have this value set to infinite.
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 169.254.169.254;
  option dhcp-server-identifier 169.254.169.254;
  option interface-mtu 1460;
  # Search path options that are copied into the resolv.conf
  option domain-search "[ZONE].c.[PROJECT_ID].internal.", "c.[PROJECT_ID].internal.", "google.internal.";
  option ntp-servers 169.254.169.254;
  option rfc3442-classless-static-routes 32,10,128,0,1,0,0,0,0,0,10,128,0,1;
  option host-name "[INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal";
  option domain-name "[ZONE].c.[PROJECT_ID].internal";
  renew 4 2017/11/16 02:15:52;
  rebind 4 2017/11/16 02:43:59;
  expire 4 2017/11/16 02:51:29;
}

em que:

  • [INSTANCE_NAME] é o nome da instância;
  • [ZONE] é a zona em que o disco está;
  • [PROJECT_ID] é o projeto que contém a instância.

DNS global

Exemplo de arquivo resolv.conf global:

# Local domain name. Computed from your project name.
domain c.[PROJECT_ID].internal
# Search list for hostname lookup. Starting with entries that represent
# your project and ending with google.internal to facilitate metadata server requests.
search c.[PROJECT_ID].internal google.internal.
# Address of the DNS server to resolve project specific, and global domain names.
nameserver 169.254.169.254

em que [PROJECT_ID] é o projeto que contém a instância.

Exemplo de arquivo dhcp.lease global:

lease {
  # What interface we are using for the network
  interface "eth0";
  fixed-address 10.128.0.8;
  option subnet-mask 255.255.255.255;
  option routers 10.128.0.1;
  # Lease timeout, older VM instances will have this value set to infinite.
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option domain-name-servers 169.254.169.254;
  option dhcp-server-identifier 169.254.169.254;
  option interface-mtu 1460;
  # Search path options that are copied into the resolv.conf
  option domain-search "c.[PROJECT_ID].internal.", "google.internal.";
  option ntp-servers 169.254.169.254;
  option rfc3442-classless-static-routes 32,10,128,0,1,0,0,0,0,0,10,128,0,1;
  option host-name "[INSTANCE_NAME].c.[PROJECT_ID].internal";
  option domain-name "c.[PROJECT_ID].internal";
  renew 4 2017/11/16 12:07:00;
  rebind 4 2017/11/16 22:44:53;
  expire 5 2017/11/17 01:44:53;
}

em que:

  • [INSTANCE_NAME] é o nome da instância;
  • [PROJECT_ID] é o projeto que contém a instância.

Esses arquivos têm as seguintes restrições:

  • O caminho de pesquisa pode processar apenas seis registros, sendo que três deles são fornecidos pelo Compute Engine. Se você adicionar entradas ao caminho de pesquisa totalizando mais de seis, o sistema operacional não aplicará as regras de pesquisa após a 6ª entrada. Isso pode fazer com que algumas funcionalidades do Compute Engine, como o acesso a instâncias por meio dos nomes delas, parem de funcionar.
  • Editar manualmente o arquivo resolv.conf fará com que ele seja revertido para o DHCP padrão sempre que o período de concessão de DHCP de 24 horas expirar na instância. No caso das instâncias que usam DNS por zona, a concessão de DHCP expira depois de uma hora. Para fazer modificações estáticas no arquivo resolv.conf, diversas distribuições do Linux permitem que itens sejam adicionados ou anexados à política DHCP.

Debian 9

Exemplo do arquivo /etc/dhcp/dhclient.conf:

# Configuration file for /sbin/dhclient.
#
...
append domain-search "mydomain.com";
prepend domain-name-servers 172.16.1.1;

em que mydomain.com é o novo domínio de pesquisa e 172.16.1.1 é o IP do servidor DNS.

Nomes de DNS por zona

Os nomes de DNS por zona incluem o nome da instância, a zona em que ela está localizada e o projeto que a contém. Os nomes de DNS globais não incluem a zona em que a instância está localizada. Os nomes de DNS por zona em um local funcionam independentemente de outros locais. Isso permite criar aplicativos multirregionais e tolerantes a falhas, com melhores características de disponibilidade.

Ainda é possível usar os nomes DNS em projetos e organizações existentes. No entanto, recomendamos a migração para os nomes DNS por zona.

Como configurar nomes DNS para projetos ou instâncias

Para ativar os caminhos de pesquisa de DNS por zona e/ou global nas instâncias, defina a variável VmDnsSetting nos metadados do projeto ou da instância. Se você definir VmDnsSetting nos metadados de uma instância específica, todas as variáveis VmDnsSetting herdadas dos metadados do projeto referentes a essa instância serão modificadas.

  • Defina VmDnsSetting=ZonalOnly para que as instâncias sejam endereçáveis apenas pelos nomes DNS por zona. As instâncias manterão os caminhos de busca global e por zona, mas os nomes DNS globais deixarão de funcionar. Outras instâncias podem fazer referência às instâncias com essa configuração somente por meio dos nomes DNS por zona, mas não pelos nomes DNS globais nem pelos caminhos de pesquisa. Essa é a opção recomendada caso seus aplicativos sejam compatíveis com essa configuração, que é padrão para instâncias em projetos independentes e naqueles criados em uma organização que ativou a API do Compute Engine após 06 de setembro de 2018. Observe que, se um projeto for migrado para uma organização, o nome DNS padrão dele não será alterado.
  • Defina VmDnsSetting=ZonalPreferred para ativar os caminhos de pesquisa de DNS por zona, mantendo, ao mesmo tempo, o nome DNS global. As instâncias com essa configuração podem fazer referência às outras usando nomes DNS globais ou por zona. Além disso, elas continuarão a fazer referência às instâncias configuradas somente com nomes DNS globais.
  • Defina VmDnsSetting=GlobalOnly para que as instâncias usem apenas nomes globais como nomes de domínio e entradas de caminho de pesquisa. Use esse valor para excluir instâncias de uma configuração de DNS por zona em todo o projeto ou para restaurar as instâncias a fim de usar apenas nomes DNS globais. Essa é a configuração padrão para instâncias em projetos independentes e naqueles criados em uma organização que ativou a API do Compute Engine antes de 06 de setembro de 2018. Observe que, se um projeto for migrado para uma organização, o nome DNS padrão dele não será alterado.

Leia Como configurar metadados personalizados para saber como definir os valores de metadados de um projeto ou de uma instância.

Depois de configurar a variável VmDnsSetting de uma instância, atualize a concessão do DHCP na instância. Para isso, reinicie a instância, aguarde até que a concessão expire ou execute um dos comandos a seguir:

  • Instâncias do Linux: sudo dhclient -v -r
  • Instâncias do Windows Server: ipconfig /renew

Como migrar aplicativos existentes para o recurso de nomes DNS por zona

É possível continuar a usar nomes DNS globais nos projetos existentes, mas recomendamos a migração de instâncias e aplicativos para que usem nomes DNS por zona e, assim, aproveitem os benefícios oferecidos por esse sistema. Em geral, use o seguinte processo de migração:

  1. Verifique os aplicativos e atualize-os para solucionar problemas de compatibilidade com as configurações somente por zona:
    • Aplicativos que fazem referência às instâncias usando os nomes delas ou os nomes de domínio totalmente qualificados globais: nomes de instâncias e nomes de instâncias globais nem sempre serão resolvidos em um ambiente apenas por zona. Como prática recomendada, atualize esses nomes para usar nomes de domínio totalmente qualificados por zona.
    • Aplicativos que adotam um formato de nome de domínio totalmente qualificado global específico: partindo do princípio de que um formato de nome de domínio geralmente representa um problema fundamental no design do aplicativo, o Google recomenda projetar aplicativos de modo que eles funcionem independentemente do formato de nome de domínio.
    • Aplicativos em que não se espera uma alteração no nome de domínio: no caso desses aplicativos, é necessário realizar uma reinicialização completa para coletar os nomes novos. Se possível, atualize os aplicativos para identificar e processar as alterações no nome de domínio da instância.
  2. Configure as instâncias na sua rede VPC interna para que usem a configuração VmDnsSetting=ZonalPreferred, que utiliza nomes DNS globais e por zona. Nessa fase de transição, as instâncias poderão continuar usando nomes globais até que os aplicativos estejam prontos para usar apenas nomes por zona:
    1. Ative VmDnsSetting=ZonalPreferred em uma instância, definindo esse valor nos metadados personalizados.
    2. Atualize a concessão de DHCP nessa instância, para que ela comece a usar nomes de DNS por zona:
      • Instâncias do Linux: sudo dhclient -v -r
      • Instâncias do Windows Server: ipconfig /renew
    3. Teste os aplicativos na instância para garantir que eles estejam funcionando conforme o esperado. Talvez alguns aplicativos não estejam preparados para alterações de nome de domínio e podem exigir uma reinicialização completa para coletar os nomes novos.
    4. Repita esse processo para ativar VmDnsSetting=ZonalPreferred e atualize a concessão de DHCP nas instâncias restantes na rede VPC até que todas operem conforme o esperado, usando apenas os nomes DNS por zona. Se preferir, defina VmDnsSetting=ZonalPreferred nos metadados do projeto para configurar o uso de nomes DNS por zona em todas as instâncias contidas nesse projeto.
  3. Após verificar se os aplicativos estão executando corretamente, usando somente os nomes de domínio por zona com a configuração VmDnsSetting=ZonalPreferred, você poderá desativar os nomes globais na rede VPC. Configure as instâncias na rede VPC interna para usar a configuração
    VmDnsSetting=ZonalOnly, que utiliza apenas os nomes DNS por zona:
    1. Ative VmDnsSetting=ZonalOnly em uma instância definindo esse valor nos metadados personalizados.
    2. Atualize a concessão de DHCP nessa instância, para que ela comece a usar nomes DNS por zona:
      • Instâncias do Linux: sudo dhclient -v -r
      • Instâncias do Windows Server: ipconfig /renew
    3. Teste os aplicativos na instância para garantir que eles estejam funcionando conforme o esperado.
    4. Repita esse processo para ativar VmDnsSetting=ZonalOnly e atualize a concessão de DHCP nas instâncias restantes na rede VPC até que todas operem conforme o esperado, usando apenas os nomes DNS por zona.
  4. Repita o processo em todas as redes VPC, até que todas as instâncias do projeto usem a configuração VmDnsSetting=ZonalOnly. Você pode definir VmDnsSetting=ZonalOnly nos metadados no nível do projeto para aplicá-la automaticamente a todas as instâncias criadas dentro do projeto. Se preferir, defina VmDnsSetting=ZonalOnly nos metadados para configurar o uso de nomes DNS por zona em todas as instâncias.

Como desativar o DNS por zona em um projeto ou uma instância

Para desativar o DNS por zona em uma instância específica, defina VmDnsSetting=GlobalOnly nos metadados dessa instância. Para desativar o DNS por zona em um projeto inteiro, defina VmDnsSetting=GlobalOnly nos metadados do projeto e certifique-se de que nenhuma instância esteja configurada individualmente com o valor VmDnsSetting. Leia Como configurar metadados personalizados para saber como definir os valores de metadados de um projeto ou de uma instância.

Caso seja necessário forçar a atualização imediata da concessão de DHCP, use um dos comandos a seguir:

  • SO otimizado para contêineres (Google Kubernetes Engine): sudo systemctl restart systemd-networkd
  • instâncias do Debian/Google App Engine Flex: sudo dhclient -r -v eth0 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v eth0
  • Ubuntu 15.04 e posterior: sudo dhclient -r -v ens4 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v ens4
  • Ubuntu anterior a 15.04: sudo dhclient -r -v eth0 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v eth0
  • Windows: ipconfig /renew

Alguns sistemas operacionais não alteram completamente as configurações de DNS, mesmo após a renovação da concessão de DHCP. Nesse caso, reinicie a rede da instância da VM para forçar uma alteração na configuração do DNS:

  • Ubuntu: sudo ifdown --exclude=lo -a && sudo ifup --exclude=lo -a
  • CentOS: sudo /etc/init.d/network restart
  • CoreOS: sudo systemctl restart systemd-networkd
  • SO otimizado para contêineres: sudo systemctl restart systemd-networkd

Se o aplicativo é executado em contêineres, no Kubernetes Engine ou no ambiente flexível do App Engine, talvez a configuração do DNS não seja atualizada automaticamente nas configurações dos contêineres. Nesse caso, será necessário reiniciar os contêineres. Para desativar o DNS por zona nos aplicativos em contêineres, defina VmDnsSetting=GlobalOnly nos projetos e nas instâncias e reinicie os contêineres, para que as configurações de DNS voltem ao estado original.

Próximas etapas

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine