DNS interno

Linux Windows

---

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

Por exemplo, ao excluir uma VM, o Google Cloud automaticamente remove os registros A e PTR associados do nome DNS .internal. Se você criar uma VM 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 VM somente aponta para o endereço IP interno principal dela. Nomes DNS internos não podem ser usados para conexão com os endereços IP externos de uma VM.

• Os nomes 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 VMs que estão na mesma rede. Essas VMs podem estar no mesmo projeto da rede ou em projetos de serviço que usam a mesma rede VPC compartilhada. Para resolver nomes de DNS de VMs em projetos de serviço, use os FQDNs das VMs. Não é possível usar o DNS interno para conectar VMs que estejam em uma rede diferente.

Tipos de nomes DNS internos

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.

Em geral, o Google recomenda fortemente que você use o DNS zonal, porque ele oferece garantias de confiabilidade mais alta ao isolar falhas no registro de DNS para zonas individuais.

Tipo de DNS interno	Nome de domínio totalmente qualificado (FQDN)	Tipo padrão do projeto	Observações
DNS por zona	VM_NAME.ZONE.c.PROJECT_ID.internal	Padrão para todas as organizações ou projetos independentes que ativaram a API Compute Engine após 06 de setembro de 2018.	Os nomes de VM precisam ser exclusivos em cada zona. No entanto, com o DNS por zona, é possível reutilizar nomes de VM entre as zonas. Por exemplo, é possível ter várias VMs chamadas instance-1, desde que as VMs estejam em zonas diferentes.
DNS global (em todo o projeto)	VM_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.	Os nomes de VM precisam ser exclusivos no projeto. Com o DNS global, não é possível reutilizar nomes de VM no projeto.

Substitua:

• VM_NAME: o nome da VM. Para DNS por zona, esse valor precisa ser exclusivo na zona, mas pode ser repetido entre elas. Para DNS global, o nome da VM precisa ser exclusivo em todo o projeto.
• ZONE: a zona em que a instância está localizada.
• PROJECT_ID: o projeto que contém a VM.

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 .

Observação: migrar um projeto para uma organização diferente não altera o tipo de DNS interno padrão da instância.

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.

Registros personalizados com o Cloud DNS

Use uma zona privada do Cloud DNS para criar entradas DNS personalizadas para as VMs. É possível configurar registros PTR que permitem substituir o URL de DNS interno padrão da VM pelo URL personalizado fornecido.

Para criar registros PTR personalizados que substituem os nomes de PTR de DNS interno criados automaticamente, consulte Registros PTR para endereços RFC 1918 em zonas particulares.

Observação: os nomes DNS internos são diferentes dos registros personalizados criados através do Cloud DNS. Os registros DNS internos são criados automaticamente e não podem ser alterados.

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.

Nomes DNS internos e VPC compartilhada

É possível usar um nome DNS interno para se referir ao endereço IP interno de uma VM, mesmo quando ele 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.

Determinar o nome DNS interno de uma VM

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

1. Conecte-se à VM.

2. Consulte os metadados hostname:

   VMs do Linux

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

   VM do Windows

   Invoke-RestMethod `
     -Headers @{"Metadata-Flavor" = "Google"} `
     -Uri "http://metadata.google.internal/computeMetadata/v1/instance/hostname"
   

O servidor de metadados retorna o nome do host da VM em um dos seguintes formatos e mostra o tipo de nome DNS interno que a VM usa:

• DNS por zona: VM_NAME.ZONE.c.PROJECT_ID.internal
• DNS global: VM_NAME.c.PROJECT_ID.internal

Na saída:

• VM_NAME: o nome da VM
• ZONE: é a zona em que a VM está localizada
• PROJECT_ID: o projeto que contém a VM.

Acessar VMs por 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.

Importante: as instâncias do Compute Engine recebem informações de resolução de DNS interno como parte das concessões de DHCP. No Linux, por padrão, o servidor de metadados da VM (169.254.169.254) aponta nomes DNS internos. No Windows, por padrão, o gateway padrão da sub-rede aponta nomes de DNS internos. Se você alterar a configuração do servidor de nomes da instância, não será possível apontar registros no DNS interno do Compute Engine (a zona .internal) ou nas zonas particulares gerenciadas, zonas de encaminhamento e zonas de peering do Cloud DNS, a menos que o servidor DNS de substituição encaminhe essas consultas para o servidor de metadados do Linux ou para o gateway padrão do Windows.

