Resumo

  • Uma segunda consulta ao mesmo endereço DNS pode alcançar outra instância. O NSID permite anexar a identificação à resposta que será investigada.
  • O conteúdo é uma sequência opaca de bytes escolhida pelo operador. A regra comum preserva o dado; não distribui nomes de servidor nem garante a interpretação.
  • Um resolvedor responde por si próprio ao cliente e pode solicitar identificadores em consultas separadas a servidores autoritativos. Essas decisões não criam uma cadeia automática de procedência.

O servidor que pergunta pode preferir não contar

Na documentação de BIND consultada para esta análise, dois controles aparecem separados. server-id define a identificação que o servidor fornece. request-nsid decide se ele solicita identificadores nas consultas iterativas que faz a servidores autoritativos. Um descreve a divulgação local; o outro, a coleta de informação do interlocutor.

A referência de configuração, identificada na captura como versão 9.20.27, informa none como padrão de server-id e no como padrão de request-nsid. O uso do nome da máquina é uma opção do primeiro. Quando o segundo é ativado, as solicitações NSID vazias acompanham consultas iterativas e os valores recebidos podem ser registrados na categoria nsid.

Não se trata de transparência ligada ou desligada para toda a resolução. São duas escolhas locais, feitas em posições diferentes de uma troca. A configuração expõe uma decisão tomada no desenho do protocolo: a identidade oferecida vale para a instância que responde naquele momento, não para todos os participantes que podem ter contribuído para os dados.

Um endereço estável não é uma única máquina

Para entender a necessidade, basta separar o endereço do serviço de suas instâncias. Anycast permite que vários nós independentes anunciem um mesmo endereço de serviço. O roteamento escolhe por onde o tráfego chega. O cliente usa um ponto de acesso estável, sem precisar conhecer a lista de endereços de manutenção.

Essa conveniência deixa uma pergunta para a operação: quem respondeu? Não é correto dizer que anycast sempre escolhe a máquina geograficamente mais próxima, nem que necessariamente troca de nó a cada pacote. O que não existe é uma garantia de identidade baseada apenas na repetição do endereço de destino.

RFC 4786, publicado em dezembro de 2006, tratou dessa variável adicional. Um traceroute poderia ajudar em certas situações, mas as condições já poderiam ter mudado quando o diagnóstico fosse executado. O documento recomendava identificação dentro do protocolo do serviço, além de observações distribuídas que registrassem o nó junto com desempenho e disponibilidade.

A referência a NSID naquele texto era a um trabalho em andamento. A especificação definitiva viria em 2007. A cronologia mostra uma demanda operacional concreta antes da solução final: era necessário associar os resultados ao participante real, sem desmontar o benefício do endereço compartilhado.

A resposta certa, colhida tarde demais

Havia convenções para consultar a identidade de um servidor DNS. HOSTNAME.BIND., em uma consulta TXT da classe CHAOS, podia retornar um identificador escolhido pelo administrador. ID.SERVER. retirava o nome de uma implementação específica. VERSION.BIND. respondia à questão distinta da versão do software.

Esses mecanismos tinham vantagens: eram simples, usavam DNS e preservavam a decisão de divulgação. O NSID não os tornou proibidos. Seu limite estava na necessidade de fazer outra consulta. A instância que respondesse à pergunta de identidade poderia não ser a mesma que havia enviado a resposta problemática.

É possível imaginar um diagnóstico em que a consulta inicial encontra uma instância com problema e a segunda recebe o nome de uma saudável. Não é uma ocorrência medida neste artigo. É uma sequência possível que mostra como um dado verdadeiro pode ser atribuído ao evento errado.

RFC 4892, de junho de 2007, formulou o requisito de identificação como parte da consulta operacional normal. Anycast e balanceamento de carga podiam encaminhar consultas sucessivas a servidores distintos. Trocar de protocolo para investigar não garantia alcançar quem havia processado o pedido original.

O documento também buscava neutralidade de implementação e controles administrativos. A solução não deveria exigir uma classe ou espaço de nomes especial, nem obrigar a revelar nomes privados ou endereços unicast de manutenção. Uma referência útil para suporte podia ser menos reveladora que um inventário público da rede.

O pedido vazio e o número comum

R. Austein definiu o NSID no RFC 5001, de agosto de 2007. O solicitante inclui uma opção NSID vazia no pseudorregistro OPT de EDNS. Não deve colocar conteúdo nessa opção; caso o faça, o servidor deve ignorá-lo.

O cliente não envia um desafio para ser repetido, não escolhe o nome do servidor e não determina qual instância deve atendê-lo. Solicita que o interlocutor efetivamente alcançado, se tiver suporte e decidir atender, acrescente seu identificador ao OPT da mesma resposta.

