Arquitetura DNS no Windows Server

2025-06-21
Aplica-se a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

O DNS é um banco de dados distribuído hierárquico e um conjunto associado de protocolos que definem:

Um mecanismo para consultar e atualizar o banco de dados
Um mecanismo para replicar as informações no banco de dados entre servidores
Um esquema do banco de dados

Os nomes de host DNS residem em um banco de dados que pode ser distribuído entre vários servidores, diminuindo a carga em qualquer servidor, e fornecem a capacidade de administrar esse sistema de nomenclatura por partição. O DNS suporta nomes hierárquicos e permite o registo de vários tipos de dados, além do mapeamento de nomes de host e endereçosto-IP, usado em arquivos HOSTS. O banco de dados DNS é distribuído, permitindo que ele aumente e diminua a escala, o que significa que o desempenho não é degradado quando mais servidores são adicionados.

O DNS original foi baseado no Request for Comment (RFC) 1035 (Domain Names–Implementation and Specification). Outras RFCs descrevem problemas de segurança, implementação e administração de DNS que mais tarde aumentaram as especificações de design originais.

As RFCs usadas nos sistemas operacionais Windows Server são:

Nomes de domínio - conceitos e facilidades RFC 1034
Nomes de domínio - implementação e especificação RFC 1035
Extensões DNS para suportar IP versão 6 RFC 1886
Um mecanismo para notificação imediata de alterações de zona (DNS NOTIFY) RFC 1996
Transferência incremental de zona no DNS RFC 1995
Atualizações dinâmicas no sistema de nomes de domínio (DNS UPDATE)RFC 2136
Cache negativo de consultas DNS (NCACHE DNS) RFC 2308
Registros de recursos para as extensões de segurança DNS RFC 4034
Modificações de protocolo para as extensões de segurança DNS RFC 4035
Um DNS RR para especificar a localização dos serviços (DNS SRV) RFC 2052

Nomes de domínio DNS

O DNS é implementado como um banco de dados hierárquico e distribuído contendo vários tipos de dados, incluindo nomes de host e nomes de domínio. Os nomes em um banco de dados DNS formam uma estrutura de árvore hierárquica chamada namespace de domínio. Os nomes de domínio consistem em rótulos individuais separados por pontos, por exemplo: mydomain.contoso.com.

Um nome de domínio totalmente qualificado (FQDN) identifica exclusivamente a posição do host dentro da árvore hierárquica DNS. O FQDN especifica uma lista de nomes separados por pontos no caminho do host referenciado para a raiz. A figura a seguir mostra um exemplo de uma árvore DNS com um host chamado mydomain dentro do domínio contoso.com. O FQDN para o anfitrião seria mydomain.contoso.com.

Noções básicas sobre o namespace de domínio DNS

O namespace de domínio DNS, como mostrado na figura anterior, é baseado no conceito de uma árvore de domínios nomeados. Cada nível da árvore pode representar um ramo ou uma folha. Uma ramificação é um nível em que mais de um nome é usado para identificar uma coleção de recursos nomeados. Uma folha representa um único nome usado uma vez nesse nível para indicar um recurso específico.

Hierarquia de nomes de domínio DNS

Clientes e servidores DNS usam consultas como o método de resolução de nomes na árvore para tipos específicos de informações de recursos. Essas informações são fornecidas por servidores DNS em respostas de consulta a clientes DNS que, em seguida, extraem as informações e as passam para um programa solicitante para resolver o nome consultado. No processo de resolução de um nome, os servidores DNS geralmente funcionam como clientes DNS, consultando outros servidores para resolver completamente um nome consultado.

Por exemplo, a Contoso recebe autoridade dos servidores raiz da Internet para sua própria parte da árvore de namespace de domínio DNS na Internet, ou seja, contoso.com. A resolução de um nome fora do namespace contoso.com exige que os servidores DNS da Contoso consultem outros servidores DNS, como os servidores raiz.

Como o namespace de domínio DNS é organizado

Qualquer nome de domínio DNS usado na árvore é tecnicamente um domínio. No entanto, a maioria das discussões de DNS identifica nomes de uma de cinco maneiras, com base no nível e na maneira como um nome é comumente usado. Por exemplo, o nome de domínio DNS registrado na Contoso (contoso.com) é conhecido como um domínio de segundo nível. O nome tem duas partes (conhecidas como rótulos) que indicam que está localizado dois níveis abaixo da raiz ou do topo da árvore. A maioria dos nomes de domínio DNS tem dois ou mais rótulos, cada um dos quais indica um novo nível na árvore. Pontos são utilizados em nomes para separar rótulos.