O exemplo a seguir usa ping para conectar uma VM 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 VM_NAME.ZONE.c.PROJECT_ID.internal -c 1

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

Substitua:

• VM_NAME: o nome da VM
• ZONE: é a zona em que a VM está localizada
• PROJECT_ID: o projeto que contém a VM.

DHCP e DNS interno

As VMs do Compute Engine estão configuradas para renovar as concessões de DHCP a cada 24 horas. Para VMs ativadas para DNS por zona, a concessão de DHCP expira a cada hora. As VMs que usam DNS zonal têm entradas globais e zonais no arquivo de configuração DHCP.

Por padrão, a maioria das distribuições Linux armazena informações de DHCP em resolv.conf. Editar manualmente resolv.conf faz com que ele seja revertido para o DHCP padrão sempre que o lease de DHCP expirar na VM. 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.

A forma de modificação da política ou do arquivo de configuração do DHCP depende da distribuição do Linux usada. Por exemplo, o Red Hat Enterprise Linux e o Debian usam o arquivo de configuração /etc/dhcp/dhcpd.conf. No CentOS, você usa o utilitário de linha de comando do Gerenciador de rede, nmcli.

Consulte a documentação do sistema operacional para mais informações sobre como definir configurações personalizadas de rede DNS e DHCP.

Exemplo de arquivo resolv.conf:

Por padrão, a maioria das distribuições Linux armazena informações de DHCP em resolv.conf. systemd-resolved também fornece serviços de resolvedor para DNS. É possível configurar esse resolvedor editando o arquivo /etc/systemd/resolved.conf e outros arquivos *.conf em /etc/systemd/resolved.conf.d/. Em distribuições Linux que armazenam informações de DHCP em resolved.conf, é possível visualizar entradas DNS globais e por zona no arquivo /etc/systemd/resolved.conf.

Observação: ao visualizar o arquivo resolv.conf, verifique se ele foi atualizado para a versão mais recente. Para fazer isso, pode ser necessário atualizar a concessão de DHCP ou reiniciar a pilha da rede, dependendo do sistema operacional que a VM usa.

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 pelo seu sistema operacional. Isso pode fazer com que a funcionalidade do Compute Engine pare de funcionar, como o acesso a VMs por meio dos nomes de instância.

• Editar manualmente o arquivo resolv.conf faz 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 VM. No caso de VMs 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.

Configuração de DNS zonal

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

Substitua:

• ZONE: a zona em que a VM está localizada
• PROJECT_ID: o projeto que contém a imagem.

Amostra 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 "VM_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;
}

Substitua:

• VM_NAME: O nome da VM.
• ZONE: a zona em que a VM está localizada.
• PROJECT_ID: o projeto que contém a imagem.

Configuração de 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

Substitua PROJECT_ID pelo projeto a que a VM pertence.

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 "VM_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;
}

Substitua:

• VM_NAME: O nome da VM.
• PROJECT_ID: o projeto que contém a imagem.

Exemplo de arquivo dhclient.conf:

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;

Neste exemplo, 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 VM, 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 VM 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 para isolamento regional e melhor confiabilidade multirregional.

Configurar nomes DNS para projeto ou VMs

Ative o DNS por zona e o DNS global para as VMs definindo a variável VmDnsSetting nos metadados do projeto ou da VM. Se você definir a variável VmDnsSetting nos metadados de uma VM específica, ela substituirá todas as variáveis VmDnsSetting herdadas dos metadados do projeto para essa VM.

Observação: a definição do valor de metadados VmDnsSetting envolvidos no projeto afeta VMs de outros serviços do Google Cloud, como Google Kubernetes Engine, ambiente flexível do App Engine, Cloud SQL, Dataproc e contêineres em execução no Compute Engine. Atualize os apps para usar nomes de DNS por zona para esses serviços, além das VMs do Compute Engine.

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

