Resumo

  • A RFC 1183 propôs o registro RP para associar um nome DNS ao contato capaz de atender um problema, mesmo que esse contato estivesse fora da organização que administrava a zona.
  • O registro indicava uma caixa postal e um nome onde buscar informações TXT. Uma resposta DNS apontava um caminho de contato; não comprovava entrega, atendimento nem reparo.

O gateway caiu. O DNS continua respondendo, inclusive com o contato do SOA. Parece haver um responsável à mão. Mas o administrador da zona pode corrigir nomes sem conhecer a máquina, e o POSTMASTER do próprio gateway pode ser inútil se ela nem receber mensagens. Foi esse desencontro que a RFC 1183 descreveu em outubro de 1990. A autoridade sobre um nome não conferia automaticamente capacidade de reparar o equipamento por trás dele.

O mecanismo recebeu o nome Responsible Person, RP, e o número de tipo 17. O exemplo da RFC é quase uma piada sobre organogramas: um gateway sob ISI.EDU poderia apontar para uma linha de ajuda em BBN.COM. A zona continuaria com um operador; a chamada útil iria para outro. O registro não dava à linha de ajuda poder de editar o DNS. Apenas mostrava a quem recorrer quando o serviço falhasse.

Depois do nome consultado, RP exigia dois campos. O primeiro codificava a caixa postal conforme a convenção DNS usada no SOA. O segundo indicava o nome dos registros TXT com instruções legíveis. A consulta ao TXT podia exigir uma segunda busca. Vários dispositivos podiam compartilhar a mesma descrição, poupando cópias de instruções. O ganho tinha uma contrapartida: uma descrição desatualizada espalharia o mesmo erro por todos os nomes que a usassem.

O ponto raiz, « . », podia registrar a ausência de caixa postal ou de texto associado. Um mesmo nome podia ter vários RP; a recomendação era manter o mesmo TTL entre eles. Nos exemplos, uma máquina trazia mais de uma pessoa para avisar. Isso descreve melhor um plantão do que a ficção de um único endereço que resolve todos os problemas de rede, correio e banco de nomes.

RP podia ser publicado em qualquer nó da hierarquia DNS, não apenas no topo de uma zona. Assim, a busca podia partir do nome exato da máquina com defeito. A utilidade durava até a próxima mudança de equipe, fornecedor ou escala. Se ninguém atualizasse o contato, uma resposta DNS tecnicamente correta encaminharia a ocorrência a uma caixa abandonada. A RFC era Experimental; definiu uma forma de registrar responsabilidade, sem demonstrar adesão em larga escala ou resultados de consertos.

SOA respondia pela base da zona. POSTMASTER cuidava do correio. RP tentava apontar o caminho até quem poderia mexer no equipamento. A parte difícil não era inventar um terceiro campo: era impedir que o campo virasse uma lembrança de uma equipe que já não estava lá.

Fonte: RFC 1183, New DNS RR Definitions, seções 2 a 2.2; registro do RFC Editor.