Opções de Resolução de Nomes DNS para máquinas virtuais Linux no Azure

Aplica-se a: ✔️ Linux VMs ✔️ Conjuntos de escala flexível

O Azure fornece resolução de nomes DNS por padrão para todas as máquinas virtuais que estão em uma única rede virtual. Você pode implementar sua própria solução de resolução de nomes DNS configurando seus próprios serviços DNS em suas máquinas virtuais que o Azure hospeda. Os cenários a seguir devem ajudá-lo a escolher o que funciona para sua situação.

• Resolução de nomes que o Azure fornece
• Resolução de nomes usando seu próprio servidor DNS

O tipo de resolução de nomes que você usa depende de como suas máquinas virtuais e instâncias de função precisam se comunicar entre si.

A tabela a seguir ilustra cenários e soluções de resolução de nomes correspondentes:

Resolução de nomes que o Azure fornece

Juntamente com a resolução de nomes DNS públicos, o Azure fornece resolução de nomes interna para máquinas virtuais e instâncias de função que estão na mesma rede virtual. Em redes virtuais baseadas no Azure Resource Manager, o sufixo DNS é consistente em toda a rede virtual; o FQDN não é necessário. Os nomes DNS podem ser atribuídos a placas de interface de rede (NICs) e máquinas virtuais. Embora a resolução de nomes que o Azure fornece não exija nenhuma configuração, ela não é a opção apropriada para todos os cenários de implantação, como visto na tabela anterior.

Características e considerações

Funcionalidades:

• Nenhuma configuração é necessária para usar a resolução de nomes fornecida pelo Azure.
• O serviço de resolução de nomes que o Azure fornece está altamente disponível. Você não precisa criar e gerenciar clusters de seus próprios servidores DNS.
• O serviço de resolução de nomes que o Azure fornece pode ser usado junto com seus próprios servidores DNS para resolver nomes de host locais e do Azure.
• A resolução de nomes é fornecida entre máquinas virtuais em redes virtuais sem a necessidade do FQDN.
• Você pode usar nomes de host que melhor descrevam suas implantações em vez de trabalhar com nomes gerados automaticamente.

Considerações:

• O sufixo DNS que o Azure cria não pode ser modificado.
• Não é possível registar manualmente os seus próprios registos.
• WINS e NetBIOS não são suportados.
• Os nomes de host devem ser compatíveis com DNS. Os nomes devem usar apenas 0-9, a-z e '-', e não podem começar ou terminar com um '-'. Ver RFC 3696 Secção 2.
• O tráfego de consulta DNS é limitado para cada máquina virtual. A limitação não deve afetar a maioria dos aplicativos. Se a limitação de solicitações for observada, verifique se o cache do lado do cliente está habilitado. Para obter mais informações, consulte Obtendo o máximo da resolução de nomes que o Azure fornece.

Obtendo o máximo da resolução de nomes que o Azure fornece

Cache do lado do cliente:

Algumas consultas DNS não são enviadas pela rede. O cache do lado do cliente ajuda a reduzir a latência e melhorar a resiliência a inconsistências de rede, resolvendo consultas DNS recorrentes a partir de um cache local. Os registros DNS contêm um TTL (Time-To-Live), que permite que o cache armazene o registro pelo maior tempo possível sem afetar a atualização do registro. Como resultado, o cache do lado do cliente é adequado para a maioria das situações.

Algumas distribuições Linux não incluem cache por padrão. Recomendamos que você adicione um cache a cada máquina virtual Linux depois de verificar se ainda não há um cache local.

Vários pacotes de cache DNS diferentes, como dnsmasq, estão disponíveis. Aqui estão as etapas para instalar o dnsmasq nas distribuições mais comuns:

sudo apt-get install dnsmasq

sudo systemctl enable dnsmasq.service

sudo systemctl start dnsmasq.service

sudo zypper install dnsmasq

sudo systemctl enable dnsmasq.service

sudo systemctl start dnsmasq.service

sudo netconfig update

sudo yum install dnsmasq -y

sudo systemctl enable dnsmasq.service

sudo systemctl start dnsmasq.service

sudo echo "prepend domain-name-servers 127.0.0.1;" >>  /etc/dhcp/dhclient.conf

sudo systemctl restart NetworkManager

Tentativas do lado do cliente