Atender é opcional. Enviar sem solicitação, por outro lado, é proibido. Uma resposta sem NSID não demonstra falha de DNS, ausência de anycast ou inexistência de instâncias distintas. Suporte, configuração, solicitação e retorno precisam ser observados separadamente.

O registro de parâmetros DNS de IANA associa o código de opção EDNS 3 ao NSID. É a reserva de um espaço no vocabulário comum, não a distribuição de identidades individuais. O operador decide o que os bytes significam. Não há exigência de cidade, prédio, nome de máquina ou número de série mundial.

A recursão não vira um histórico transferível

Quando um cliente pede NSID a um resolvedor recursivo, pergunta por esse resolvedor. Ele pode fazer suas próprias solicitações NSID a servidores autoritativos, mas cada uma constitui outro intercâmbio. A identificação recebida do servidor autoritativo não é encaminhada como se fosse a identidade do resolvedor perante o cliente.

O mecanismo é expressamente não transitivo. A expressão salto a salto trata das pontas de cada transação DNS, não de cada roteador IP atravessado. Não se forma uma lista de todos os equipamentos, nem uma cadeia dos servidores consultados na resolução.

RFC 6891, a revisão de EDNS de abril de 2013, explica que OPT contém controle de uma transação específica, e não dados DNS. Não deve ser armazenado em cache, encaminhado como registro comum nem guardado em arquivos mestres de zona.

Da combinação dessas regras surge uma consequência importante: uma resposta pode usar registros em cache e, ao mesmo tempo, identificar a instância recursiva que está respondendo agora. O NSID não certifica qual instância autoritativa havia fornecido os registros no passado. Misturar esses dois tempos tornaria a identificação mais vistosa e menos precisa.

O usuário pode não entender, mas precisa copiar inteiro

O conteúdo NSID é opaco. Mesmo que pareça texto, não se pode presumir que seja um nome DNS ou uma codificação textual universal. O usuário talvez só consiga enviá-lo ao operador, que consulta uma correspondência interna. Isso é um uso previsto, não uma deficiência.

RFC 5001 exige leitura e escrita em hexadecimal, com dois dígitos por octeto. A comparação é entre dados binários. A cópia não pode assumir que um byte nulo termina a sequência. Zeros iniciais e internos são parte da referência e não podem ser removidos por conveniência visual.

Maiúsculas e minúsculas na exibição hexadecimal podem representar os mesmos bytes. Alterar maiúsculas, minúsculas ou normalização Unicode dentro do conteúdo supostamente textual é outra coisa. Uma interface pode mostrar uma prévia legível, mas deve preservar o valor exato. A formatação de um formulário de suporte não deveria reescrever a evidência que ele pretende transmitir.

Um código opaco não nasce confidencial

O operador pode escolher nomes, endereços, valores aleatórios persistentes ou identificadores dinâmicos. A liberdade permite ajustar divulgação e diagnóstico, mas cobra manutenção. Se todos os nós forem configurados com o mesmo valor, a opção funciona no formato e fracassa na distinção.

Expor um endereço de manutenção pode revelar uma instância que o endereço anycast não individualizava. Usar hash de IPv4 não aumenta seu espaço de entrada, limitado a 32 bits. Nomes previsíveis também podem ser testados. Valores aleatórios exigem guardar o vínculo com os recursos operacionais; valores que mudam exigem explicar a política de mudança.

Por isso, dois valores diferentes não provam por si só mudança de rota ou troca de equipamento. Um valor igual também não é uma identidade física permanente. A conclusão depende das regras locais de atribuição e continuidade.

O RFC discute conteúdo assinado ou cifrado sem oferecer uma solução criptográfica completa. Um bloco estático pode ser reproduzido. NSID é sinalização de canal e não recebe automaticamente a proteção de DNSSEC: autenticar um conjunto de registros não autentica necessariamente o campo que o acompanha. A menção histórica a mecanismos como TSIG delimita essa necessidade; não afirma que as trocas comuns já estejam protegidas.

A ferramenta faz uma pergunta, não uma exigência

As páginas de manual de BIND documentam dig +nsid como forma de incluir a solicitação EDNS. Isso demonstra uma implementação utilizável, não uma garantia de resposta ou de autenticidade. Tampouco serve como levantamento de quantos serviços habilitam o recurso.

Os bytes adicionais também contam para o tamanho da resposta. NSID pode aproximá-la dos limites de truncamento, mas não modifica as regras existentes nem exige truncar apenas para inserir a identificação opcional. A informação de diagnóstico acompanha o serviço; não transforma uma resposta maior em entrega garantida.

A contribuição do padrão foi manter o indício junto do evento certo. Sem isso, perguntar depois poderia produzir um nome claro e uma atribuição errada. Com isso, até um valor incompreensível para o usuário pode conduzir o operador à investigação adequada.