Sistema de nomes de domínio

O Domain Name System (DNS) é um sistema de nomenclatura hierárquico e distribuído para computadores, serviços e outros recursos na Internet ou em outras redes de Protocolo de Internet (IP).. Associa várias informações aos nomes de domínio atribuídos a cada uma das entidades associadas. Mais proeminentemente, traduz nomes de domínio prontamente memorizados para os endereços IP numéricos necessários para localizar e identificar serviços de computador e dispositivos com os protocolos de rede subjacentes. O Domain Name System tem sido um componente essencial da funcionalidade da Internet desde 1985.

O Domain Name System delega a responsabilidade de atribuir nomes de domínio e mapear esses nomes para recursos da Internet, designando servidores de nomes autorizados para cada domínio. Os administradores de rede podem delegar autoridade sobre subdomínios de seu espaço de nome alocado para outros servidores de nome. Esse mecanismo fornece serviço distribuído e tolerante a falhas e foi projetado para evitar um único grande banco de dados central.

O Domain Name System também especifica a funcionalidade técnica do serviço de banco de dados que está em seu núcleo. Ele define o protocolo DNS, uma especificação detalhada das estruturas de dados e trocas de comunicação de dados usadas no DNS, como parte do Internet Protocol Suite.

A Internet mantém dois namespaces principais, a hierarquia de nomes de domínio e os espaços de endereço do Protocolo de Internet (IP). O Domain Name System mantém a hierarquia de nomes de domínio e fornece serviços de tradução entre ele e os espaços de endereçamento. Os servidores de nomes da Internet e um protocolo de comunicação implementam o Domain Name System. Um servidor de nomes DNS é um servidor que armazena os registros DNS de um domínio; um servidor de nomes DNS responde com respostas a consultas em seu banco de dados.

Os tipos mais comuns de registros armazenados no banco de dados DNS são para Start of Authority (SOA), endereços IP (A e AAAA), trocadores de correio SMTP (MX), servidores de nomes (NS), ponteiros para pesquisas reversas de DNS (PTR) e aliases de nome de domínio (CNAME). Embora não pretenda ser um banco de dados de uso geral, o DNS foi expandido ao longo do tempo para armazenar registros de outros tipos de dados para pesquisas automáticas, como registros DNSSEC, ou para consultas humanas, como pessoa responsável (RP) registros. Como um banco de dados de uso geral, o DNS também tem sido usado no combate a e-mails não solicitados (spam), armazenando uma lista de buracos negros em tempo real (RBL). O banco de dados DNS é tradicionalmente armazenado em um arquivo de texto estruturado, o arquivo de zona, mas outros sistemas de banco de dados são comuns.

O Domain Name System originalmente usava o User Datagram Protocol (UDP) como transporte sobre IP. Preocupações com confiabilidade, segurança e privacidade geraram o uso do Protocolo de Controle de Transmissão (TCP), bem como vários outros desenvolvimentos de protocolo.

Função

Uma analogia frequentemente usada para explicar o DNS é que ele serve como um catálogo telefônico para a Internet, traduzindo nomes de host de computadores amigáveis para humanos em endereços IP. Por exemplo, o nome do host www.example.com dentro do nome de domínio example.com é traduzido para os endereços 93.184.216.34 (IPv4) e 2606:2800:220:1:248:1893:25c8:1946 (IPv6). O DNS pode ser atualizado de forma rápida e transparente, permitindo que a localização de um serviço na rede mude sem afetar os usuários finais, que continuam usando o mesmo nome de host. Os usuários tiram proveito disso quando usam localizadores uniformes de recursos (URLs) significativos e endereços de e-mail sem precisar saber como o computador realmente localiza os serviços.

Uma função importante e onipresente do DNS é seu papel central em serviços de Internet distribuídos, como serviços em nuvem e redes de distribuição de conteúdo. Quando um usuário acessa um serviço de Internet distribuído usando uma URL, o nome de domínio da URL é traduzido para o endereço IP de um servidor próximo ao usuário. A principal funcionalidade do DNS explorada aqui é que diferentes usuários podem simultaneamente receber diferentes traduções para o mesmo nome de domínio, um ponto-chave de divergência de uma visão de catálogo telefônico tradicional de o DNS. Esse processo de usar o DNS para atribuir servidores proximais aos usuários é fundamental para fornecer respostas mais rápidas e confiáveis na Internet e é amplamente utilizado pela maioria dos principais serviços da Internet.

O DNS reflete a estrutura de responsabilidade administrativa na Internet. Cada subdomínio é uma zona de autonomia administrativa delegada a um gestor. Para zonas operadas por um registro, as informações administrativas geralmente são complementadas pelos serviços RDAP e WHOIS do registro. Esses dados podem ser usados para obter informações e rastrear a responsabilidade por um determinado host na Internet.

História

O uso de um nome mais simples e memorável no lugar do endereço numérico de um host remonta à era da ARPANET. O Stanford Research Institute (agora SRI International) mantinha um arquivo de texto chamado HOSTS.TXT que mapeava nomes de host para endereços numéricos de computadores na ARPANET. Elizabeth Feinler desenvolveu e manteve o primeiro diretório ARPANET. A manutenção de endereços numéricos, chamada Lista de Números Atribuídos, foi realizada por Jon Postel no Instituto de Ciências da Informação (ISI) da Universidade do Sul da Califórnia, cuja equipe trabalhou em estreita colaboração com o SRI.

Os endereços foram atribuídos manualmente. Os computadores, incluindo seus nomes de host e endereços, foram adicionados ao arquivo principal entrando em contato com o SRI Network Information Center (NIC), dirigido por Feinler, por telefone durante o horário comercial. Posteriormente, Feinler configurou um diretório WHOIS em um servidor no NIC para recuperação de informações sobre recursos, contatos e entidades. Ela e sua equipe desenvolveram o conceito de domínios. Feinler sugeriu que os domínios deveriam ser baseados na localização do endereço físico do computador. Computadores em instituições de ensino teriam o domínio edu, por exemplo. Ela e sua equipe administraram o Host Naming Registry de 1972 a 1989.

No início da década de 1980, a manutenção de uma única tabela de host centralizada tornou-se lenta e difícil de manejar, e a rede emergente exigia um sistema de nomenclatura automatizado para tratar de questões técnicas e de pessoal. Postel dirigiu a tarefa de forjar um compromisso entre cinco propostas concorrentes de soluções para Paul Mockapetris. Em vez disso, Mockapetris criou o Domain Name System em 1983 enquanto estava na University of Southern California.

