Visão geral do DNS interno

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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

OGoogle Cloud cria, atualiza e remove automaticamente os seguintes tipos de registros DNS à medida que você gerencia suas instâncias:

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

Por exemplo, quando você exclui uma instância,o Google Cloud remove automaticamente os registros A e PTR associados ao nome de DNS interno. Se você criar uma instância com o mesmo nome,o Google Cloud cria novos registros para a substituição.

Limitações

• O Compute Engine cria registros A e PTR de nome DNS interno apenas para o endereço IPv4 interno principal da interface de rede nic0 de uma instância. Consequentemente, o tipo de pilha da interface de rede nic0 precisa ser somente IPv4 ou de pilha dupla. O DNS interno não oferece suporte a interfaces de rede somente IPv6 (Pré-lançamento).

• O Compute Engine não cria registros DNS internos para os seguintes casos:

  • O endereço IPv4 interno principal de uma interface de rede diferente de nic0.
  • Um endereço IPv4 externo de qualquer interface de rede.
  • Um endereço IPv4 interno de um intervalo de IP de alias de qualquer interface de rede.
  • Um intervalo de endereços IPv6 interno ou externo de qualquer interface de rede.

• A resolução de nomes DNS internos exige que a VM cliente e a VM associada ao registro DNS interno sejam:

  • Na mesma rede VPC.
  • No mesmo projeto (exceto em alguns cenários de VPC compartilhada).

  Para mais informações sobre cenários de VPC compartilhada, consulte Nomes DNS internos e VPC compartilhada.

Nomes DNS internos globais e zonais

OGoogle Cloud tem dois tipos de nomes de DNS internos:

• DNS zonal: os nomes de instância precisam ser exclusivos em cada zona, mas podem ser reutilizados entre as zonas. Por exemplo, é possível ter várias instâncias chamadas instance-1, desde que estejam em zonas diferentes.
• DNS global: os nomes das instâncias precisam ser exclusivos em cada projeto. Com o DNS global, não é possível reutilizar nomes de instâncias 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 instância precisa ser exclusivo em todo o projeto. Por esse motivo, não é possível criar novas instâncias em nenhuma região com falhas no plano de controle em que você tenha ou tenha tido recursos do projeto. 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.

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

Substitua:

• INSTANCE_NAME: o nome da instância. 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 Configurar nomes de DNS para o projeto ou para instâncias.

Resolução de nomes DNS

As instâncias recebem informações de resolução de DNS interno como parte das concessões de DHCP. O método de resolução de DNS depende da plataforma do sistema operacional:

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

Zonas reversas para registros PTR

O serviço de DNS interno doGoogle Cloudcria automaticamente registros PTR para instâncias 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

A VM cliente e a VM associada ao registro DNS interno podem estar localizadas em projetos separados, mas precisam usar a mesma rede VPC compartilhada. Por exemplo, o cliente pode estar localizado em um projeto de serviço, e a VM associada ao registro DNS interno pode estar localizada em um projeto de serviço diferente ou no projeto host.

Os clientes precisam emitir consultas de nome de domínio totalmente qualificado (FQDN) para registros DNS internos em vez de depender de consultas parciais e domínios de pesquisa DNS. Os domínios de pesquisa do DNS são diferentes em cada projeto por motivos como estes:

• A parte do nome de domínio de cada registro A do DNS interno contém o ID do projeto que contém a VM. Para uma VM em um projeto de serviço cuja interface de rede nic0 usa uma rede VPC compartilhada, o projeto da VM é diferente do projeto que contém a rede.

• A escolha de usar nomes DNS internos zonais ou globais (em todo o projeto) depende da configuração do projeto que contém a VM.

Para mais informações sobre a VPC compartilhada, consulte:

• Visão geral de VPC compartilhada
• Provisionar VPC compartilhada

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 particular do Cloud DNS para criar entradas DNS personalizadas para suas instâncias. É possível configurar registros PTR que permitem substituir o URL de DNS interno padrão da instância 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 instâncias, consulte Criar um registro PTR para uma instância.

Nomes de host personalizados

É possível especificar um nome de host personalizado para uma instância ao criá-la. 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 criar uma instância com um nome de host personalizado.

DHCP e DNS interno

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. As instâncias que usam DNS por zona 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 período de concessão de DHCP de 24 horas expirar na instância. 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. Por exemplo, para o Red Hat Enterprise Linux para SAP com HA e Update Services 8.6, use o seguinte link: Configurar manualmente o arquivo /etc/resolv.conf

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 por zona no arquivo /etc/systemd/resolved.conf.

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 instâncias usando os 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 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.

# 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

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

# 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

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

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 informações sobre Google Cloud redes VPC, 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.