DNS privado para redes VPS: como funciona e quando você precisa dele

Você sobe um terceiro servidor, precisa que as máquinas se encontrem pelo nome em vez do IP e pesquisa "private DNS VPS". Voltam três resultados e eles não concordam entre si. Um é uma configuração do Android que criptografa as consultas do seu telefone. Outro é um guia do cPanel para personalizar os servidores de nomes de um domínio. Outro é um documento da AWS sobre zonas hospedadas privadas. Em 20 de julho de 2026, A Cloudflare lançou o Internal DNS em disponibilidade geral e o descreveu como "às vezes também chamado de DNS privado", de modo que agora a confusão vem também dos fornecedores de infraestrutura.

O termo está sobrecarregado. Este artigo separa os diferentes significados e depois se concentra no sentido de rede VPS: uma zona DNS interna para a comunicação entre servidores. No fim, você saberá identificar qual sistema precisa, decidir se sua frota exige DNS privado e evitar erros comuns de projeto.

TL;DR

• "DNS privado" nomeia pelo menos três sistemas sem relação entre si: uma zona DNS interna para uma rede de servidores, o recurso de criptografia DNS-over-TLS do Android e os servidores de nomes personalizados do cPanel. Este artigo usa o termo no primeiro sentido: uma zona DNS interna para uma rede VPS.
• Uma zona DNS privada de VPS é um espaço de nomes interno restrito à rede que mapeia nomes de host como db.internal.example.com a IPs privados. Seus registros não são publicados no DNS público.
• Para um punhado de servidores com IPs estáveis, /etc/hosts é realmente suficiente. Um servidor DNS interno se paga quando a frota cresce, os IPs mudam com frequência ou os serviços precisam de resolução de nomes confiável.
• Para a maioria das redes VPS em produção, use um subdomínio que você possua, como internal.example.com. Use o espaço de nomes .internal apenas em uma configuração isolada em que sejam aceitáveis colisões de nomes entre redes, a gestão de certificados por uma CA privada e um tratamento especial de DNSSEC. Evite .local, que o mDNS reserva.

O Que Este Artigo Não Aborda

Este texto se limita ao sentido de rede VPS do DNS privado. Ele não cobre usos de consumo e de marcas de hospedagem sem relação com o tema:

• Configurar a opção de DNS privado ou DNS-over-TLS do Android em um telefone.
• Configurar servidores de nomes privados do cPanel para uma marca de hospedagem.
• Um tutorial completo de instalação de BIND 9, Unbound, dnsmasq ou CoreDNS. Aqui a implementação fica em nível de referência, não de configuração passo a passo.
• Resolvedores criptografados de consumo como 1.1.1.1 ou NextDNS, além de diferenciá-los do sentido de rede.

O que "DNS privado" realmente significa?

"DNS privado" não é um único sistema. O termo nomeia pelo menos três sem relação entre si: uma zona DNS restrita à rede que resolve nomes de host internos dentro de uma rede VPS ou VPC, o recurso de criptografia DNS-over-TLS do Android e os servidores de nomes autoritativos personalizados do cPanel. Este artigo trata do primeiro, a zona interna que seus servidores consultam para se encontrarem. Existe também um quarto uso mais solto: resolvedores públicos criptografados vendidos como "privados".

Os quatro significados compartilham um nome e nada mais:

O anúncio de disponibilidade geral do Internal DNS da Cloudflare é um exemplo gerenciado e atual do primeiro significado, e uma das razões pelas quais a confusão ficou visível: um fornecedor de infraestrutura agora usa "DNS privado" como sinônimo de DNS interno em seu texto de lançamento. O sistema que ele descreve, um Gateway Resolver mais o Internal Authoritative DNS para clientes Enterprise, é a mesma categoria de sistema que você monta sozinho em uma frota de VPS, só que gerenciado.

Conclusão da seção: os principais sistemas chamados de "DNS privado" compartilham um rótulo, não uma função. Identifique o significado antes de seguir um guia de configuração.

Como o DNS privado funciona em uma rede VPS?