A Internet Engineering Task Force publicou as especificações originais no RFC 882 e RFC 883 em novembro de 1983. Elas foram atualizadas no RFC 973 em janeiro de 1986.

Em 1984, quatro estudantes da UC Berkeley, Douglas Terry, Mark Painter, David Riggle e Songnian Zhou, escreveram a primeira implementação de servidor de nomes Unix para o Berkeley Internet Name Domain, comumente referido como BIND. Em 1985, Kevin Dunlap da DEC revisou substancialmente a implementação do DNS. Mike Karels, Phil Almquist e Paul Vixie assumiram a manutenção do BIND. O Internet Systems Consortium foi fundado em 1994 por Rick Adams, Paul Vixie e Carl Malamud, expressamente para fornecer um lar para o desenvolvimento e manutenção do BIND. Versões BIND de 4.9.3 em diante foram desenvolvidas e mantidas pelo ISC, com suporte fornecido pelos patrocinadores do ISC. Como co-arquitetos/programadores, Bob Halley e Paul Vixie lançaram a primeira versão pronta para produção do BIND versão 8 em maio de 1997. Desde 2000, mais de 43 desenvolvedores principais diferentes trabalharam no BIND.

Em novembro de 1987, RFC 1034 e RFC 1035 substituíram as especificações de DNS de 1983. Vários pedidos de comentários adicionais propuseram extensões para os protocolos DNS centrais.

Estrutura

Espaço de nome de domínio

O espaço de nome de domínio consiste em uma estrutura de dados em árvore. Cada nó ou folha na árvore tem um rótulo e zero ou mais registros de recursos (RR), que contêm informações associadas ao nome de domínio. O próprio nome de domínio consiste no rótulo, concatenado com o nome de seu nó pai à direita, separado por um ponto.

A árvore se subdivide em zonas começando na zona raiz. Uma zona DNS pode consistir em tantos domínios e subdomínios quantos o gerente de zona escolher. O DNS também pode ser particionado de acordo com a classe, onde as classes separadas podem ser consideradas como uma matriz de árvores de namespace paralelas.

O sistema hierárquico de nome de domínio para classe Internet, organizado em zonas, cada uma servida por um servidor de nomes

A responsabilidade administrativa por qualquer zona pode ser dividida criando zonas adicionais. Diz-se que a autoridade sobre a nova zona é delegada a um servidor de nomes designado. A zona pai deixa de ser autoritativa para a nova zona.

Sintaxe do nome de domínio, internacionalização

As descrições definitivas das regras para formar nomes de domínio aparecem em RFC 1035, RFC 1123, RFC 2181 e RFC 5892. Um nome de domínio consiste em uma ou mais partes, tecnicamente chamadas de rótulos, que são convencionalmente concatenados e delimitados por pontos, como exemplo.com.

O rótulo mais à direita transmite o domínio de nível superior; por exemplo, o nome de domínio www.example.com pertence ao domínio de nível superior com.

A hierarquia dos domínios desce da direita para a esquerda; cada rótulo à esquerda especifica uma subdivisão ou subdomínio do domínio à direita. Por exemplo, o rótulo exemplo especifica um subdomínio do domínio com e www é um subdomínio de exemplo.com. Esta árvore de subdivisões pode ter até 127 níveis.

Um rótulo pode conter de zero a 63 caracteres. O rótulo nulo, de comprimento zero, é reservado para a zona raiz. O nome de domínio completo não pode exceder o comprimento de 253 caracteres em sua representação textual. Na representação binária interna do DNS, o comprimento máximo requer 255 octetos de armazenamento, pois também armazena o comprimento do nome.

Embora não exista nenhuma limitação técnica para impedir que rótulos de nomes de domínio usem qualquer caractere que seja representável por um octeto, os nomes de host usam um formato e um conjunto de caracteres preferidos. Os caracteres permitidos nos rótulos são um subconjunto do conjunto de caracteres ASCII, consistindo nos caracteres a a z, A a Z, dígitos 0 a 9 e hífen. Esta regra é conhecida como regra LDH (letras, dígitos, hífen). Os nomes de domínio são interpretados de maneira independente de maiúsculas e minúsculas. Os rótulos não podem começar ou terminar com um hífen. Uma regra adicional exige que os nomes de domínio de nível superior não sejam totalmente numéricos.

O conjunto limitado de caracteres ASCII permitidos no DNS impedia a representação de nomes e palavras de muitos idiomas em seus alfabetos ou scripts nativos. Para tornar isso possível, a ICANN aprovou o sistema de internacionalização de nomes de domínio em aplicativos (IDNA), por meio do qual aplicativos de usuário, como navegadores da Web, mapeiam cadeias de caracteres Unicode no conjunto de caracteres DNS válido usando Punycode. Em 2009, a ICANN aprovou a instalação de domínios de primeiro nível com nomes de domínio internacionalizados (ccTLDs). Além disso, muitos registros dos nomes de domínio de primeiro nível (TLDs) existentes adotaram o sistema IDNA, guiado por RFC 5890, RFC 5891, RFC 5892, RFC 5893.

Servidores de nomes

O Domain Name System é mantido por um sistema de banco de dados distribuído, que usa o modelo cliente-servidor. Os nós desse banco de dados são os servidores de nomes. Cada domínio tem pelo menos um servidor DNS autoritativo que publica informações sobre esse domínio e os servidores de nomes de quaisquer domínios subordinados a ele. O topo da hierarquia é servido pelos servidores de nomes raiz, os servidores a serem consultados ao pesquisar (resolver) um TLD.

Servidor de nomes autorizado

Um servidor de nomes autoritário é um servidor de nomes que apenas fornece respostas a consultas DNS a partir de dados que foram configurados por uma fonte original, por exemplo, o administrador do domínio ou por métodos DNS dinâmicos, em contraste às respostas obtidas por meio de uma consulta a outro servidor de nomes que mantém apenas um cache de dados.

Um servidor de nomes autorizado pode ser um servidor principal ou um servidor secundário. Historicamente, os termos mestre/escravo e primário/secundário às vezes eram usados de forma intercambiável, mas a prática atual é usar a última forma. Um servidor primário é um servidor que armazena as cópias originais de todos os registros de zona. Um servidor secundário usa um mecanismo especial de atualização automática no protocolo DNS em comunicação com seu primário para manter uma cópia idêntica dos registros primários.

Cada zona DNS deve receber um conjunto de servidores de nomes autorizados. Esse conjunto de servidores é armazenado na zona de domínio pai com registros de servidor de nomes (NS).