O DNS é principalmente um protocolo UDP. Como o protocolo UDP não garante a entrega de mensagens, o próprio protocolo DNS lida com a lógica de repetição. Cada cliente DNS (sistema operacional) pode exibir uma lógica de repetição diferente, dependendo da preferência do criador:

• Os sistemas operacionais Windows tentam novamente após um segundo e depois novamente após mais dois, quatro e outros quatro segundos.
• A configuração padrão do Linux tenta novamente após cinco segundos. Você deve alterar isso para tentar novamente cinco vezes em intervalos de um segundo.

Para verificar as configurações atuais em uma máquina virtual Linux, 'cat /etc/resolv.conf', e veja a linha 'options', por exemplo:

sudo cat /etc/resolv.conf

options timeout:1 attempts:5

O /etc/resolv.conf arquivo é gerado automaticamente e não deve ser editado. As etapas específicas que adicionam a linha 'opções' variam de acordo com a distribuição:

Ubuntu (usa resolvconf)

1. Adicione a linha de opções ao /etc/resolvconf/resolv.conf.d/head arquivo.
2. Execute sudo resolvconf -u para atualizar.

SUSE (usa netconf)

1. Adicionar timeout:1 attempts:5 ao NETCONFIG_DNS_RESOLVER_OPTIONS="" parâmetro em /etc/sysconfig/network/config.
2. Execute sudo netconfig update para atualizar.

Resolução de nomes usando seu próprio servidor DNS

Suas necessidades de resolução de nomes podem ir além dos recursos que o Azure fornece. Por exemplo, você pode precisar de resolução DNS entre redes virtuais. Para cobrir esse cenário, você pode usar seus próprios servidores DNS.

Os servidores DNS dentro de uma rede virtual podem encaminhar consultas DNS para resolvedores recursivos do Azure para resolver nomes de host que estão na mesma rede virtual. Por exemplo, um servidor DNS executado no Azure pode responder a consultas DNS para seus próprios arquivos de zona DNS e encaminhar todas as outras consultas para o Azure. Essa funcionalidade permite que as máquinas virtuais vejam suas entradas em seus arquivos de zona e nomes de host que o Azure fornece (por meio do encaminhador). O acesso aos resolvedores recursivos do Azure é fornecido por meio do IP virtual 168.63.129.16.

O encaminhamento de DNS também permite a resolução de DNS entre redes virtuais e permite que suas máquinas locais resolvam nomes de host fornecidos pelo Azure. Para resolver o nome de host de uma máquina virtual, a máquina virtual do servidor DNS deve residir na mesma rede virtual e ser configurada para encaminhar consultas de nome de host para o Azure. Como o sufixo DNS é diferente em cada rede virtual, você pode usar regras de encaminhamento condicional para enviar consultas DNS para a rede virtual correta para resolução. A imagem a seguir mostra duas redes virtuais e uma rede local fazendo a resolução DNS entre redes virtuais usando esse método:

Quando você usa a resolução de nomes que o Azure fornece, o sufixo DNS interno é fornecido para cada máquina virtual usando DHCP. Quando você usa sua própria solução de resolução de nomes, esse sufixo não é fornecido para máquinas virtuais porque o sufixo interfere com outras arquiteturas DNS. Para se referir a máquinas por FQDN ou para configurar o sufixo em suas máquinas virtuais, você pode usar o PowerShell ou a API para determinar o sufixo:

• Para redes virtuais geridas pelo Azure Resource Manager, o sufixo está disponível através do recurso da placa de interface de rede. Você também pode executar o azure network public-ip show <resource group> <pip name> comando para exibir os detalhes do seu IP público, que inclui o FQDN da NIC.

Se o encaminhamento de consultas para o Azure não atender às suas necessidades, você precisará fornecer sua própria solução de DNS. Sua solução de DNS precisa:

• Forneça a resolução de nome de host apropriada, por exemplo, via DDNS. Se você usa DDNS, talvez seja necessário desativar a eliminação de registros DNS. As concessões de DHCP do Azure são longas e a eliminação pode remover registros DNS prematuramente.
• Fornecer resolução recursiva apropriada para permitir a resolução de nomes de domínio externos.
• Ser acessível (TCP e UDP na porta 53) a partir dos clientes que serve e ser capaz de aceder à Internet.
• Esteja protegido contra o acesso da Internet para mitigar ameaças representadas por agentes externos.