A tabela a seguir descreve as cinco categorias de nomes de domínio DNS por sua função no namespace, juntamente com um exemplo de cada tipo de nome.

Tipo de nome	Descrição	Exemplo
Domínio raiz	O topo da árvore, representando um nível sem nome; às vezes é mostrado como duas aspas vazias (""), indicando um valor nulo. Quando usado num nome de domínio no DNS, é indicado por um ponto final (.) para indicar que está localizado na raiz ou no nível mais alto da hierarquia de domínio. Neste caso, o nome de domínio DNS é considerado completo e aponta para um local exato na árvore de nomes. Os nomes apresentados desta forma são FQDNs. Um único ponto (.) ou um ponto usado no final de um nome, como `example.contoso.com.`	Um único ponto (.) ou um ponto usado no final de um nome, como `example.contoso.com.`
Domínio de topo (TLD)	Um nome usado para indicar um país ou região ou o tipo de organização usando um nome.	`.com`, que indica um nome registado numa empresa para utilização comercial na Internet.
Domínio de segundo nível	Nomes de comprimento variável registados a um indivíduo ou organização para uso na Internet. Esses nomes são sempre baseados em um domínio de nível superior apropriado, dependendo do tipo de organização ou localização geográfica onde um nome é usado.	`contoso.com.` é o nome de domínio de segundo nível registrado na Contoso pelo registrador de nomes de domínio DNS da Internet.
Subdomínio	Outros nomes que uma organização pode criar que são derivados do nome de domínio de segundo nível registrado. Os subdomínios incluem nomes adicionados para aumentar a árvore DNS de nomes em uma organização e dividi-la em departamentos ou localizações geográficas.	`example.contoso.com.` é um subdomínio atribuído pela Contoso para uso em nomes de exemplo de documentação.
Nome do host ou do recurso	Nomes que representam uma folha na árvore DNS de nomes e identificam um recurso específico. Normalmente, o rótulo mais à esquerda de um nome de domínio DNS identifica um computador específico na rede. Por exemplo, se um nome nesse nível for usado em um registro de recurso de host (A), ele será usado para procurar o endereço IP do computador com base em seu nome de host.	`host-a.example.contoso.com.` O primeiro rótulo (host-a) é o nome de host DNS para um computador específico na rede.

DNS e domínios da Internet

As autoridades de registo na Internet gerem o Sistema de Nomes de Domínio. As autoridades de registo são responsáveis pela manutenção de domínios de nível superior atribuídos por organização e por país/região. Estes nomes de domínio seguem a norma internacional para os códigos de país (ISO 3166). Existem centenas de nomes de domínio de nível superior disponíveis para utilização pelo público. A tabela a seguir mostra alguns TLDs comuns, bem como exemplos de abreviaturas de duas letras usadas para países e regiões.

Nome de domínio DNS	Tipo de Organização
.com	Organizações comerciais
.edu	Instituições de ensino
.org	Organizações sem fins lucrativos
.net	Redes (a espinha dorsal da Internet)
.gov	Organizações governamentais não militares
.mil	Organizações governamentais militares
.arpa	DNS reverso
.xx	Códigos de país de duas letras (por exemplo, `.us`, `.au`, `.ca`., `.fr`)

Registos de recursos DNS

Os registros de recursos DNS contêm as informações que uma zona mantém sobre os recursos (como hosts) que a zona contém. Um registro de recurso típico consiste em:

Nome (host) do registro de recurso.
Informações sobre por quanto tempo o registro de recurso pode permanecer no cache.
Tipo de registro de recurso, como um registro de recurso de host (A).
Dados específicos para o tipo de registro, como o endereço IPv4 dos hosts.

Você pode adicionar registros de recursos diretamente ou eles podem ser adicionados automaticamente quando clientes habilitados para DHCP (Dynamic Host Configuration Protocol) baseados no Windows ingressam em uma rede usando a atualização dinâmica.

Tipos de registros de recursos

Os registos de recursos comuns incluem:

Tipo de registo de recurso	Descrição
Registos de Host (A, AAAA)	Mapeia um nome de host para um endereço IP.
Registos de alias (CNAME)	Encaminhe um nome de domínio ou subdomínio de alias para outro nome primário ou canônico. Os registos de recurso de alias (CNAME) também são denominados registos de recurso de nome canónico. Com esses registros, você pode usar mais de um nome DNS para apontar para um único host.
Registos MX (Mail Exchanger)	Especifica o nome de um computador que troca ou encaminha emails. Os aplicativos de email usam o registro de recurso MX (mail exchanger) para localizar um servidor de email com base em um nome de domínio DNS no endereço de destino do destinatário de email de uma mensagem. Se existirem vários registos de recursos MX (mail exchanger), o serviço Cliente DNS tenta contactar os servidores de correio pela ordem de preferência do valor mais baixo (prioridade mais alta) para o valor mais elevado (prioridade mais baixa).
Registos de ponteiro (PTR)	Usado para pesquisas reversas de DNS para mapear um endereço IP para um domínio. Os registros de recursos de ponteiro (PTR) suportam o processo de pesquisa inversa, com base em zonas criadas e enraizadas no domínio `in-addr.arpa`. Você precisa ter a zona de pesquisa inversa apropriada presente no seu servidor DNS para criar um registro PTR que mapeie um endereço IP para um nome de host específico.
Registos de localização de serviço (SRV)	Especifica o host, a porta e o protocolo de um serviço. Os registros de recursos de local de serviço (SRV) são necessários quando os clientes usam o DNS para localizar serviços de localização, como controladores de domínio do Ative Directory.
Registos do servidor de nomes (NS)	Especifica os servidores de nomes autoritativos para um domínio.
Registo de texto (TXT)	Permite a publicação de texto em um registro DNS. Os registros de texto permitem adicionar informações de texto que são retornadas consultando o DNS. Os registos TXT são frequentemente utilizados para autenticar a propriedade de zonas DNS.
Registo de nome de delegação (DNAME)	Fornece um alias para um domínio, como um registro CNAME, mas inclui todos os subdomínios.
Registo de início de autoridade (SOA)	Fornece informações autorizadas sobre uma zona DNS. O registro SOA inclui o servidor de nomes primário, o contato do administrador da zona DNS, informações de atualização e outras informações.

Time-to-Live para registros de recursos

O valor TTL (Time-to-Live) em um registro de recurso indica um período de tempo usado por outros servidores DNS para determinar por quanto tempo armazenar em cache as informações de um registro antes de expirá-lo e descartá-lo. Por exemplo, a maioria dos registros de recursos criados pelo serviço Servidor DNS herda o TTL mínimo (padrão) de uma hora a partir do início do registro de recurso de autoridade (SOA), o que impede o cache estendido por outros servidores DNS.

Um resolvedor de cliente DNS armazena em cache as respostas que recebe quando resolve consultas DNS. Essas respostas armazenadas em cache podem ser usadas para responder a consultas posteriores para obter as mesmas informações. Os dados armazenados em cache, no entanto, têm um tempo de vida limitado especificado no parâmetro TTL retornado com os dados de resposta. O TTL garante que o servidor DNS não mantenha as informações por tanto tempo que elas fiquem desatualizadas. O TTL para o cache pode ser definido no banco de dados DNS (para cada registro de recurso individual, especificando o campo TTL do registro e por zona através do campo TTL mínimo do registro SOA) e no lado do resolvedor do cliente DNS, especificando o TTL máximo que o resolvedor permite armazenar em cache os registros de recursos.

Há dois fatores concorrentes a considerar ao definir o TTL. O primeiro é a precisão das informações armazenadas em cache, e o segundo é a utilização dos servidores DNS e a quantidade de tráfego de rede. Se o TTL for curto, a probabilidade de ter informações antigas é reduzida consideravelmente, mas aumenta a utilização de servidores DNS e tráfego de rede, porque o cliente DNS deve consultar os servidores DNS para obter os dados expirados na próxima vez que for solicitado. Se o TTL for longo, as respostas armazenadas em cache podem ficar desatualizadas, o que significa que o resolvedor pode dar respostas falsas às consultas. Ao mesmo tempo, um TTL longo diminui a utilização de servidores DNS e reduz o tráfego de rede porque o cliente DNS responde a consultas usando seus dados armazenados em cache.

Se uma consulta for respondida com uma entrada do cache, o TTL da entrada também será passado com a resposta. Desta forma, os resolvedores que recebem a resposta sabem por quanto tempo a entrada é válida. Os resolvedores honram o TTL do servidor respondente; eles não o redefinem com base no seu próprio TTL. Assim, as entradas realmente expiram em vez de viverem perpetuamente à medida que passam do servidor DNS para o servidor DNS com um TTL atualizado.

Observação