Um servidor autoritativo indica seu status de fornecer respostas definitivas, consideradas autoritativas, definindo um sinalizador de protocolo, chamado de "Resposta autoritativa" (AA) bit em suas respostas. Esse sinalizador geralmente é reproduzido com destaque na saída das ferramentas de consulta de administração de DNS, como dig, para indicar que o servidor de nomes que responde é uma autoridade para o nome de domínio em questão.

Quando um servidor de nomes é designado como servidor autoritativo para um nome de domínio para o qual não possui dados autoritativos, ele apresenta um tipo de erro chamado "delegação lame" ou "resposta esfarrapada".

Operação

Mecanismo de resolução de endereços

Os resolvedores de nomes de domínio determinam os servidores de nomes de domínio responsáveis pelo nome de domínio em questão por uma sequência de consultas começando com o rótulo de domínio mais à direita (nível superior).

Um resolver DNS que implementa a abordagem iterativa mandatada pelo RFC 1034; neste caso, o resolver consulta três servidores de nomes para resolver o nome de domínio totalmente qualificado "www.wikipedia.org".

Para a operação adequada de seu resolvedor de nomes de domínio, um host de rede é configurado com um cache inicial (dicas) dos endereços conhecidos dos servidores de nomes raiz. As dicas são atualizadas periodicamente por um administrador recuperando um conjunto de dados de uma fonte confiável.

Supondo que o resolvedor não tenha registros em cache para acelerar o processo, o processo de resolução começa com uma consulta a um dos servidores raiz. Em operação típica, os servidores raiz não respondem diretamente, mas respondem com uma referência a servidores mais confiáveis, por exemplo, uma consulta para "www.wikipedia.org" é referido aos servidores org. O resolvedor agora consulta os servidores referidos e repete iterativamente esse processo até receber uma resposta autoritativa. O diagrama ilustra esse processo para o host nomeado pelo nome de domínio totalmente qualificado "www.wikipedia.org".

Esse mecanismo colocaria uma grande carga de tráfego nos servidores raiz, se todas as resoluções na Internet exigissem começar na raiz. Na prática, o cache é usado em servidores DNS para descarregar os servidores raiz e, como resultado, os servidores de nomes raiz realmente estão envolvidos em apenas uma fração relativamente pequena de todas as solicitações.

Servidor de nomes recursivo e em cache

Em teoria, os servidores de nomes autorizados são suficientes para a operação da Internet. No entanto, com apenas servidores de nome autorizados operando, cada consulta DNS deve começar com consultas recursivas na zona raiz do Sistema de Nomes de Domínio e cada sistema de usuário teria que implementar um software resolvedor capaz de operação recursiva.

Para melhorar a eficiência, reduzir o tráfego DNS na Internet e aumentar o desempenho em aplicativos de usuário final, o Domain Name System oferece suporte a servidores de cache DNS que armazenam resultados de consulta DNS por um período de tempo determinado na configuração (tempo -to-live) do registro de nome de domínio em questão. Normalmente, esses servidores DNS de cache também implementam o algoritmo recursivo necessário para resolver um determinado nome começando com a raiz DNS até os servidores de nomes autorizados do domínio consultado. Com essa função implementada no servidor de nomes, os aplicativos do usuário ganham eficiência em design e operação.

A combinação de cache DNS e funções recursivas em um servidor de nomes não é obrigatória; as funções podem ser implementadas independentemente em servidores para fins especiais.

Provedores de serviços de Internet normalmente fornecem servidores de nome recursivos e de cache para seus clientes. Além disso, muitos roteadores de rede doméstica implementam caches DNS e recursão para melhorar a eficiência na rede local.

Resolvedores de DNS

O lado do cliente do DNS é chamado de resolvedor de DNS. Um resolvedor é responsável por iniciar e sequenciar as consultas que levam a uma resolução completa (tradução) do recurso procurado, por exemplo, tradução de um nome de domínio em um endereço IP. Os resolvedores de DNS são classificados por vários métodos de consulta, como recursivo, não recursivo e iterativo. Um processo de resolução pode usar uma combinação desses métodos.

Em uma consulta não recursiva, um resolvedor DNS consulta um servidor DNS que fornece um registro para o qual o servidor é autoritativo ou fornece um resultado parcial sem consultar outros servidores. No caso de um resolvedor DNS de cache, a consulta não recursiva de seu cache DNS local fornece um resultado e reduz a carga nos servidores DNS upstream armazenando em cache os registros de recursos DNS por um período de tempo após uma resposta inicial dos servidores DNS upstream.

Em uma consulta recursiva, um resolvedor DNS consulta um único servidor DNS, que por sua vez pode consultar outros servidores DNS em nome do solicitante. Por exemplo, um resolvedor de stub simples executado em um roteador doméstico geralmente faz uma consulta recursiva ao servidor DNS executado pelo ISP do usuário. Uma consulta recursiva é aquela para a qual o servidor DNS responde à consulta completamente, consultando outros servidores de nomes conforme necessário. Em operação típica, um cliente emite uma consulta recursiva para um servidor DNS recursivo de cache, que subseqüentemente emite consultas não recursivas para determinar a resposta e enviar uma única resposta de volta ao cliente. O resolvedor, ou outro servidor DNS agindo recursivamente em nome do resolvedor, negocia o uso do serviço recursivo usando bits nos cabeçalhos de consulta. Os servidores DNS não são necessários para oferecer suporte a consultas recursivas.

O procedimento de consulta iterativa é um processo no qual um resolvedor DNS consulta uma cadeia de um ou mais servidores DNS. Cada servidor encaminha o cliente para o próximo servidor na cadeia, até que o servidor atual possa resolver totalmente a solicitação. Por exemplo, uma possível resolução de www.example.com consultaria um servidor raiz global e, em seguida, um "com" servidor e, finalmente, um "example.com" servidor.

Dependências circulares e registros cola

Os servidores de nomes nas delegações são identificados pelo nome, e não pelo endereço IP. Isso significa que um servidor de nomes de resolução deve emitir outra solicitação de DNS para descobrir o endereço IP do servidor ao qual foi encaminhado. Se o nome fornecido na delegação for um subdomínio do domínio para o qual a delegação está sendo fornecida, haverá uma dependência circular.

Nesse caso, o servidor de nomes que fornece a delegação também deve fornecer um ou mais endereços IP para o servidor de nomes autorizado mencionado na delegação. Esta informação é chamada de cola. O servidor de nomes de delegação fornece essa cola na forma de registros na seção adicional da resposta DNS e fornece a delegação na seção de autoridade da resposta. Um registro cola é uma combinação do servidor de nomes e endereço IP.