• Recomendação: definir VmDnsSetting=ZonalOnly para que as VMs sejam endereçáveis somente pelos nomes DNS por zona. As VMs manterão os caminhos de busca global e por zona, mas os nomes DNS globais deixarão de funcionar. Outras VMs podem lidar com VMs com essa configuração usando apenas os nomes DNS por zona e não podem abordar essas VMs usando os nomes DNS globais ou os caminhos de pesquisa. Essa é a opção preferencial e mais confiável, contanto que seus apps possam ser compatíveis. Essa é a configuração padrão para VMs em projetos independentes e naqueles criados em uma organização que ativou a API Compute Engine depois de 06 de setembro de 2018.
• Defina VmDnsSetting=GlobalDefault para que as VMs registrem nomes DNS globais e por zona, mas use apenas nomes globais como nomes de domínio padrão e entradas de caminho de pesquisa. Essa é a configuração padrão para VMs em projetos independentes e naqueles criados em uma organização que ativou a API Compute Engine antes de 06 de setembro de 2018.

Migrar um projeto para uma organização diferente não altera o nome DNS padrão do projeto.

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

Depois de configurar a variável VmDnsSetting para uma VM, atualize a concessão de DHCP na VM. Para isso, reinicie a VM, aguarde até que a concessão expire ou execute um dos seguintes comandos:

• VMs do Linux: sudo dhclient -v -r
• VMs do Windows Server: ipconfig /renew

Depois de atualizar o lease de DHCP, verifique se a VM está ativada para DNS por zona.

Aplicar DNS zonal somente por padrão em projetos novos/futuros

Em comparação com o DNS global interno, o DNS interno interno oferece maior confiabilidade ao isolar falhas no registro DNS de zonas individuais. O Google recomenda a troca para o DNS zonal sempre que possível.

Se um novo projeto for criado em uma organização criada antes de 6 de setembro de 2018, por padrão, o tipo de DNS interno do projeto ainda será DNS global. Para evitar os riscos de confiabilidade relacionados ao DNS global, você pode aplicar a política da organização booleana constraints/compute.setNewProjectDefaultToZonalDNSOnly em um nível de organização ou pasta. Quando você define essa política para substituir a configuração de DNS padrão, os projetos recém-criados usarão o DNS zonal interno por padrão. Mas a política não afeta os projetos atuais em que a API Compute Engine já está ativada. Para alternar projetos atuais para que usem DNS por zona, consulte Como alternar projetos atuais para o DNS zonal.

Para aplicar essa alteração de política, é preciso ter acesso no nível da pasta ou da organização com o papel do IAM roles/orgpolicy.policyAdmin.

Siga os seguintes passos para definir a política da organização para uma pasta ou organização:

1. Faça login no console do Google Cloud como superadministrador do Google Workspace ou do Cloud Identity.

2. No console, acesse a página Políticas da organização.

   Acessar as políticas da organização

3. Selecione a pasta ou a organização que contém as políticas da organização que você quer visualizar. Uma lista de restrições de política da organização disponíveis é exibida em uma ou mais páginas.

4. Para encontrar a política para aplicar DNS por zona, clique em Filtrar e selecione Nome. Em seguida, defina o nome do filtro como Define a configuração de DNS interno para novos projetos somente para DNS por zona.

5. Clique no nome da política para ver os detalhes dela.

6. A página de detalhes da política fornece informações sobre a restrição e como a restrição é aplicada no momento. Por padrão, a aplicação é indefinida para uma pasta ou organização. No entanto, se uma pasta pai tiver uma aplicação definida, ela será herdada da pasta mãe mais próxima que tem uma aplicação definida. Para mais informações, consulte Noções básicas sobre a avaliação da hierarquia.

7. Para personalizar a política da organização, clique em Editar.

8. Na página de edição, selecione Personalizar.

9. Em Aplicação, selecione uma opção para aplicação:

   • Para aplicar a restrição, selecione Ativado. Para novos projetos, o tipo DNS interno padrão será o DNS zonal.
   • Para desativar a restrição, selecione Desativado. O tipo de DNS padrão do projeto ainda é determinado pelo horário de criação da organização.