Uma zona DNS privada de VPS é um espaço de nomes restrito à rede, servido por um resolvedor que seus servidores estão configurados para usar. Ela mapeia nomes de host internos como db.internal.example.com a IPs privados em uma faixa que você controla. Os registros não são publicados no DNS público, ainda que as consultas possam passar por um túnel privado ou por um plano de controle DNS gerenciado antes de chegar ao resolvedor. Essa separação é o cerne da distinção entre DNS privado e DNS público: o protocolo é o mesmo, mas a visibilidade da zona e seu alcance de acesso são diferentes.

Três partes fazem o trabalho. Um servidor autoritativo ou fonte de zona guarda a zona interna e seus registros. Um resolvedor responde às consultas que seus servidores enviam. E os registros A e AAAA da zona mapeiam nomes de host internos para endereços privados, de modo que app.internal.example.com resolve para a camada de aplicação e db.internal.example.com resolve para o banco de dados. Outros tipos de registro podem fornecer apelidos ou informações de serviço. Quando a zona e o caminho do resolvedor estão configurados corretamente, o resolvedor responde à consulta interna localmente em vez de enviá-la para a raiz do DNS público.

As plataformas de nuvem delimitam isso à rede em vez da máquina, o que é um modelo de referência útil. As zonas hospedadas privadas do AWS Route 53 só funcionam quando a VPC tem enableDnsHostnames e enableDnsSupport definidos como true, e o resolvedor responde a partir da zona privada para qualquer VPC que você associe a ela. As zonas privadas do Google Cloud são restritas a redes VPC autorizadas e, na ordem de resolução padrão de uma VPC elas são consultadas antes do DNS público, a menos que uma política de servidor de saída altere o caminho. Leia isso como ilustrações do padrão, não como tutoriais de plataforma: um servidor DNS interno autogerenciado é a mesma ideia, rodando no seu próprio VPS.

Manter a zona fora do DNS público é só metade do trabalho. Vincule o serviço DNS a uma interface privada ou restrinja a porta 53 em UDP e TCP à sua rede privada ou VPN. Não exponha o serviço recursivo à internet pública; um resolvedor aberto pode ser abusado em ataques de amplificação de DNS.

Zonas privadas e públicas usam o mesmo modelo de registros e cache do DNS. Os registros carregam um TTL, e resolvedores com cache normalmente reaproveitam uma resposta até esse TTL expirar, embora configurações próprias de cada resolvedor possam mudar o tempo real de cache. Esse comportamento é tratado em nosso guia de apontar um domínio para um VPS, incluindo os fundamentos da propagação de DNS e do TTL, por isso não é reexplicado aqui.

Quando a sua rede VPS realmente precisa de DNS privado?

Para dois ou três servidores estáticos, /etc/hosts é realmente suficiente. Um servidor DNS interno se paga quando a frota cresce, os IPs mudam com regularidade ou as aplicações precisam de descoberta de serviços confiável. O gatilho real é a complexidade operacional, não um número fixo de servidores.

/etc/hosts é um mapa estático de nome de host para IP que já existe em toda máquina Linux. Não precisa de daemon nem de arquivo de zona, mas cópias desatualizadas ou inconsistentes são falhas bem reais. Adicione o IP privado de cada servidor ao arquivo, mantenha as cópias sincronizadas e as máquinas conseguirão se achar pelo nome. Para uma frota pequena e estável essa é a resposta certa, e apelar para o BIND 9 no lugar apenas acrescenta um daemon para manter sem ganho nenhum.

Ele deixa de dar conta em três situações. Quando você adiciona e remove servidores com frequência, manter um arquivo estático consistente em cada host vira trabalho manual penoso. Quando os IPs mudam, por autoescalonamento, reconstruções ou realocações do provedor, o arquivo fica desatualizado em silêncio. E quando contêineres ou runtimes isolados não herdam as entradas do host, o mapeamento deixa de ser universal. Qualquer uma dessas é o gatilho real. O número de servidores sozinho é uma aproximação grosseira, não o sinal de verdade.

Conclusão da seção: o gatilho é a rotatividade operacional, não a contagem de servidores. Uma frota congelada de dez máquinas pode viver com /etc/hosts; uma frota de três máquinas que é reconstruída toda noite provavelmente não.

Construa num VPS Linux com acesso root, NVMe e o poder do AMD EPYC.

Ver planos Linux