Por exemplo, se o servidor de nomes autorizado para example.org for ns1.example.org, um computador tentando resolver www.example.org primeiro resolve ns1.example.org. Como ns1 está contido em example.org, isso requer a resolução de example.org primeiro, que apresenta uma dependência circular. Para quebrar a dependência, o servidor de nomes para o domínio de nível superior org inclui cola junto com a delegação para example.org. Os registros cola são registros de endereços que fornecem endereços IP para ns1.example.org. O resolvedor usa um ou mais desses endereços IP para consultar um dos servidores autoritativos do domínio, o que permite concluir a consulta de DNS.

Cache de registro

Uma prática padrão na implementação da resolução de nomes em aplicativos é reduzir a carga nos servidores do Sistema de Nomes de Domínio armazenando em cache os resultados localmente ou em hosts de resolução intermediários. Os resultados obtidos de uma solicitação de DNS estão sempre associados ao time to live (TTL), um tempo de expiração após o qual os resultados devem ser descartados ou atualizados. O TTL é definido pelo administrador do servidor DNS autoritativo. O período de validade pode variar de alguns segundos a dias ou até semanas.

Como resultado dessa arquitetura de cache distribuído, as alterações nos registros DNS não se propagam pela rede imediatamente, mas exigem que todos os caches expirem e sejam atualizados após o TTL. A RFC 1912 transmite regras básicas para determinar os valores TTL apropriados.

Alguns resolvedores podem substituir os valores de TTL, pois o protocolo suporta cache por até sessenta e oito anos ou nenhum cache. O cache negativo, ou seja, o cache do fato da inexistência de um registro, é determinado pelos servidores de nomes com autoridade para uma zona que deve incluir o registro Start of Authority (SOA) quando relatar que não existem dados do tipo solicitado. O valor do campo mínimo do registro SOA e o TTL do próprio SOA são usados para estabelecer o TTL para a resposta negativa.

Pesquisa reversa

Uma pesquisa DNS reversa é uma consulta do DNS para nomes de domínio quando o endereço IP é conhecido. Vários nomes de domínio podem estar associados a um endereço IP. O DNS armazena endereços IP na forma de nomes de domínio como nomes especialmente formatados em registros de ponteiro (PTR) dentro do domínio de nível superior da infraestrutura arpa. Para IPv4, o domínio é in-addr.arpa. Para IPv6, o domínio de pesquisa inversa é ip6.arpa. O endereço IP é representado como um nome na representação de octetos ordenados inversamente para IPv4 e representação de nibbles ordenados inversamente para IPv6.

Ao realizar uma pesquisa reversa, o cliente DNS converte o endereço nesses formatos antes de consultar o nome de um registro PTR seguindo a cadeia de delegação como em qualquer consulta DNS. Por exemplo, supondo que o endereço IPv4 208.80.152.2 seja atribuído à Wikimedia, ele é representado como um nome DNS na ordem inversa: 2.152.80.208.in-addr.arpa. Quando o resolvedor de DNS obtém uma solicitação de ponteiro (PTR), ele começa consultando os servidores raiz, que apontam para os servidores do Registro Americano de Números da Internet (ARIN) para a zona 208.in-addr.arpa. Os servidores do ARIN delegam 152.80.208.in-addr.arpa à Wikimedia, para a qual o resolvedor envia outra consulta para 2.152.80.208.in-addr.arpa, que resulta em uma resposta autorizada.

Pesquisa do cliente

Sequência de resolução DNS

Os usuários geralmente não se comunicam diretamente com um resolvedor de DNS. Em vez disso, a resolução de DNS ocorre de forma transparente em aplicativos como navegadores da Web, clientes de e-mail e outros aplicativos da Internet. Quando um aplicativo faz uma solicitação que requer uma pesquisa de nome de domínio, esses programas enviam uma solicitação de resolução ao resolvedor de DNS no sistema operacional local, que, por sua vez, lida com as comunicações necessárias.

O resolvedor de DNS quase invariavelmente terá um cache (veja acima) contendo pesquisas recentes. Se o cache puder fornecer a resposta à solicitação, o resolvedor retornará o valor no cache para o programa que fez a solicitação. Se o cache não contiver a resposta, o resolvedor enviará a solicitação para um ou mais servidores DNS designados. No caso da maioria dos usuários domésticos, o provedor de serviços de Internet ao qual a máquina se conecta normalmente fornecerá esse servidor DNS: esse usuário terá configurado o endereço desse servidor manualmente ou permitido que o DHCP o configure; no entanto, onde os administradores de sistemas configuraram sistemas para usar seus próprios servidores DNS, seus resolvedores de DNS apontam para servidores de nomes mantidos separadamente da organização. Em qualquer caso, o servidor de nomes assim consultado seguirá o processo descrito acima, até encontrar um resultado com sucesso ou não. Em seguida, ele retorna seus resultados ao resolvedor de DNS; assumindo que encontrou um resultado, o resolvedor armazena devidamente esse resultado em cache para uso futuro e devolve o resultado ao software que iniciou a solicitação.

Resolvedores quebrados

Alguns grandes ISPs configuraram seus servidores DNS para violar regras, como desobedecer TTLs ou indicar que um nome de domínio não existe apenas porque um de seus servidores de nomes não responde.

Alguns aplicativos, como navegadores da Web, mantêm um cache DNS interno para evitar pesquisas repetidas pela rede. Essa prática pode adicionar dificuldade extra ao depurar problemas de DNS, pois obscurece o histórico de tais dados. Esses caches geralmente usam tempos de cache muito curtos, da ordem de um minuto.

O Internet Explorer representa uma exceção notável: as versões até o IE 3.x armazenam em cache os registros DNS por 24 horas por padrão. Internet Explorer 4.xe versões posteriores (até IE 8) diminuem o valor de tempo limite padrão para meia hora, que pode ser alterado modificando a configuração padrão.

Quando o Google Chrome detecta problemas com o servidor DNS, ele exibe uma mensagem de erro específica.

Outras aplicações

O Domain Name System inclui várias outras funções e recursos.

Nomes de host e endereços IP não precisam corresponder em um relacionamento um para um. Vários nomes de host podem corresponder a um único endereço IP, o que é útil em hospedagem virtual, na qual muitos sites da Web são servidos a partir de um único host. Como alternativa, um único nome de host pode resolver vários endereços IP para facilitar a tolerância a falhas e a distribuição de carga para várias instâncias de servidor em uma empresa ou na Internet global.

O DNS serve a outros propósitos além de traduzir nomes em endereços IP. Por exemplo, agentes de transferência de correio usam DNS para encontrar o melhor servidor de correio para entregar e-mail: Um registro MX fornece um mapeamento entre um domínio e um trocador de correio; isso pode fornecer uma camada adicional de tolerância a falhas e distribuição de carga.

