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 acessarem umas às outras usando nomes de DNS interno. Os registros A internos de instâncias de máquina virtual (VM) são criados em uma zona DNS para .internal. Os registros PTR de 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 do 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 DNS internos não podem ser usados para se conectar 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 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 das instâncias de VM precisam ser exclusivos em cada zona. No entanto, com o DNS zonal, é possível reutilizar nomes de instâncias de VM entre as zonas. Por exemplo, é possível ter várias instâncias chamadas instance-1, desde que as instâncias 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 das instâncias de VM precisam ser exclusivos no projeto. Com o DNS global, não é possível reutilizar nomes de instâncias 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 instância 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 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 .

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 suas instâncias de VM. É possível configurar registros PTR que permitem substituir o URL de VM de DNS interno padrão 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.

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

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 o nome DNS interno de uma instância de 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. conectar-se à instância de 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 instância de VM
  • ZONE: a zona em que a instância está localizada.
  • PROJECT_ID é o projeto que contém a instância

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 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 instância de VM
  • 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 arquivo resolv.conf.

Em distribuições Linux que armazenam informações de DHCP em systemd.resolved.conf, é possível visualizar entradas DNS globais e por zona no arquivo /etc/systemd/resolved.conf.

As redes VPC têm uma Unidade de transmissão máxima (MTU) padrão de 1460 bytes. No entanto, a MTU de rede pode ser definida como a MTU Ethernet padrão de 1500 bytes, até 8896 bytes para frames jumbo ou no mínimo 1300. Para mais informações sobre MTUs de rede, consulte a visão geral da unidade de transmissão máxima.

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

Substitua:

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

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.

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 ao qual a instância 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.

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

Como configurar nomes DNS para projetos ou instâncias

Ative o DNS por zona e o DNS global para 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:

  • Recomendação: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 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 preferencial e mais confiável, contanto que seus apps 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 pós 06 de setembro de 2018.
  • Defina VmDnsSetting=GlobalDefault para que as instâncias 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 instâncias 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 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

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 a página 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 uma instância de VM e verifique se sua VM está ativado 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 zonais

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:

  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 das VMs forem usados para acessar instâncias em 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.

Como reverter para DNS global em um projeto ou uma instância

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

Para reverter para o DNS global de um projeto, adicione o seguinte aos metadados do projeto: VmDnsSetting=GlobalDefault. Verifique se nenhuma das suas instâncias está configurada individualmente com o valor de metadados 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 alteração da configuração de DNS, reinicie a rede da instância de 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, você precisa definir VmDnsSetting=GlobalDefault nos projetos e nas instâncias 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 .