Resumo

  • Publicada em agosto de 2007, a RFC 5001 definiu a opção DNS NSID. Uma consulta com campo vazio pede identificação; um servidor que aceite o pedido devolve bytes identificadores junto da própria resposta.
  • O pedido vale para o servidor que recebeu aquela consulta. Um resolvedor recursivo identifica a si mesmo na conversa com o cliente; a identidade de uma autoridade consultada a montante pertence a outra conversa. O conteúdo do NSID é uma sequência opaca escolhida pelo operador.
  • O relato operacional de L-Root de 2014 documentou o nome completo de cada nó respondente no NSID. O registro de parâmetros DNS da IANA reserva o código EDNS 3 para a opção.

A segunda consulta não foi uma acareação

O suporte recebe uma captura com uma resposta errada. Na bancada, outra consulta ao mesmo IP retorna o valor esperado. É tentador chamar a primeira de falha passageira de um único servidor. O anycast torna essa frase frágil. Várias máquinas anunciam o mesmo endereço de serviço, e o roteamento escolhe qual delas atende cada pacote. Um balanceador de carga também pode reunir processos diferentes sob um endereço. A identidade da porta de entrada permaneceu igual; a de quem atendeu pode ter mudado.

A orientação sobre operação de serviços anycast de 2006 já tratava a identificação do nó como parte do diagnóstico. Era possível enviar uma pergunta posterior para descobrir o nome do servidor. Se a rota mudou entre a resposta ruim e a pergunta adicional, esse nome pertence ao servidor que respondeu depois. A máquina que errou segue incógnita, enquanto uma colega inocente aparece no relatório com endereço e tudo.

A RFC 5001 atacou o desencaixe temporal. O documento cita anycast e distribuição de carga como razões para vários servidores de nomes compartilharem um IP. Uma consulta DNS não mantém uma sessão que obrigue a repetição a encontrar o mesmo nó. A forma confiável de atribuir uma resposta específica é fazer o respondente incluir uma marca identificadora na própria resposta. Assim, resultado e nome declarado pertencem ao mesmo acontecimento de rede.

Um pedido vazio, uma resposta com identidade

O resolvedor coloca uma opção NSID vazia no pseudorregistro OPT do EDNS. Ele não deve pôr dados nessa opção de consulta. O número 3 aparece no registro da IANA. O servidor que entende o pedido e decide atendê-lo insere a sequência identificadora no OPT da resposta. Deve ignorar dados NSID que tenham sido enviados indevidamente na consulta e não pode devolver NSID a quem não o solicitou. Uma captura pode então guardar a consulta, a resposta, a marca e a hora como um único conjunto.

A sequência não precisa ser um nome legível. A RFC admite o nome real, um endereço de manutenção, um valor aleatório persistente, um pseudônimo calculado, uma marca dinâmica, dados assinados ou criptografados. O protocolo padroniza o lugar da pergunta e da resposta. A interpretação dos bytes pertence ao operador. Um nome público facilita a abertura de chamados por clientes. Um pseudônimo estável permite comparar incidentes sem publicar os endereços internos. Uma marca que muda pode limitar a observação externa e complicar a busca posterior dentro da própria empresa.

Essa liberdade não é decorativa. Divulgar os endereços reais de manutenção de uma instalação anycast pode expor os nós que a arquitetura procurava abrigar sob um endereço compartilhado. Recusar qualquer identificador deixa o cliente sem um modo simples de apontar o nó de uma resposta defeituosa. A análise de segurança da RFC descreve NSID como sinalização do canal, fora da proteção que DNSSEC dá aos dados DNS. Quando a autenticidade da marca importa, é preciso proteger o canal ou conferir os registros da operação.

L-Root escolheu um nome que os outros pudessem ler

Em janeiro de 2014, os operadores de L-Root publicaram um relato dos métodos implantados para identificar seus nós anycast. No NSID, cada nó devolvia seu nome de máquina completo. O documento mostra uma saída de dig em que os octetos, exibidos em hexadecimal, correspondem a ytz01.l.root-servers.org. Trata-se de uma escolha concreta de transparência: a especificação permitia bytes opacos; L-Root os preencheu com um identificador compreensível fora da sala de controle.

O mesmo texto descreve consultas HOSTNAME.BIND e ID.SERVER. Elas podem revelar o nó que atende uma pergunta adicional. Uma troca de rota pode fazer a pergunta adicional chegar a outro lugar. O NSID pedido na consulta problemática aparece junto da resposta problemática. O relatório do incidente ganha uma ligação direta entre o resultado e quem declarou tê-lo produzido, sem depender da boa vontade da rota seguinte.

O registro de L-Root mostra uma implantação documentada em 2014. Não fornece o mapa atual de todos os operadores de servidores raiz. Para investigar uma resposta concreta, guardam-se consulta e retorno originais, bytes NSID, origem, transporte e horário. O inventário mantido pelo operador relaciona a marca ao processo ou equipamento correspondente.

Recursão não fabrica um passaporte de ponta a ponta

NSID tem alcance de um salto. Se um dispositivo pede NSID ao resolvedor recursivo, está perguntando quem é aquele resolvedor. Ele pode pedir outro NSID a um servidor autoritativo quando fizer sua consulta a montante, mas essa é uma transação distinta. O identificador que devolve ao dispositivo não vira automaticamente o nome da autoridade consultada. A RFC também impede o envio espontâneo de NSID a quem não fez o pedido.

Para saber qual autoridade respondeu atrás do resolvedor, o operador precisa da consulta a montante ou dos registros dela. Uma só resposta ao usuário não carrega a genealogia de todos os servidores visitados. Essa distinção impede atribuir uma falha à autoridade errada. Em cada salto, a marca informa o que o respondente escolheu declarar; configuração, logs e integridade do canal esclarecem a atuação real da máquina.

A porta comum deixou de ser álibi

A mudança de 2007 preservou o endereço compartilhado. Acrescentou ao pacote uma oportunidade para o nó se identificar no ato de responder. A IANA mantém o número comum, o operador decide a marca, e o resolvedor escolhe solicitá-la e preservá-la. Não há necessidade de desfazer o serviço distribuído para melhorar a precisão do diagnóstico.

O servidor pode permanecer calado. Bytes extras podem contribuir para o truncamento de uma resposta grande, e a especificação torna opcional devolver NSID. Um pacote sem marca demonstra apenas que naquele intercâmbio nenhuma marca foi entregue. A máquina ainda terá de ser localizada por outros registros. A ausência de um campo não faz do IP uma identidade física.

A pergunta importante durante uma falha é curta: qual máquina deu aquela resposta? L-Root respondeu com um nome público; outro operador pode responder com uma chave interna. Ambos só ajudam porque a marca acompanha o pacote sob investigação. A repetição feita minutos depois pode alcançar um servidor diferente, com uma versão diferente da história.