O DNS é usado para armazenamento e distribuição eficientes de endereços IP de hosts de e-mail na lista negra. Um método comum é colocar o endereço IP do host em questão no subdomínio de um nome de domínio de nível superior e resolver esse nome para um registro que indique uma indicação positiva ou negativa.

Por exemplo:

• O endereço 102.3.4.5 está na lista negra. Ele aponta para 5.4.3.102.blacklist.example, que resolve para 127.0.0.1.
• O endereço 102.3.4.6 não é lista negra e aponta para 6.4.3.102.blacklist.example. Este nome de host não está configurado ou resolve para 127.0.0.2.

Servidores de e-mail podem consultar blacklist.example para descobrir se um host específico conectado a eles está na lista negra. Muitas dessas listas negras, baseadas em assinatura ou gratuitas, estão disponíveis para uso por administradores de e-mail e software anti-spam.

Para fornecer resiliência em caso de falha do computador ou da rede, vários servidores DNS geralmente são fornecidos para cobrir cada domínio. No nível superior do DNS global, existem treze grupos de servidores de nomes raiz, com "cópias" deles distribuídos mundialmente via endereçamento anycast.

Dynamic DNS (DDNS) atualiza um servidor DNS com um endereço IP do cliente em tempo real, por exemplo, ao se mover entre ISPs ou pontos de acesso móveis ou quando o endereço IP muda administrativamente.

Formato de mensagem DNS

O protocolo DNS usa dois tipos de mensagens DNS, consultas e respostas; ambos têm o mesmo formato. Cada mensagem consiste em um cabeçalho e quatro seções: pergunta, resposta, autoridade e um espaço adicional. Um campo de cabeçalho (flags) controla o conteúdo dessas quatro seções.

A seção de cabeçalho consiste nos seguintes campos: Identificação, Sinalizadores, Número de perguntas, Número de respostas, Número de registros de recursos de autoridade (RRs) e Número de RRs adicionais. Cada campo tem 16 bits de comprimento e aparece na ordem dada. O campo de identificação é usado para corresponder respostas com consultas. O campo sinalizador consiste em subcampos como segue:

Após o sinalizador, o cabeçalho termina com quatro inteiros de 16 bits que contêm o número de registros em cada uma das seções a seguir, na mesma ordem.

Seção de perguntas

A seção de perguntas tem um formato mais simples do que o formato de registro de recursos usado nas outras seções. Cada registro de pergunta (geralmente há apenas um na seção) contém os seguintes campos:

O nome de domínio é dividido em rótulos discretos que são concatenados; cada rótulo é prefixado pelo comprimento desse rótulo.

Registros de recursos

O Domain Name System especifica um banco de dados de elementos de informação para recursos de rede. Os tipos de elementos de informação são categorizados e organizados com uma lista de tipos de registro DNS, os registros de recursos (RRs). Cada registro tem um tipo (nome e número), um tempo de expiração (time to live), uma classe e dados específicos do tipo. Registros de recursos do mesmo tipo são descritos como um conjunto de registros de recursos (RRset), sem ordem especial. Os resolvedores de DNS retornam todo o conjunto após a consulta, mas os servidores podem implementar a ordem round-robin para obter o balanceamento de carga. Por outro lado, as extensões de segurança do sistema de nomes de domínio (DNSSEC) funcionam no conjunto completo de registros de recursos em ordem canônica.

Quando enviados por uma rede de Protocolo de Internet, todos os registros usam o formato comum especificado no RFC 1035:

NAME é o nome de domínio totalmente qualificado do nó na árvore. Na conexão, o nome pode ser abreviado usando compactação de rótulo, onde as extremidades dos nomes de domínio mencionados anteriormente no pacote podem ser substituídas pelo final do nome de domínio atual.

TYPE é o tipo de registro. Ele indica o formato dos dados e dá uma dica de seu uso pretendido. Por exemplo, o registro A é usado para traduzir de um nome de domínio para um endereço IPv4, o registro NS lista quais servidores de nomes podem responder a pesquisas em uma zona DNS e o registro O registro MX especifica o servidor de e-mail usado para lidar com e-mail para um domínio especificado em um endereço de e-mail.

RDATA são dados de relevância específica do tipo, como o endereço IP para registros de endereço ou a prioridade e o nome do host para registros MX. Tipos de registro bem conhecidos podem usar compactação de rótulo no campo RDATA, mas "desconhecido" os tipos de registro não devem (RFC 3597).

A CLASS de um registro é definida como IN (para Internet) para registros DNS comuns envolvendo nomes de host da Internet, servidores ou endereços IP. Além disso, existem as classes Chaos (CH) e Hesiod (HS). Cada classe é um espaço de nome independente com delegações potencialmente diferentes de zonas DNS.

Além dos registros de recursos definidos em um arquivo de zona, o sistema de nome de domínio também define vários tipos de solicitação que são usados apenas na comunicação com outros nós DNS (on the wire), como ao executar transferências de zona (AXFR/IXFR) ou para EDNS (OPT).

Registros curinga

O sistema de nome de domínio suporta registros DNS curinga que especificam nomes que começam com o rótulo de asterisco, '*', por exemplo, *.example. Os registros DNS pertencentes a nomes de domínio curinga especificam regras para gerar registros de recursos em uma única zona DNS, substituindo rótulos inteiros por componentes correspondentes do nome da consulta, incluindo quaisquer descendentes especificados. Por exemplo, na configuração a seguir, a zona DNS x.example especifica que todos os subdomínios, incluindo subdomínios de subdomínios, de x.example usam o trocador de correio (MX) a.x.exemplo. O registro A para a.x.example é necessário para especificar o endereço IP do trocador de e-mail. Como isso tem como resultado a exclusão deste nome de domínio e seus subdomínios das correspondências curinga, um registro MX adicional para o subdomínio a.x.example, bem como um registro MX curinga para todos os seus subdomínios, também deve ser definido na zona DNS.

x.example. MX 10 a.x.example.
*.x.example. MX 10 a.x.example.
*.a.x.example. MX 10 a.x.example.
A.x.example. MX 10 a.x.example.
A.x.example. AAAA 2001:

A função dos registros curinga foi refinada na RFC 4592, porque a definição original na RFC 1034 estava incompleta e resultava em interpretações incorretas pelos implementadores.

Extensões de protocolo