Qual servidor DNS você deve rodar: BIND 9, Unbound, dnsmasq ou CoreDNS?

Escolha pelo formato da sua frota. O dnsmasq serve a redes pequenas que querem DNS leve e, quando cabe, DHCP a partir do mesmo daemon. O Unbound é um resolvedor recursivo enxuto e validador, que também responde por uma zona local modesta. O BIND 9 oferece amplos recursos autoritativos e recursivos, com a maior superfície de configuração. O CoreDNS se encaixa em frotas de contêiner e Kubernetes, em que o DNS faz parte da descoberta de serviços.

A lógica de escolha é curta. Se você precisa de um resolvedor pequeno apoiado em um arquivo no estilo hosts, ou já distribui concessões DHCP, o dnsmasq tira uma peça móvel do caminho. Se o que você precisa é sobretudo um resolvedor validador que encaminhe para fora e responda por uma zona interna modesta, o Unbound entrega esse conjunto mais estreito sem uma implantação completa do BIND 9. Se você precisa de controle autoritativo total, delegação e o maior acervo de documentação para se apoiar às 3 da manhã, o BIND 9 é a escolha conservadora apesar da superfície de configuração mais ampla. Se o DNS já faz parte de uma pilha de descoberta de serviços com contêineres ou Kubernetes, o CoreDNS encontra o terreno pronto. A regra prática é rodar a menor coisa que dê conta do formato da sua frota.

Em uma frota de produção, não faça de uma única instância DNS o único caminho para cada nome interno. Rode pelo menos duas instâncias DNS que possam responder pela zona, coloque-as em domínios de falha separados quando for prático e configure os clientes para alcançarem as duas. Caso contrário, uma única queda de DNS pode fazer serviços saudáveis parecerem mortos.

Como nomear seu domínio interno: .internal, .local ou um subdomínio?

Para a maioria das redes VPS em produção, use um subdomínio que você possua, como internal.example.com. Use o espaço de nomes .internal apenas em uma configuração isolada em que sejam aceitáveis colisões de nomes entre redes, a gestão de certificados por uma CA privada e um tratamento especial de DNSSEC. Evite .local, que o mDNS reserva.

O problema do .local é concreto. RFC 6762 dá aos nomes terminados em .local um tratamento especial para Multicast DNS, de modo que uma zona unicast em BIND 9 ou Unbound com o mesmo sufixo pode entrar em conflito com o comportamento de mDNS em dispositivos Apple e outros sistemas com mDNS. Use outro espaço de nomes em vez de contar com contornos específicos de cada cliente.

Dica profissional: se você herdou uma zona interna em .local, trate isso como dívida técnica. Alguns clientes mandam consultas .local para o mDNS em vez do seu servidor DNS unicast, o que pode gerar falhas que dependem do cliente ou parecem intermitentes.

A Diretoria da ICANN reservou permanentemente o .internal da delegação na raiz do DNS público em julho de 2024, após uma recomendação anterior do SSAC. Por design, os nomes sob ele não serão resolvidos pelo DNS global. Isso vem com contrapartidas: nomes .internal não são globalmente únicos, não se espera que autoridades certificadoras públicas emitam certificados para eles, e resolvedores que validam DNSSEC apoiados na âncora de confiança global não conseguirão resolvê-los. Se você precisa de HTTPS em .internal, planeje operar uma CA privada.

Aqui vale separar duas coisas. A reserva da ICANN é definitiva. Em separado, um Internet-Draft ativo, draft-davies-internal-tld-06, publicado em 6 de maio de 2026 para documentar o espaço de nomes e compará-lo com o endereçamento privado da RFC 1918. Ele continua sendo um Internet-Draft em andamento, e não uma RFC publicada, então descreva o .internal como um TLD de uso privado reservado pela ICANN, não como um padrão do IETF.

Para a maioria das frotas de VPS, um subdomínio de um domínio que você controla é o padrão mais seguro. O ISC recomenda uma hierarquia de subdomínios, como um subdomínio interno do seu próprio domínio, em vez de manter versões internas e públicas separadas e incompletas da mesma zona pai. Essa preferência não é estilística: ela evita a falha da próxima seção.

