DNS interno

As redes de nuvem privada virtual no Google Cloud têm um serviço DNS interno que permite às instâncias na mesma rede acessar umas às outras usando nomes de DNS interno. Os registros A internos para instâncias de máquina virtual (VM, na sigla em inglês) são criados em uma zona DNS para .internal. Os registros PTR para instâncias de VM são criados em zonas reversas correspondentes (em inglês). Conforme você gerencia suas instâncias, o Google Cloud cria, atualiza e remove automaticamente esses registros DNS.

Por exemplo, ao excluir uma instância, o Google Cloud automaticamente remove os registros A e PTR associados ao seu nome de DNS .internal. Se você criar uma instância com o mesmo nome, o Google Cloud criará um registro para a substituição.

Sobre o DNS interno

Os nomes de DNS interno 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 de DNS internos não podem ser usados para se conectar aos endereços IP externos de uma instância.

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

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

Registros PTR e DNS interno

O serviço de DNS interno do Google Cloud cria automaticamente registros PTR para VMs nas seguintes zonas reversas:

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa., 17.172.in-addr.arpa., ... até 31.172.in-addr.arpa.

DNS interno e Cloud DNS

O DNS interno e o Cloud DNS são ofertas diferentes.. Os nomes de DNS interno são aqueles que o Google Cloud cria automaticamente. Se você precisar criar nomes de DNS personalizados para suas instâncias de VM, poderá usar uma zona particular do Cloud DNS.

Para informações sobre como criar registros PTR personalizados que substituem os nomes de PTR de DNS interno criados automaticamente, consulte Como usar registros PTR em zonas privadas.

Nomes de host personalizados

É possível especificar um nome de host personalizado para uma VM no momento da criação. Os nomes de host personalizados atribuídos dessa maneira não são resolvidos pelo DNS interno. Com nomes de host personalizados, você ainda precisa criar um registro DNS correspondente na zona apropriada (por exemplo, usando o Cloud DNS). Para mais informações, consulte como criar uma instância de VM com um nome de host personalizado.

Tipos de nomes de DNS interno

O Google Cloud tem dois tipos de nomes de DNS interno. O tipo de DNS interno padrão é definido com base na ativação da API Compute Engine.

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 Compute Engine antes de 06 de setembro de 2018.

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.

Para informações sobre como controlar o tipo de nome DNS interno usado no nível do projeto ou da instância, consulte como configurar nomes de DNS para seu projeto ou instâncias .

Nomes de DNS internos e VPC compartilhada

Você pode usar um nome DNS interno para se referir ao endereço IP interno de uma instância mesmo quando esse endereço IP estiver localizado em uma rede VPC compartilhada em um projeto de host . Com a VPC compartilhada, a parte do ID do projeto do nome DNS interno por zona ou global (todo o projeto) é o ID do projeto de serviço.

Como determinar um nome de DNS interno para uma instância

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

  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 servidor de nomes resolver para consultas DNS emitidas pela VM. O servidor de metadados resolve todas as consultas de DNS, tanto para nomes de DNS internos quanto para nomes de DNS externos. Para consultas externas de DNS, o servidor de metadados transmite solicitações para os servidores de nome público do Google.

No exemplo a seguir, ping é usado 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 em resolv.conf. As instâncias do Compute Engine estão configuradas para renovar as concessões de DHCP a cada 24 horas. Para instâncias ativadas para DNS por zona, a concessão de DHCP expira a cada hora. A renovação do DHCP substitui o arquivo, desfazendo todas alterações que você fez. Instâncias usando DNS por zona têm entradas zonais e globais no campo resolv.conf arquivo.

DNS por zona

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

Arquivo dhcp.lease de amostra 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 a instância está localizada.
  • [PROJECT_ID] é o projeto que contém a instância.

DNS global

Arquivo resolv.conf de amostra 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.

Arquivo dhcp.lease de amostra 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 para que o número total de entradas seja maior que seis, as regras de pesquisa após a sexta entrada não serão aplicadas por seu sistema operacional. Isso pode fazer com que a funcionalidade do Compute Engine pare de funcionar, como o acesso a instâncias por meio dos nomes de instância.
  • 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, várias distribuições Linux permitem que os itens sejam prefixados ou anexados à política DHCP (em inglês).

Debian 9

Arquivo /etc/dhcp/dhclient.conf de amostra:

# 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 seu 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 em um local funcionam independentemente de outros locais, permitindo que você crie mais aplicativos multirregionais tolerantes a falhas com melhores características de disponibilidade.

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

Como configurar nomes de DNS para projetos ou instâncias

Ative os caminhos de DNS e de DNS global nas suas instâncias definindo a variável VmDnsSetting nos metadados do projeto ou da instância. Se você definir a variável VmDnsSetting nos metadados de uma instância específica, ela substituirá todas as variáveis VmDnsSetting herdadas dos metadados do projeto para essa instância.