O protocolo DNS original tinha provisões limitadas para extensão com novos recursos. Em 1999, Paul Vixie publicou no RFC 2671 (substituído pelo RFC 6891) um mecanismo de extensão, chamado Extension Mechanisms for DNS (EDNS), que introduziu elementos de protocolo opcionais sem aumentar a sobrecarga quando não estava em uso. Isso foi realizado por meio do registro de pseudo-recurso OPT que existe apenas em transmissões por fio do protocolo, mas não em nenhum arquivo de zona. Extensões iniciais também foram sugeridas (EDNS0), como aumentar o tamanho da mensagem DNS em datagramas UDP.

Atualizações de zona dinâmica

Atualizações dinâmicas de DNS usam o opcode UPDATE DNS para adicionar ou remover registros de recursos dinamicamente de um banco de dados de zona mantido em um servidor DNS autorizado. O recurso é descrito no RFC 2136. Esse recurso é útil para registrar clientes de rede no DNS quando eles inicializam ou se tornam disponíveis na rede. Como um cliente de inicialização pode receber um endereço IP diferente a cada vez de um servidor DHCP, não é possível fornecer atribuições de DNS estático para esses clientes.

Protocolos de transporte

Desde sua origem em 1983, o DNS tem usado o User Datagram Protocol (UDP) para transporte sobre IP. Suas limitações motivaram inúmeros desenvolvimentos de protocolos para confiabilidade, segurança, privacidade e outros critérios, nas décadas seguintes.

DNS sobre UDP/53 (Do53)

O UDP reserva a porta número 53 para servidores que ouvem consultas. Tais consultas consistem em um pedido de texto claro enviado em um único pacote UDP do cliente, respondeu com uma resposta de texto clara enviada em um único pacote UDP do servidor. Quando o comprimento da resposta exceder 512 bytes e suporte ao cliente e servidor Mecanismos de extensão para DNS (EDNS), pacotes UDP maiores podem ser usados. O uso de DNS sobre UDP é limitado por, entre outras coisas, sua falta de criptografia de camada de transporte, autenticação, entrega confiável e comprimento da mensagem.

DNS sobre TCP/53 (Do53/TCP)

Em 1989, o RFC 1123 especificou o transporte opcional do Protocolo de Controle de Transmissão (TCP) para consultas, respostas e, particularmente, transferências de zona. Através da fragmentação de respostas longas, o TCP permite respostas mais longas, entrega confiável e reutilização de conexões de longa duração entre clientes e servidores.

DNS sobre TLS (DoT)

DNS sobre TLS surgiu como um padrão IETF para DNS criptografado em 2016, utilizando Transport Layer Security (TLS) para proteger toda a conexão, em vez de apenas a carga de DNS. Os servidores DoT ouvem na porta TCP 853. O RFC 7858 especifica que a criptografia oportunista e a criptografia autenticada podem ser suportadas, mas não fez a autenticação de servidor ou cliente obrigatória.

DNS sobre HTTPS (DoH)

O DNS sobre HTTPS foi desenvolvido como um padrão concorrente para o transporte de consultas DNS em 2018, túnel dados de consulta DNS sobre HTTPS, que transporta HTTP sobre TLS. O DoH foi promovido como uma alternativa mais amigável para o DNS desde que, como DNSCrypt, ele usa a porta TCP 443, e assim parece semelhante ao tráfego web, embora eles sejam facilmente diferenciados na prática. DoH tem sido amplamente criticado por diminuir o anonimato do usuário em relação ao DoT.

DNS Oblivious (ODNS) e DoH Oblivious (ODoH)

DNS Oblivious (ODNS) foi inventado e implementado por pesquisadores na Universidade de Princeton e na Universidade de Chicago como uma extensão para DNS não criptografado, antes de DoH foi padronizado e amplamente implantado. A Apple e o Cloudflare posteriormente implantaram a tecnologia no contexto do DoH, como Oblivious DoH (ODoH). ODoH combina separação de entrada/egresso (inventado em ODNS) com o túnel HTTPS da DoH e criptografia de camada de transporte TLS em um único protocolo.

DNS sobre TOR

O DNS pode ser executado em redes privadas virtuais (VPNs) e protocolos de túnel. Um uso que se tornou comum desde 2019 para justificar seu próprio acrônimo frequentemente usado é DNS sobre Tor. Os ganhos de privacidade de DNS Oblivious podem ser adquiridos através do uso da rede Tor pré-existente de nós de entrada e saída, emparelhado com a criptografia de camada de transporte fornecida pela TLS.

DNS sobre QUIC (DoQ)

O RFC 9250 da Força-Tarefa de Engenharia da Internet descreve o DNS sobre o QUIC.

DNSCrypt

O protocolo DNSCrypt, que foi desenvolvido em 2011 fora da estrutura de padrões IETF, introduziu criptografia DNS no lado a jusante de resolvers recursivos, em que os clientes criptografam cargas de consulta usando chaves públicas dos servidores, que são publicados no DNS (em vez de confiar em autoridades de certificados de terceiros) e que podem, por sua vez, ser protegidos por assinaturas DNSSEC. O DNSCrypt usa a porta 443 TCP ou UDP, a mesma porta que o tráfego web criptografado HTTPS. Isso introduziu não apenas a privacidade em relação ao conteúdo da consulta, mas também uma medida significativa da capacidade do firewall-traversal. Em 2019, DNSCrypt foi ampliado para suportar um modo "anonimizado", semelhante ao proposto "Oblivious DNS", no qual um nó de entrada recebe uma consulta que foi criptografada com a chave pública de um servidor diferente, e a transmite para esse servidor, que atua como um nó de progresso, executando a resolução recursiva. A privacidade dos pares de usuário/query é criada, uma vez que o nó de entrada não conhece o conteúdo da consulta, enquanto os nós de egress não conhece a identidade do cliente. O DNSCrypt foi implementado pela primeira vez na produção pela OpenDNS em dezembro de 2011. Existem várias implementações de software livre e de código aberto que também integram ODoH. Está disponível para uma variedade de sistemas operacionais, incluindo Unix, Apple iOS, Linux, Android e MS Windows.

Problemas de segurança

Originalmente, as preocupações com a segurança não eram considerações de design importantes para o software DNS ou qualquer software para implantação na Internet antiga, pois a rede não estava aberta para participação do público em geral. No entanto, a expansão da Internet para o setor comercial na década de 1990 mudou os requisitos de medidas de segurança para proteger a integridade dos dados e a autenticação do usuário.