Conclusão da seção: a decisão sobre o espaço de nomes é de longa duração. Um subdomínio que você controla é o padrão para a maioria dos ambientes de produção, porque preserva a unicidade global e funciona com a PKI pública. Use .internal quando um espaço de nomes privado e isolado se encaixar melhor e você aceitar suas contrapartidas de DNSSEC, certificados e colisões.

DNS de horizonte dividido e os erros que o quebram

O DNS de horizonte dividido devolve, para o mesmo nome de host, uma resposta diferente conforme quem pergunta: o IP privado internamente, o IP público externamente. Ele quebra com mais frequência pela armadilha NXDOMAIN no mesmo domínio, por resolvedores alternativos que contornam a visão pretendida e por caminhos de DNS em contêineres que não chegam ao upstream esperado. Acertar depende de três coisas ao mesmo tempo, não de uma.

A armadilha NXDOMAIN é justamente a falha sobre a qual o ISC alerta diretamente. Se seus servidores internos são autoritativos para o domínio pai, mas a versão da zona neles não contém um registro público como o host www, um cliente interno que consulte esse nome recebe NXDOMAIN mesmo com a zona pública tendo o registro. A zona interna é autoritativa e não recorre ao DNS público para o domínio pai. É exatamente por isso que a abordagem de hierarquia de subdomínios da seção de nomenclatura é o desenho preferido pelo ISC.

Dica profissional: antes de apontar seus servidores para uma configuração de horizonte dividido no mesmo domínio, teste de dentro da rede a resolução de um nome público conhecido desse domínio. Uma resposta NXDOMAIN para um nome que resolve normalmente por fora é a assinatura dessa armadilha.

Outras três armadilhas passam batido com facilidade. Um resolvedor alternativo configurado em um host ou contêiner pode contornar a separação; dependendo da implementação do resolvedor, ele pode ser consultado após um tempo limite ou em paralelo, então as respostas variam. Contêineres na bridge padrão do Docker recebem, ao iniciar, uma cópia da configuração de DNS do host, enquanto contêineres em redes personalizadas consultam o resolvedor embutido do Docker em 127.0.0.11. Esse resolvedor encaminha as buscas externas para os servidores DNS configurados para o host ou o contêiner, então o comportamento do split-DNS depende da configuração do Docker e do host, e não apenas do arquivo de resolução do próprio contêiner. Se um serviço interno fica atrás de um proxy reverso como o Gerenciador de Proxy Nginx, a validação do certificado pode falhar quando ele não cobre o nome de host solicitado ou quando a CA emissora não é confiável para o cliente. Apenas usar um certificado diferente internamente não é, por si só, um erro. São lacunas de configuração, não defeitos das ferramentas.

Clientes remotos podem cair na mesma falha quando uma VPN auto-hospedada não envia nem roteia as consultas DNS para o resolvedor interno pretendido.

Há também uma dimensão de segurança. Se nomes de host internos e IPs privados vazarem para registros DNS públicos, você expôs parte do seu esquema interno de nomes e endereços a qualquer um que consulte. O horizonte dividido existe em parte para manter esse mapa interno, e uma zona pública mal configurada desfaz isso em silêncio.

Conclusão da seção: as falhas do horizonte dividido são armadilhas de configuração, não defeitos das ferramentas. A correção depende de disciplina de nomenclatura, de saber qual resolvedor cada cliente realmente consulta e de delimitar a zona corretamente, não de um único ajuste.

LER

Como Apontar um Domínio para VPS: Guia Rápido

Conclusão: escolhendo o desenho certo de DNS privado

Agora você consegue identificar a qual sistema de "DNS privado" está realmente se referindo. Em redes VPS, é a zona DNS interna, não a configuração DNS-over-TLS do Android nem servidores de nomes autoritativos personalizados. Se sua frota é pequena e estável, /etc/hosts é uma escolha defensável. Se não for, use um subdomínio seu como espaço de nomes padrão, escolha o menor servidor DNS que sirva à frota e mantenha explícitos o acesso, a redundância e o alcance da zona interna frente à pública. Use .internal só quando um espaço de nomes isolado se encaixar melhor e você aceitar suas contrapartidas de certificados, DNSSEC e colisões.

Perguntas frequentes