Visão geral do DNS interno

Linux Windows

---

Quando você cria instâncias de máquina virtual (VM) do Compute Engine, o DNS interno cria automaticamente um nome DNS para a VM. Esse nome DNS facilita a comunicação interna de VM para VM ao resolver endereços IP internos. As redes de nuvem privada virtual no Google Cloud usam o serviço de DNS interno para permitir que as VMs na mesma rede acessem umas às outras usando nomes DNS internos.

O Google Cloud cria, atualiza e remove automaticamente os seguintes tipos de registros DNS à medida que você gerencia suas VMs:

• Os registros de endereço DNS, ou registros A, são criados para VMs em uma zona de DNS para .internal.
• Os registros PTR para VMs, usados na busca DNS reversa, são criados em zonas reversas correspondentes.

Por exemplo, quando você exclui uma VM, o Google Cloud remove automaticamente os registros A e PTR associados do nome DNS interno. Se você criar uma VM com o mesmo nome, o Google Cloud criará um novo registro para a substituição.

Limitações

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 resolução em 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.

Nomes DNS internos globais e zonais

O Google Cloud tem dois tipos de nomes DNS internos:

• DNS zonal: os nomes de VMs precisam ser exclusivos em cada zona, mas podem ser reutilizados entre as zonas. Por exemplo, é possível ter várias VMs chamadas instance-1, desde que elas estejam em zonas diferentes.
• DNS global: os nomes das VMs precisam ser exclusivos em cada projeto. Com DNS global, não é possível reutilizar nomes de VMs no projeto.

O Google recomenda fortemente que você use o DNS zonal, porque ele oferece confiabilidade mais alta ao isolar falhas no registro de DNS para zonas individuais. No caso de uma interrupção, o DNS global tem os seguintes problemas:

• O nome da VM precisa ser exclusivo em todo o projeto. Por esse motivo, não é possível criar novas VMs em nenhuma região com falhas no plano de controle em que você tenha ou teve recursos do projeto. O Google Cloud não pode verificar os nomes DNS de recursos existentes na região indisponível.
• Alguns recursos do Compute Engine não estão disponíveis, como o escalonamento automático de grupos gerenciados de instâncias (MIGs). Como resultado, os aplicativos que usam o escalonamento automático para lidar com os aumentos de carga de trabalho não podem ser escalonados verticalmente.

O tipo de DNS interno padrão é definido quando você ativa a API Compute Engine.

• O tipo de DNS interno padrão é o DNS zonal.
• Se a API Compute Engine foi ativada na organização ou no projeto independente antes de 6 de setembro de 2018, o tipo de DNS interno padrão é definido como DNS global.

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

Os nomes de domínio totalmente qualificados para nomes DNS internos estão descritos na tabela a seguir.

Tipo de DNS interno	Nome de domínio totalmente qualificado (FQDN)
DNS por zona	VM_NAME.ZONE.c.PROJECT_ID.internal
DNS global (em todo o projeto)	VM_NAME.c.PROJECT_ID.internal

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 Configurar nomes de DNS para o projeto ou para instâncias.

Resolução de nomes DNS

As VMs recebem informações de resolução de DNS interno como parte dos leases de DHCP. O método de resolução de DNS depende da plataforma do sistema operacional:

• Linux: por padrão, o servidor DNS da VM (169.254.169.254:53) resolve nomes DNS internos.
• Windows: por padrão, o gateway padrão da sub-rede aponta nomes DNS internos.

Importante: se você alterar a configuração do servidor de nomes da VM, não será possível resolver registros no DNS interno do Compute Engine (a zona .internal) ou nas zonas particulares gerenciadas, nas zonas de encaminhamento e nas 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.

Zonas reversas para registros PTR

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.

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 zonal ou global (todo o projeto) é o ID do projeto de serviço.

Como personalizar nomes DNS internos

Algumas organizações ou aplicativos podem exigir nomes DNS internos personalizados em vez dos nomes DNS internos padrão criados pelo Google Cloud.

Zonas particulares e 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 do DNS interno padrão da VM pelo URL personalizado fornecido.

Para criar registros PTR personalizados que substituem os nomes DNS de PTR internos criados automaticamente, consulte Registros PTR para endereços RFC 1918 em zonas particulares. Para informações sobre como criar registros PTR para VMs, consulte Criar um registro PTR para uma instância de VM.

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.

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. O serviço systemd-resolved também fornece serviços de resolvedor para DNS. É possível configurar esse serviço editando o arquivo /etc/systemd/resolved.conf e outros arquivos *.conf no diretório /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 zonais 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 os recursos do Compute Engine parem de funcionar, como o acesso a VMs usando os respestivos 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 VM.

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

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

Exemplo de arquivo dhclient.conf:

Alguns sistemas operacionais, como o Debian 9, usam o arquivo dhclient.conf em vez do arquivo resolv.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.

A seguir

• Para mais informações sobre as redes VPC do Google Cloud, consulte a Visão geral da VPC.
• Para informações sobre como criar e modificar redes VPC, consulte Como usar VPC.
• Migre sua organização e seus projetos para o uso do DNS zonal em vez do DNS global.