Vários problemas de vulnerabilidade foram descobertos e explorados por usuários mal-intencionados. Um desses problemas é o envenenamento de cache de DNS, no qual os dados são distribuídos para os resolvedores de cache sob o pretexto de ser um servidor de origem autorizado, poluindo assim o armazenamento de dados com informações potencialmente falsas e longos tempos de expiração (time-to-live). Posteriormente, solicitações de aplicativos legítimos podem ser redirecionadas para hosts de rede operados com intenção maliciosa.

As respostas DNS tradicionalmente não possuem uma assinatura criptográfica, levando a muitas possibilidades de ataque; as Extensões de Segurança do Sistema de Nomes de Domínio (DNSSEC) modificam o DNS para adicionar suporte para respostas assinadas criptograficamente. DNSCurve foi proposto como uma alternativa ao DNSSEC. Outras extensões, como TSIG, adicionam suporte para autenticação criptográfica entre pares confiáveis e são comumente usadas para autorizar a transferência de zona ou operações de atualização dinâmica.

Alguns nomes de domínio podem ser usados para obter efeitos de falsificação. Por exemplo, paypal.com e paypa1.com são nomes diferentes, mas os usuários pode ser incapaz de distingui-los em uma interface gráfica do usuário, dependendo do tipo de letra escolhido pelo usuário. Em muitas fontes, a letra l e o numeral 1 parecem muito semelhantes ou mesmo idênticos. Esse problema é agudo em sistemas que oferecem suporte a nomes de domínio internacionalizados, pois muitos códigos de caracteres no ISO 10646 podem parecer idênticos em telas de computador típicas. Esta vulnerabilidade é ocasionalmente explorada em phishing.

Técnicas como DNS reverso confirmado pelo encaminhamento também podem ser usadas para ajudar a validar os resultados do DNS.

DNS também pode "vazar" de conexões seguras ou privadas, se não for dada atenção à sua configuração e, às vezes, o DNS foi usado para contornar firewalls por pessoas mal-intencionadas e exfiltrar dados, pois geralmente são vistos como inócuos.

Problemas de privacidade e rastreamento

Originalmente projetado como um banco de dados público, hierárquico, distribuído e altamente armazenado em cache, o protocolo DNS não possui controles de confidencialidade. As consultas do usuário e as respostas do servidor de nomes estão sendo enviadas sem criptografia, o que permite a detecção de pacotes de rede, sequestro de DNS, envenenamento de cache de DNS e ataques man-in-the-middle. Essa deficiência é comumente usada por cibercriminosos e operadores de rede para fins de marketing, autenticação de usuários em portais cativos e censura.

A privacidade do usuário é ainda mais exposta por propostas para aumentar o nível de informações de IP do cliente em consultas DNS (RFC 7871) para o benefício das redes de distribuição de conteúdo.

As principais abordagens usadas para combater os problemas de privacidade com o DNS:

• VPNs, que movem a resolução de DNS para o operador VPN e escondem o tráfego de usuários do ISP local,
• Tor, que substitui a resolução DNS tradicional por domínios anônimos.onion, escondendo a resolução de ambos os nomes e o tráfego do usuário por trás da contra-reunião de roteamento de cebola,
• Proxies e servidores DNS públicos, que movem a resolução DNS real para um provedor de terceiros, que geralmente promete pouco ou nenhum registro de solicitação e recursos adicionais opcionais, tais como anúncios de nível DNS ou bloqueio de pornografia.
  • Servidores DNS públicos podem ser consultados usando protocolo DNS tradicional, em que caso eles não fornecem proteção contra vigilância local, ou DNS sobre HTTPS, DNS sobre TLS e DNSCrypt, que fornecem tal proteção

Soluções que impedem a inspeção de DNS por operadora de rede local são criticadas por frustrar políticas de segurança de rede corporativa e censura na Internet. Eles também são criticados do ponto de vista da privacidade, por entregarem a resolução do DNS nas mãos de um pequeno número de empresas conhecidas por monetizar o tráfego de usuários e por centralizar a resolução de nomes do DNS, que geralmente é vista como prejudicial para a Internet.

O Google é o fornecedor dominante da plataforma no Android, o navegador no Chrome e o resolver DNS no serviço 8.8.8.8.8. Este cenário seria um caso de uma única entidade corporativa estar em uma posição de overarching control de todo o namespace da Internet? A Netflix já usou um aplicativo que usou seu próprio mecanismo de resolução DNS independente da plataforma em que o aplicativo estava executando. E se o aplicativo Facebook incluiu DoH? E se o iOS da Apple usou um mecanismo de resolução DoH para contornar a resolução DNS local e direcionar todas as consultas DNS das plataformas da Apple para um conjunto de resolvedores de nomes operados pela Apple?

—Privacidade DNS e IETF

Registro de nome de domínio

O direito de usar um nome de domínio é delegado por registradores de nomes de domínio que são credenciados pela Internet Corporation for Assigned Names and Numbers (ICANN) ou outras organizações, como a OpenNIC, encarregadas de supervisionar os sistemas de nomes e números do Internet. Além da ICANN, cada domínio de primeiro nível (TLD) é mantido e atendido tecnicamente por uma organização administrativa, operando um registro. Um registro é responsável por operar o banco de dados de nomes dentro de sua zona de autoridade, embora o termo seja usado com mais frequência para TLDs. Um registrante é uma pessoa ou organização que solicitou o registro de domínio. O registro recebe as informações cadastrais de cada registrador de nome de domínio, que está autorizado (credenciado) a atribuir nomes na zona correspondente e publica as informações usando o protocolo WHOIS. A partir de 2015, o uso de RDAP está sendo considerado.

ICANN publica a lista completa de TLDs, registros de TLDs e registradores de nomes de domínio. As informações do registrante associadas aos nomes de domínio são mantidas em um banco de dados online acessível com o serviço WHOIS. Para a maioria dos mais de 290 domínios de primeiro nível com código de país (ccTLDs), os registros de domínio mantêm as informações WHOIS (Registrante, servidores de nome, datas de expiração, etc.). Por exemplo, DENIC, Alemanha NIC, detém os dados do domínio DE. Por volta de 2001, a maioria dos registros de domínios genéricos de primeiro nível (gTLDs) adotaram a chamada abordagem de registro thick, ou seja, mantendo os dados WHOIS em registros centrais em vez de bancos de dados de registradores.

Para domínios de nível superior em COM e NET, um modelo de registro thin é usado. O registro de domínio (por exemplo, GoDaddy, BigRock e PDR, VeriSign, etc., etc.) contém dados WHOIS básicos (ou seja, registradores e servidores de nomes, etc.). As organizações ou registrantes que usam ORG, por outro lado, estão exclusivamente no Registro de Interesse Público.