Em geral, nunca configure o TTL para zero. A diferença entre uma configuração de 0 ou 60 é mínima para a precisão do registro, mas quando o TTL é definido como 0, há um impacto significativo no desempenho do servidor DNS porque o servidor DNS está constantemente consultando os dados expirados.

Zonas e delegação

Um banco de dados DNS pode ser particionado em várias zonas. Uma zona é uma parte do banco de dados DNS que contém os registros de recursos com os nomes de proprietário pertencentes à parte contígua do namespace DNS. Os arquivos de zona são mantidos em servidores DNS. Um único servidor DNS pode ser configurado para hospedar zero, uma ou várias zonas.

Cada zona é ancorada em um nome de domínio específico conhecido como domínio raiz da zona. Uma zona contém informações sobre todos os nomes que terminam com o nome de domínio raiz da zona. Um servidor DNS é considerado autoritativo para um nome se carrega a zona que contém esse nome. O primeiro registro em qualquer arquivo de zona é um registro de recurso Start of Authority (SOA). O registro de recurso SOA identifica um servidor de nomes DNS primário para a zona como a melhor fonte de informações para os dados dentro dessa zona. A SOA também atua como uma entidade que processa as atualizações para a zona.

Um nome dentro de uma zona também pode ser delegado a uma zona diferente hospedada em um servidor DNS diferente. A delegação é um processo de atribuição de responsabilidade por uma parte de um namespace DNS a um servidor DNS de propriedade de uma entidade separada. Essa entidade separada pode ser outra organização, departamento ou grupo de trabalho dentro da sua empresa. Essa delegação é representada pelo registro de recurso NS que especifica a zona delegada e o nome DNS do servidor autorizado para essa zona. Delegar em várias zonas fazia parte do objetivo de design original do DNS.

Para saber mais sobre os tipos e a replicação de zonas DNS, consulte zonas DNS.

Os motivos para delegar um namespace DNS incluem:

Uma necessidade de delegar o gerenciamento de um domínio DNS a muitas organizações ou departamentos dentro de uma organização.
Uma necessidade de distribuir a carga de manutenção de um grande banco de dados DNS entre vários servidores DNS para melhorar o desempenho de resolução de nomes e criar um ambiente DNS tolerante a falhas.
Há uma necessidade de permitir a afiliação organizacional de um host ao incluir o anfitrião em domínios apropriados. Os registros de recursos do servidor de nomes (NS) facilitam a delegação identificando servidores DNS para cada zona e os registros de recursos NS aparecem em todas as zonas. Sempre que um servidor DNS precisa cruzar uma delegação para resolver um nome, ele se refere aos registros de recursos NS para servidores DNS na zona de destino.

A imagem a seguir mostra como o gerenciamento do domínio contoso.com é delegado em duas zonas, contoso.com e mydomain.contoso.com.

Observação

Se existirem vários registos NS para uma zona delegada que identifique vários servidores DNS disponíveis para consulta, o serviço Servidor DNS do Windows Server poderá selecionar o servidor DNS mais próximo com base nos intervalos de ida e volta medidos ao longo do tempo para cada servidor DNS.

Arquitetura de serviço DNS

O diagrama a seguir ilustra a arquitetura do serviço Cliente DNS em suas operações de resolução de nomes e atualização no cliente Windows e no Windows Server. A arquitetura de resolução de nomes é demonstrada usando um aplicativo cliente e as atualizações são representadas pelo cliente DHCP.

O diagrama a seguir ilustra a arquitetura de serviço do Servidor DNS com suas ferramentas de administração e a interface WMI (Instrumentação de Gerenciamento do Windows) no Windows Server.

As seções a seguir descrevem o processo de consulta DNS e como as atualizações DNS são tratadas.

Consultas DNS

As consultas DNS podem ser enviadas de um cliente DNS (resolvedor) para um servidor DNS ou entre dois servidores DNS.

Uma consulta DNS é meramente uma solicitação de registros de recursos DNS de um tipo de registro de recurso especificado com um nome DNS especificado. Por exemplo, uma consulta DNS pode solicitar todos os registros de recursos do tipo A (host) com um nome DNS especificado.

Existem dois tipos de consultas DNS que podem ser enviadas para um servidor DNS:

recursivo : Uma consulta recursiva força um servidor DNS a responder a uma solicitação com uma resposta de falha ou sucesso. Os clientes DNS (resolvedores) normalmente fazem consultas recursivas. Com uma consulta recursiva, o servidor DNS deve entrar em contato com quaisquer outros servidores DNS necessários para resolver a solicitação. Quando recebe uma resposta bem-sucedida do outro servidor DNS (ou servidores), envia uma resposta para o cliente DNS. A consulta recursiva é o tipo de consulta típico usado por um resolvedor consultando um servidor DNS e por um servidor DNS consultando seu encaminhador, que é outro servidor DNS configurado para lidar com solicitações encaminhadas para ele.

Quando um servidor DNS processa uma consulta recursiva e a consulta não pode ser resolvida a partir de dados locais (arquivos de zona local ou cache de consultas anteriores), a consulta recursiva deve ser escalada para um servidor DNS raiz. Cada implementação baseada em padrões do DNS inclui um arquivo de cache (ou dicas de servidor raiz) que contém entradas para os servidores DNS raiz dos domínios da Internet. (Se o servidor DNS estiver configurado com um encaminhador, o encaminhador será usado antes que um servidor raiz seja usado.)
iterativa: Uma consulta iterativa é aquela em que se espera que o servidor DNS responda com as melhores informações locais que possui, com base no que o servidor DNS sabe de arquivos de zona local ou de cache. Essa resposta também é conhecida como referência se o servidor DNS não tiver autoridade para o nome. Se um servidor DNS não tiver nenhuma informação local que possa responder à consulta, ele simplesmente enviará uma resposta negativa. Um servidor DNS faz esse tipo de consulta enquanto tenta encontrar nomes fora de seu domínio (ou domínios) local (quando não está configurado com um encaminhador). Pode ser necessário consultar servidores DNS externos na tentativa de resolver o nome.

A figura a seguir mostra um exemplo de ambos os tipos de consultas.

O diagrama mostra como várias consultas foram usadas para determinar o endereço IP para www.contoso.com. A sequência de consulta é descrita da seguinte forma:

Consulta recursiva para www.contoso.com (um registro de recurso).
Consulta iterativa para www.contoso.com (um registo de recurso).
Encaminhamento para o servidor de nomes .com (registros de recursos NS, por .com); para simplificar, foram omitidas consultas iterativas A pelo servidor DNS para resolver os endereços IP dos nomes de host do servidor de nomes retornados por outros servidores DNS.
Consulta iterativa para www.contoso.com (um registo de recurso).
Referência ao servidor de nomes contoso.com (registro de recurso NS, para contoso.com).
Consulta iterativa para www.contoso.com (um registo de recurso).
Resposta à consulta iterativa do servidor contoso.com (endereço IP www.contoso.com).
Resposta à consulta recursiva original do servidor DNS local ao resolvedor (endereço IP www.contoso.com).

Atualizar DNS

Os registros de recursos geralmente mudam à medida que computadores, servidores e dispositivos são adicionados ou removidos da rede. A implementação do DNS no Windows Server suporta atualizações estáticas e dinâmicas do banco de dados DNS.

Os registros de recursos podem ser adicionados a uma zona existente usando o comando Add-DNSServerResourceRecord PowerShell. Alguns tipos de registro de recurso comuns têm outros comandos do PowerShell em que você não precisa especificar o tipo de registro de recurso. Você também pode adicionar registros de recursos usando o console do Gerenciador DNS. Consulte Gerenciando registros de recursos DNS para obter orientações sobre como trabalhar com registros de recursos, incluindo a criação e modificação de registros de recursos existentes de todos os tipos.

Suporte a caracteres Unicode

Quando o DNS foi introduzido como parte da RFC 1035, os nomes eram limitados ao uso de letras maiúsculas e minúsculas (A-Z, a-z), números (0-9) e hífenes (-). Além disso, o primeiro caractere do nome DNS pode ser um número e os nomes devem ser codificados e representados usando caracteres baseados em US-ASCII. Para o uso de DNS em configurações internacionais, esse requisito cria limitações significativas quando conjuntos de caracteres estendidos são usados para padrões de nomenclatura locais. O serviço DNS do Windows Server fornece suporte aprimorado, além da especificação RFC 1035, para caracteres UTF-8.

O que é UTF-8?

UTF-8 é o conjunto de caracteres recomendado para protocolos que evoluem além do uso de ASCII. O protocolo UTF-8 fornece suporte a caracteres ASCII estendidos e tradução de UCS-2, um conjunto de caracteres Unicode de 16 bits que engloba a maioria dos sistemas de escrita do mundo. UTF-8 permite uma gama muito maior de nomes do que pode ser alcançado usando ASCII ou codificação ASCII estendida para dados de caracteres.

