Resumen

  • La RFC 1183 propuso el registro RP para señalar a quien podía atender una avería de un nombre concreto, aunque trabajara fuera de la entidad que administraba su zona DNS.
  • RP contenía un buzón y un nombre que apuntaba a posibles registros TXT con instrucciones. La publicación de esos datos no demostraba que el aviso llegara, recibiera respuesta o terminara en reparación.

El servidor de nombres contesta. La pasarela no. Una consulta al registro SOA revela a quién avisar sobre la zona, pero el problema está en otro sitio: el equipo que transporta tráfico. El buzón POSTMASTER sirve para el correo y puede resultar inútil si la pasarela ni siquiera acepta mensajes. Esa diferencia entre la autoridad sobre los nombres y la capacidad de reparar una máquina es el punto de partida de la RFC 1183, publicada en octubre de 1990.

La propuesta se llamó Responsible Person, RP, y recibió el código de tipo 17. El ejemplo del documento es más revelador que la sigla: una pasarela bajo ISI.EDU podía remitir a una línea de ayuda de BBN.COM. El registro DNS no cambiaba de propietario. Se hacía visible que la llamada útil cruzaba una frontera institucional. Quien firma el mapa de nombres no siempre sostiene la llave inglesa.

Después del nombre del recurso, el registro llevaba dos campos obligatorios. El primero expresaba un buzón con la sintaxis DNS que ya usaba SOA. El segundo apuntaba al nombre de registros TXT con explicaciones para personas. Consultar esos TXT podía requerir otra pregunta al DNS. Varias máquinas podían referirse a la misma nota, evitando copiar teléfonos e instrucciones una y otra vez. También quedaban expuestas al mismo error si esa nota envejecía.

El documento permite usar el punto raíz, « . », para declarar que no existe buzón o que no hay TXT asociado. Permite asimismo más de un RP en un mismo nombre y pide que compartan tiempo de vida en caché. En sus ejemplos, un equipo tiene varias personas a las que avisar. No hay una jerarquía pulcra de un responsable por aparato; hay tareas que se solapan y turnos que importan cuando algo deja de funcionar.

RP podía asociarse con cualquier nodo de la jerarquía DNS, no solo con un dominio entero. Esa precisión hacía más útil el contacto: se podía preguntar por el nombre afectado. Pero el dato dependía de que alguien actualizase el buzón y la descripción cuando cambiase el servicio. Una respuesta DNS válida podía guiar a un buzón abandonado. La RFC se publicó como Experimental: define el mecanismo, sin ofrecer cifras de adopción ni resultados de incidentes.

El problema que señaló sigue siendo concreto. El contacto SOA puede modificar la zona. POSTMASTER puede atender el correo. La pasarela necesita a quien responda por su operación. RP intentó poner ese tercer nombre en un lugar consultable. Dejarlo sin dueño solo trasladaría la avería al directorio de contactos.

Fuente: RFC 1183, New DNS RR Definitions, secciones 2 a 2.2; ficha del RFC Editor.