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. Este nome DNS facilita a comunicação interna entre instâncias, resolvendo endereços IP internos. Redes de nuvem privada virtual ativadas Google Cloud use o serviço DNS interno para permitir que instâncias de computação na mesma rede acessem umas às outras usando nomes DNS internos.

Google 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 DNS para .internal .
• Os registros PTR para instâncias, usados ​​para pesquisa reversa de DNS, são criados nas zonas reversas correspondentes.

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

Limitações

• O Compute Engine cria registros internos de nome DNS A e PTR somente para o endereço IPv4 interno principal da interface de rede nic0 de uma instância. Conseqüentemente, o tipo de pilha da interface de rede nic0 deve ser somente IPv4 ou pilha dupla. O DNS interno não oferece suporte a interfaces de rede somente IPv6 ( Preview ).

• O Compute Engine não cria registros DNS internos para o seguinte:

  • O endereço IPv4 interno primário 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 requer que a VM cliente e a VM associada ao registro DNS interno sejam:

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

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

Nomes DNS internos zonais e globais

Google Cloud tem dois tipos de nomes DNS internos:

• DNS zonal : os nomes das instâncias devem ser exclusivos em cada zona, mas você pode reutilizar nomes de instâncias entre zonas. Por exemplo, você pode ter várias instâncias denominadas instance-1 desde que elas estejam em zonas diferentes.
• DNS global : os nomes das instâncias devem ser exclusivos em cada projeto. Com o DNS global, não é possível reutilizar nomes de instâncias no projeto.

O Google recomenda fortemente o uso de DNS zonal porque oferece maior confiabilidade ao isolar falhas no registro de DNS para zonas individuais. No caso de uma interrupção, o DNS global apresenta os seguintes problemas:

• O nome da instância deve ser exclusivo em todo o projeto. Como resultado, não é possível criar novas instâncias em nenhuma região que esteja enfrentando falhas no plano de controle onde você tem ou já teve recursos de projeto. Google Cloud não é possível verificar os nomes DNS dos recursos existentes na região indisponível.
• Certos recursos do Compute Engine não estão disponíveis, como o escalonamento automático de grupos de instâncias gerenciadas (MIGs). Como resultado, seus aplicativos que usam escalonamento automático para lidar com aumentos de carga de trabalho não conseguem escalar verticalmente.

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

• O tipo de DNS interno padrão é DNS zonal.
• Se sua organização ou projeto autônomo tiver ativado a API Compute Engine antes de 6 de setembro de 2018, o tipo de DNS interno padrão será definido como DNS global.

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

Substitua o seguinte:

• INSTANCE_NAME : o nome da instância. Para DNS zonal, esse valor deve ser exclusivo na zona, mas pode ser repetido entre zonas. Para DNS global, o nome da instância deve ser exclusivo em todo o projeto.
• ZONE : a zona onde sua instância está localizada.
• PROJECT_ID : o projeto ao qual a instância pertence.

Para obter informações sobre como controlar qual tipo de nome DNS interno é usado no nível do projeto ou da instância, consulte configurar nomes DNS para seu projeto ou instâncias .

Resolução de nomes DNS

As instâncias recebem informações internas de resolução de DNS como parte de suas concessões de DHCP. O método de resolução 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 resolve nomes DNS internos.

Zonas reversas para registros PTR

Google CloudO serviço DNS interno do DNS cria 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 devem 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 devem emitir consultas de nomes de domínio totalmente qualificados (FQDN) para registros DNS internos, em vez de depender de consultas parciais e domínios de pesquisa DNS. Os domínios de pesquisa DNS são diferentes em cada projeto por motivos como os seguintes:

• A parte do nome de domínio de cada registro DNS A 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 utilização de nomes DNS internos zonais ou globais (em todo o projeto) depende da configuração do projeto que contém a VM.

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

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

Personalizando nomes DNS internos

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

Zonas privadas e registros personalizados com Cloud DNS

Você pode usar uma zona privada do Cloud DNS para criar entradas DNS personalizadas para suas instâncias. Você pode configurar registros PTR que permitem substituir o URL DNS interno padrão da sua instância pelo URL personalizado fornecido.

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

Nomes de host personalizados

Você pode 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 Cloud DNS). Para obter mais informações, consulte criar uma instância com um nome de host personalizado .

DNS interno e DHCP

As instâncias do Compute Engine são configuradas para renovar concessões de DHCP a cada 24 horas. Para instâncias habilitadas para DNS zonal, a concessão de DHCP expira a cada hora. As instâncias que usam DNS zonal têm entradas zonais e globais no arquivo de configuração DHCP.

Por padrão, a maioria das distribuições Linux armazena informações de DHCP em resolv.conf . A edição manual resolv.conf faz com que ele seja revertido para o DHCP padrão sempre que a concessão do DHCP expirar em sua instância. Para fazer modificações estáticas no arquivo resolv.conf , diversas distribuições Linux permitem que itens sejam acrescentados ou anexados à política DHCP .

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

Consulte a documentação do sistema operacional para obter informações sobre como definir configurações personalizadas de rede DHCP e DNS. Por exemplo, para Red Hat Enterprise Linux para SAP com HA e Update Services 8.6, use o seguinte link: Configurando 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 resolução para DNS. Você pode configurar esse serviço editando o arquivo /etc/systemd/resolved.conf e outros arquivos *.conf no diretório /etc/systemd/resolved.conf.d/ . Nas distribuições Linux que armazenam informações de DHCP resolved.conf , você pode visualizar entradas DNS zonais e globais no arquivo /etc/systemd/resolved.conf .

Esses arquivos têm as seguintes restrições:

• O caminho de pesquisa pode lidar com apenas seis registros, e três deles são fornecidos pelo Compute Engine. Se você adicionar entradas ao caminho de pesquisa de forma que o número total de entradas seja maior que 6, as regras de pesquisa após a ^6ª entrada não serão aplicadas pelo seu sistema operacional. Isso pode fazer com que os recursos do Compute Engine parem de funcionar, como acessar instâncias usando seus nomes de instância.

• A edição manual resolv.conf faz com que ele seja revertido para o DHCP padrão sempre que a concessão de DHCP de 24 horas expirar em sua instância. Em instâncias que usam DNS zonal, a concessão de DHCP expira a cada hora. Para fazer modificações estáticas no arquivo resolv.conf , diversas distribuições Linux permitem que itens sejam acrescentados 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 .

Exemplo de arquivo /etc/dhcp/dhclient.conf :

# 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 seu servidor DNS.

O que vem a seguir

• Para informações sobre Google Cloud Redes VPC, consulte a visão geral do VPC .
• Para obter informações sobre como criar e modificar redes VPC, consulte Usando VPC .
• Migre sua organização e seus projetos para usar DNS zonal em vez de DNS global .