Os computadores que executam o Windows Server 2008 reconhecem UTF-8. O que significa que quando caracteres codificados em UTF-8 são recebidos ou usados como dados pelo servidor, o servidor pode carregar e armazenar esses dados em suas zonas. Embora os servidores DNS baseados no Windows reconheçam UTF-8, eles permanecem compatíveis com outros servidores DNS que usam codificação de dados US-ASCII tradicional e padrões DNS atuais.

Como o serviço DNS implementa UTF-8

Para fornecer compatibilidade e interoperabilidade de padrões com outras implementações de DNS, o serviço DNS usa downcasing uniforme de todos os dados de caracteres recebidos. Nesse processo, o serviço DNS converte todos os caracteres maiúsculos usados em dados US-ASCII padrão em dados equivalentes minúsculos pelos seguintes motivos:

Para manter a compatibilidade com os padrões DNS atuais e existentes.
Para fornecer interoperabilidade com implementações de servidor DNS que não reconhecem ou suportam codificação UTF-8.

Para compreender por que razão se optou por uma redução uniforme, devem ser considerados, em primeiro lugar, vários pontos conexos a partir das atuais normas revistas da Internet para o DNS. Vários pontos-chave nos padrões dizem respeito diretamente à forma como os dados de caracteres devem ser tratados entre servidores DNS e outros servidores e clientes. Os pontos-chave incluem:

Qualquer string binária pode ser usada em um nome DNS. (RFC 2181)
Os servidores DNS devem ser capazes de comparar nomes de uma forma que não diferencie maiúsculas de minúsculas. (RFC 1035)
O caso original para os dados de caracteres deve ser preservado sempre que possível à medida que os dados são inseridos no sistema. (RFC 1035)

Como a insensibilidade a maiúsculas e minúsculas é uma parte necessária do padrão DNS principal e a preservação de maiúsculas e minúsculas é uma recomendação opcional, optou-se pelo downcasing uniforme para fornecer uma solução eficaz e compatível com os padrões. Ao reduzir os nomes codificados UTF-8 antes da transmissão, outros servidores DNS (que não estão cientes de UTF-8) são capazes de receber e executar comparações binárias bem-sucedidas dos dados e obter os resultados desejados.

Considerações para a interoperabilidade com UTF-8

O serviço Servidor DNS pode ser definido para permitir ou bloquear o uso de caracteres UTF-8 para cada servidor. Alguns servidores DNS que não suportam UTF-8 podem aceitar zonas com nomes UTF-8, mas podem ter problemas para salvar ou recarregar esses nomes. Tenha cuidado ao transferir zonas com nomes UTF-8 para servidores que não suportam UTF-8.

Alguns protocolos impõem restrições aos caracteres permitidos em um nome. Além disso, os nomes que se destinam a ser globalmente visíveis (RFC 1958) devem conter caracteres somente ASCII, conforme recomendado no RFC 1123.

Usar UTF-8 para transformar caracteres Unicode é invisível para os usuários. No entanto, você pode ver caracteres codificados em UTF-8 se você usar o Monitor de rede ou uma ferramenta semelhante para analisar o tráfego DNS.

Além do suporte ao servidor DNS para o formato de codificação UTF-8, o resolvedor do cliente usa como padrão o formato de codificação de caracteres UTF-8.

Os nomes codificados no formato UTF-8 não devem exceder os limites de tamanho esclarecidos na RFC 2181, que especifica um máximo de 63 octetos por rótulo e 255 octetos por nome. A contagem de caracteres é insuficiente para determinar o tamanho porque alguns caracteres UTF-8 excedem um octeto de comprimento.

O protocolo de codificação UTF-8 adapta-se ao uso com implementações de protocolo DNS existentes que esperam US-ASCII caracteres porque a representação de US-ASCII caracteres em UTF-8 é idêntica, byte por byte, à representação US-ASCII. As implementações de cliente ou servidor DNS que não reconhecem caracteres UTF-8 sempre codificam nomes no formato US-ASCII. O serviço Servidor DNS é capaz de interpretar corretamente esses nomes.

O serviço DNS pode configurar a verificação de nome para permitir ou restringir o uso de caracteres UTF-8 em dados DNS.

Por padrão, a verificação de nome UTF-8 multibyte é usada, permitindo a maior tolerância quando o serviço DNS processa caracteres. A verificação de nomes UTF-8 multibyte é o método preferencial de verificação de nomes para a maioria dos servidores DNS operados de forma privada que não fornecem serviço de nomes para hosts da Internet.