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 na zona, mas podem ser repetidos 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. Não é possível repetir nomes de instâncias.

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 da rede pode ser definida como 1500 bytes. Consulte Unidade de transmissão máxima para saber mais sobre MTUs de rede em segundo plano.

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

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=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 umas às 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. Essa opção pode ser usada como uma etapa intermediária para tentar testar nomes de DNS por zona.
  • 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.

Como migrar aplicativos existentes para nomes de DNS por zona

O DNS global foi substituído pelo DNS por zona. Se os projetos atuais ainda estiverem usando o DNS global, recomendamos que você migre as instâncias e os aplicativos atuais para usar nomes DNS zonais. Os nomes de DNS por zona reduzem o risco de interrupções entre egionais.

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 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 aplicativos para identificar e lidar com alterações no nome de domínio da instância.
  2. Após a execução correta dos aplicativos usando somente os nomes de domínio zonais, é possível desativar os nomes globais na 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 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.
  3. 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 zonal 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 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 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=GlobalOnly 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 .