10. Clique em Save.

Para validar a alteração da política da organização, crie um novo projeto na pasta ou organização, depois crie e inicie uma instância de VM e verifique se a VM está ativada para DNS por zona.

Se o DNS global interno for necessário para resolver uma consulta de nome DNS integrada à carga de trabalho, é possível reverter essa alteração no nível da organização ou da pasta desativando a aplicação.

Como alternar projetos existentes para nomes DNS por zona

Observação: a ativação de nomes DNS por zona em todo o projeto aplica configurações de DNS por zona às VMs nos seguintes serviços: ambiente flexível do App Engine, Google Kubernetes Engine, Cloud SQL, Dataproc, Dataflow e Cloud Functions. Verifique se os apps podem resolver problemas de compatibilidade com as configurações somente por zona.

O DNS global foi substituído pelo DNS por zona como o tipo de DNS interno padrão para todas as novas organizações integradas ao Google Cloud após 6 de setembro de 2018. Se os projetos atuais ainda estiverem usando o DNS global, o Google recomenda que você mude esses projetos para usar nomes DNS zonais internos. O DNS zonal reduz o risco de interrupções entre regiões.

Em geral, use o seguinte processo de migração:

Observação: se uma VM com Linux ou Unix já tiver seis domínios no caminho de pesquisa (execute cat /etc/resolv.conf), verifique se ela está em execução com a versão glibc 2.26 ou mais recente (uma maneira de verificar a versão da glibc é executar ldd --version) Os clientes do DHCP com glibc 2.25 e anteriores são compatíveis apenas com até seis domínios de pesquisa. Portanto, pode haver o risco de descartar um domínio de pesquisa atual.

1. Verifique os aplicativos e atualize-os para solucionar problemas de compatibilidade com as configurações somente por zona:
   • Se você tiver qualquer app que use nomes de DNS globais codificados, corrija-os para usar nomes de DNS internos zonais.
   • Se os nomes de VM forem usados para acessar VMs de outra zona, verifique se o nome da zona de destino foi adicionado à consulta. Por exemplo: <DESTINATION_VM_NAME>.<DESTINATION_ZONE_NAME>.
   • Para resolver nomes de DNS de VMs em projetos de serviço usando uma rede VPC compartilhada, use os nomes de domínio totalmente qualificados por zona das VMs.
2. Para alternar o projeto para usar DNS interno interno, defina VmDnsSetting=ZonalOnly nos metadados do projeto.

Para testar se os metadados do projeto foram atualizados, execute gcloud compute project-info describe --flatten="commonInstanceMetadata[VmDnsSetting]". O comando retornará ZonalOnly.

Reverter para o DNS global no projeto ou em VMs

Para reverter para DNS global em uma VM específica, adicione o seguinte aos metadados da VM: VmDnsSetting=GlobalDefault.

Para reverter para o DNS global de um projeto, adicione o seguinte aos metadados do projeto: VmDnsSetting=GlobalDefault. Além disso, verifique se nenhuma das VMs está configurada individualmente com o valor de metadados VmDnsSetting. Para informações sobre como definir metadados de projeto ou valores de metadados de VM, consulte Configuração de metadados personalizados.

Para forçar a alteração da configuração de DNS, reinicie a rede da VM:

• Container-optimized OS/Ubuntu: sudo systemctl restart systemd-networkd
• CentOS/RHEL/Fedora CoreOS/Rocky Linux: sudo systemctl restart network
• Debian: sudo systemctl restart networking
• Windows: ipconfig /renew

Se você executar seu 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é que você reinicie os contêineres. Para desativar o DNS por zona nesses aplicativos de contêiner, é preciso definir VmDnsSetting=GlobalDefault nos projetos e nas VMs e reiniciar os contêineres para que as configurações do DNS voltem ao estado original.

A seguir

• Para mais informações sobre as redes VPC do Google Cloud, consulte a Visão geral da VPC.
• Para obter informações sobre como criar e modificar redes VPC, consulte usando VPC .