Resumo

  • A RFC 8552, Melhor Prática Atual de março de 2019, formalizou o uso de uma ramificação sublinhada abaixo do domínio a que os dados se referem. O nome sublinhado mais próximo da raiz DNS tem alcance global.
  • O registro da IANA protege o par tipo RR e nome global. A revisão especializada confere clareza e unicidade; os nomes inferiores continuam sob a especificação que define aquela ramificação.
  • A RFC 8553 atualizou especificações anteriores, inclusive os modelos de SRV e URI, para usar o registro integrado sem mudar software e práticas operacionais já em funcionamento. O registro mostra a atribuição; a zona autoritativa e a consulta do cliente mostram um uso concreto.

O tipo do dado não conta toda a história

As regras centrais do DNS não dão significado fixo a cada pedaço de um nome e não reservam um único local para cada tipo de registro. Isso permitiu que aplicações usassem TXT, SRV e URI para finalidades novas sem criar sempre um código de tipo novo. Também abriu uma confusão previsível: se todos publicassem no nó do domínio principal, o cliente receberia conjuntos de registros com instruções de serviços diferentes.

A RFC 8552 descreveu o remédio como uma escolha de endereço. O protocolo pode publicar seu conjunto sob _nome.exemplo.org, uma ramificação de exemplo.org. O dado continua falando sobre o domínio principal, mas a pergunta busca a parte reservada ao protocolo. O pacote e o tipo DNS não mudam. O lugar do registro limita a interpretação.

O caractere inicial distingue essa prateleira das etiquetas usadas para nomes comuns de host conforme as regras de host citadas no RFC. Ele sinaliza um atributo do domínio, não a presença de outra máquina chamada nome. Não é um segundo DNS. É uma convenção de nomes dentro da árvore existente que permite fazer uma consulta mais precisa e separar usos de tipos de registro gerais.

O caminho começou antes da formalização. A RFC 2782, de fevereiro de 2000, usou _Service._Proto.Name para buscas SRV, marcando serviço e protocolo para evitar colisões com etiquetas naturais de host. A descoberta de serviços baseada em DNS mais tarde adotou a mesma convenção. Essas especificações ensinam a localizar serviços. A questão de 2019 era quem coordenava o espaço de nomes quando muitos protocolos independentes começavam a ocupar os mesmos pontos globais.

A disputa cabe em uma dupla

Uma ramificação pode conter mais de uma etiqueta marcada. A mais próxima da raiz DNS é a global; as seguintes ficam dentro de seu escopo. Essa primeira posição é compartilhada por todos os autores de protocolos. Um deles pode organizar as prateleiras inferiores como quiser, mas não deve dar um segundo significado incompatível ao mesmo nome global com o mesmo tipo RR.

A RFC 8552 criou na IANA o registro “Underscored and Globally Scoped DNS Node Names”. Suas colunas mostram tipo RR, nome e documento de referência. A chave contra colisões é o par tipo-nome. Dois serviços podem usar o mesmo tipo em nomes globais diferentes. O mesmo nome pode aparecer com tipos distintos. Não se trata de proibir o sublinhado nem de registrar todas as etiquetas abaixo de cada ramificação.

Um especialista examina se a proposta é suficientemente clara e se o par está livre. A RFC 8552 exclui desse exame um julgamento geral sobre a qualidade técnica do protocolo. Conseguir uma posição única protege contra uma duplicidade específica; não prova que a solução é boa, que um domínio publicou os dados ou que um cliente fará a leitura correta.

A tabela atual da IANA liga cada posição global à sua referência. As etiquetas inferiores são explicadas pela especificação citada. A publicação de um domínio aparece em sua zona autoritativa. É fácil confundir esses três documentos quando se quer um diagnóstico rápido; a tabela distribui lugares, o texto define a organização interna, a resposta DNS revela o que está disponível naquele momento.

A administração chegou depois dos moradores

Várias especificações já tinham criado nomes marcados antes de haver uma lista comum. Publicada no mesmo mês de 2019, a RFC 8553 trouxe os documentos antigos para o novo regime. Corrigiu os modelos de nomes globais usados por SRV e URI para que futuras atribuições passassem pelo registro integrado.

O texto preservou software e práticas existentes. Não ordenou que zonas em funcionamento trocassem nomes de uma vez, nem alterou o formato dos pacotes DNS. Mudou a coordenação de novas escolhas e o caminho pelo qual o leitor de uma especificação antiga encontra a autoridade atual de atribuição. Foi um conserto de endereço institucional para uma convenção já viva.

A distinção em relação à história de SRV é essencial. SRV informa onde um serviço pode ser encontrado; a RFC de 2019 administra quem pode definir a posição global na qual dados de um protocolo são procurados. Uma norma resolve o destino da busca; a outra evita que duas normas façam a mesma pergunta inicial com sentidos incompatíveis.

A IANA parou no limite necessário. A especificação dona da posição global define suas subetiquetas; o operador publica os registros; o cliente interpreta a resposta. O registro comum coordena só a dupla que poderia colidir entre protocolos. Para afirmar que um serviço específico usou uma posição, faltam uma cópia datada da zona autoritativa e a consulta do cliente ao nome e ao tipo corretos.