A variável VmDnsSetting é compatível com as seguintes configurações:

  • Definir VmDnsSetting=ZonalOnly para que as instâncias sejam endereçáveis somente pelos nomes de DNS zonais. As instâncias manterão os caminhos de busca global e por zona, mas os nomes de DNS globais deixarão de funcionar. Outras instâncias podem endereçar instâncias com essa configuração usando apenas seus nomes de DNS por zona e não podem abordar essas instâncias usando seus nomes de DNS globais ou caminhos de pesquisa. Essa é a opção preferida, desde que seus aplicativos possam ser compatíveis. Essa é a configuração padrão para instâncias em projetos independentes e naqueles criados em uma organização que ativou a API 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 desse projeto não será alterado.
  • Definir VmDnsSetting=ZonalPreferred para ativar caminhos de pesquisa de DNS por zona, mantendo o nome DNS global. As instâncias com essa configuração podem fazer referência a outras usando nomes de DNS globais ou por zona. Além disso, elas continuarão a fazer referência às instâncias configuradas somente com nomes de DNS globais.
  • Definir 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 de 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 de DNS padrão dele não será alterado.

Para informações sobre como definir metadados de projeto ou valores de metadados de instâncias, consulte Configuração de metadados personalizados .

Depois de configurar a variável VmDnsSetting para uma instância, atualize a concessão de DHCP na instância. Para isso, reinicie a instância, aguarde até que o lease 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 apps atuais para nomes de DNS por zona

Embora os projetos atuais possam continuar usando nomes de DNS globais, é melhor migrar suas instâncias e aplicativos atuais para usar nomes de DNS por zona e conseguir os benefícios do sistema DNS por zona. Em geral, use o seguinte processo de migração:

  1. Verifique os apps e atualize-os para solucionar problemas de compatibilidade com as configurações somente por zona:
    • Aplicativos que abrangem instâncias pelo nome da instância ou nomes globais de domínio totalmente qualificados : nomes de instâncias e nomes de instâncias globais nem sempre são resolvidos em um ambiente somente por zona. Como um prática recomendada, atualize esses nomes para usar nomes de domínio totalmente qualificados por zona.
    • Aplicativos que pressupõem um formato global de nome de domínio totalmente qualificado: 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 que você projete seus aplicativos para funcionar independentemente do formato do nome de domínio.
    • Aplicativos que não esperam alterações no nome do domínio: alguns aplicativos não esperam alterações no nome do domínio e exigem uma reinicialização completa antes de pegar os novos nomes. Se possível, atualize seus apps para identificar e lidar com alterações no nome de domínio da instância.
  2. Configure instâncias na sua rede VPC interna para usar a configuração VmDnsSetting=ZonalPreferred, que usa nomes de DNS globais e por zonas. Essa fase de transição permite que instâncias continuem usando nomes globais até que seus aplicativos estejam prontos para usar apenas nomes por zonas:
    1. Ative VmDnsSetting=ZonalPreferred em uma instância definindo esse valor em metadados personalizados .
    2. Atualize a concessão de DHCP nessa instância, de modo 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 apps na instância para garantir que eles funcionem conforme o esperado. Alguns aplicativos podem não esperar alterações no nome do domínio e exigir uma reinicialização completa antes de usar os novos nomes.
    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 funcionem conforme o esperado usando apenas os nomes de DNS por zona. Outra opção é definir VmDnsSetting=ZonalPreferred nos metadados do projeto para configurar cada instância no seu projeto para usar nomes de DNS por zonas.
  3. Depois que seus aplicativos forem executados adequadamente usando apenas nomes de domínio por zonas com o VmDnsSetting=ZonalPreferred configuração, desative nomes globais nessa rede VPC. Configure instâncias na sua rede interna de nuvem privada virtual para usar a configuração VmDnsSetting=ZonalOnly , que usa apenas os nomes de DNS por zona:
    1. Ative VmDnsSetting=ZonalOnly em uma instância definindo esse valor em metadados personalizados .
    2. Atualize a concessão de DHCP nessa instância, de modo 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 apps na instância para garantir que eles funcionem conforme o esperado.
    4. Repita esse processo para ativar VmDnsSetting=ZonalOnly e atualize o lease de DHCP nas instâncias restantes na rede VPC até que todas funcionem conforme o esperado usando apenas os nomes de DNS por zona.
  4. Repita esse processo em cada uma das suas redes de nuvem privada virtual até que todas as instâncias em seu projeto usem a VmDnsSetting=ZonalOnly configuração. É possível definir VmDnsSetting=ZonalOnly nos metadados do projeto para que eles sejam aplicados automaticamente às instâncias criadas nesse projeto.

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 da instância. Para desativar o DNS por zona em um projeto, defina VmDnsSetting=GlobalOnly nos metadados do projeto e certifique-se de que nenhuma das suas instâncias esteja configurada individualmente com o valor VmDnsSetting. Para informações sobre como definir metadados de projeto ou valores de metadados de instâncias, consulte Configuração de metadados personalizados .

Para forçar a atualização do lease do DHCP imediatamente, use um dos seguintes comandos:

  • Container-optimized OS (Google Kubernetes Engine): sudo systemctl restart systemd-networkd
  • Instâncias do ambiente flexível Debian/app Engine: 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 à 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 do lease 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
  • Container-optimized OS: sudo systemctl restart systemd-networkd

Se você executar o aplicativo em contêineres, no Google Kubernetes Engine ou no ambiente flexível do App Engine, a configuração de DNS nas suas configurações de contêiner poderá não ser atualizada automaticamente até a reinicialização dos contêineres. Para desativar o DNS por zona nesses aplicativos de contêiner, você precisa definir VmDnsSetting=GlobalOnly nos seus projetos e instâncias e reiniciar os contêineres para que suas configurações de DNS voltem ao estado original.

A seguir

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

Enviar comentários sobre…

Documentação do Compute Engine