Alguns registros de nomes de domínio, geralmente chamados de centros de informações de rede (NIC), também funcionam como registradores para usuários finais, além de fornecer acesso aos conjuntos de dados WHOIS. Os registros de domínio de nível superior, como os domínios COM, NET e ORG, usam um modelo de registrador de registro que consiste em vários registradores de nomes de domínio. Nesse método de gerenciamento, o registro gerencia apenas o banco de dados de nomes de domínio e o relacionamento com os registradores. Os registrantes (usuários de um nome de domínio) são clientes do registrador, em alguns casos por meio de subcontratação adicional de revendedores.

Documentos RFC

O Domain Name System é definido por documentos Request for Comments (RFC) publicados pela Internet Engineering Task Force (padrões da Internet). A seguir está uma lista de RFCs que definem o protocolo DNS.

Trilha padrão

• RFC 1034, Nomes de Domínio - Conceitos e Instalações
• RFC 1035, Nomes de Domínio - Implementação e Especificação
• RFC 1123, Requisitos para Anfitriões da Internet — Aplicação e Suporte
• RFC 1995 Transferência de Zona Incremental no DNS
• RFC 1996, Um Mecanismo para Notificação Prompt de Mudanças de Zona (DNS NOTIFY)
• RFC 2136, Atualizações dinâmicas no sistema de nomes de domínio (DNS UPDATE)
• RFC 2181, Clarificações à especificação DNS
• RFC 2308, Cache negativo de consultas DNS (DNS NCACHE)
• RFC 2672, DNS não-Terminal Nome Redirecionamento
• RFC 2845, Autenticidade de Transação Secreta para DNS (TSIG)
• RFC 3225, Resolução de Indicação Suporte de DNSSEC
• RFC 3226, DNSSEC e IPv6 A6 requisitos de tamanho do servidor/resolver mensagem
• RFC 3596, Extensões de DNS para Suporte à Versão IP 6
• RFC 3597, Manipulação de Tipos de Registro de Recursos DNS Desconhecidos (RR)
• RFC 4343, Sistema de Nome de Domínio (DNS)
• RFC 4592, O papel dos Wildcards no sistema de nomes de domínio
• RFC 4635, Identificadores de Algoritmo HMAC SHA TSIG
• RFC 5001, DNS Nome Servidor Identifier (NSID) Opção
• RFC 5011, Atualizações automatizadas de DNS Security (DNSSEC) Trust Anchors
• RFC 5452, Medidas para fazer DNS Mais resistente contra respostas forjadas
• RFC 5890, Nomes de Domínio Internacionalizados para Aplicações (IDNA):Definições e Quadro de Documentos
• RFC 5891, Nomes de Domínio Internacionalizados em Aplicações (IDNA): Protocolo
• RFC 5892, Os Pontos de Código Unicode e Nomes de Domínio Internacionalizados para Aplicações (IDNA)
• RFC 5893, Scripts de direita para esquerda para nomes de domínio internacionalizado para aplicações (IDNA)
• RFC 6891, Mecanismos de extensão para DNS (EDNS0)
• RFC 7766, Transporte DNS sobre TCP - Requisitos de Implementação

Padrões de segurança propostos

• RFC 4033, Introdução e Requisitos de Segurança DNS
• RFC 4034, Registros de recursos para as extensões de segurança DNS
• RFC 4035, Modificações de protocolo para as extensões de segurança DNS
• RFC 4509, Uso de SHA-256 em DNSSEC Delegation Signer (DS) Resource Records
• RFC 4470, Cobertura minimamente NSEC Records e DNSSEC On-line Signing
• RFC 5155, Segurança DNS (DNSSEC) Hashed Denial autenticado da existência
• RFC 5702, Uso de algoritmos SHA-2 com RSA em DNSKEY e Registros de Recursos RRSIG para DNSSEC
• RFC 5910, Sistema de Nomes de Domínio (DNS) Mapeamento de Extensões de Segurança para o Protocolo de Provisão Extensível (EPP)
• RFC 5933, Uso de algoritmos de assinatura GOST em DNSKEY e registros de recursos RRSIG para DNSSEC
• RFC 7830, O EDNS(0) Opção de Padding
• RFC 7858, Especificação para DNS sobre Transport Layer Security (TLS)
• RFC 8310, Perfis de uso para DNS sobre TLS e DNS sobre DTLS
• RFC 8484, Perguntas de DNS sobre HTTPS (DoH)

RFCs experimentais

• RFC 1183, Novas definições de RR DNS

Melhores práticas atuais

• RFC 2182, Seleção e Operação de Servidores DNS Secundários (BCP 16)
• RFC 2317, Delegação IN-ADDR.ARPA sem classes (BCP 20)
• RFC 5625, Orientações de implementação de Proxy DNS (BCP 152)
• RFC 6895, Considerações do Sistema de Nomes de Domínio (DNS) IANA (BCP 42)
• RFC 7720, Requisitos de Protocolo e Implementação de Nome de Raiz DNS (BCP 40)

RFCs informativos

Esses RFCs são de natureza consultiva, mas podem fornecer informações úteis, apesar de não definirem um padrão ou BCP. (RFC 1796)

• RFC 1178, Escolhendo um nome para o seu computador (FYI)
• RFC 1591, Estrutura e Delegação do Sistema de Nome de Domínio
• RFC 1912, DNS comum Erros operacionais e de configuração
• RFC 2100, O nome dos anfitriões
• RFC 3696, Técnicas de Aplicação para Verificação e Transformação de Nomes
• RFC 3833. Análise da ameaça do sistema de nome de domínio (DNS)
• RFC 4892, Requisitos para um Mecanismo Identificar uma instância do Servidor de Nome
• RFC 5894, Nomes de Domínio Internacionalizados para Aplicações (IDNA):Banco, Explicação e Racional
• RFC 5895, Mapeamento de caracteres para nomes de domínio internacionalizados em aplicações (IDNA) 2008
• RFC 7626, Considerações de privacidade do DNS
• RFC 7706, Diminuir o tempo de acesso aos servidores root executando um no Loopback
• RFC 7816, DNS Minimização de Nomes de Consulta para Melhorar a Privacidade
• RFC 8499, DNS Terminologia

Desconhecido

Estes RFCs têm um status oficial de Desconhecido, mas devido à sua idade não são claramente rotulados como tal.

• RFC 920, Requisitos de Domínio – Especifique domínios originais de nível superior
• RFC 1032, Administradores de Domínio Guia
• RFC 1033, Administradores de Domínio Guia de Operações
• RFC 1101, Encodings DNS de Nomes de Rede e Outros Tipos