Resumen

  • El cliente X puede patrocinar el dominio y el host que quiere borrar mientras un dominio del cliente Y sigue dependiendo de ese host.
  • Renombrado, pendingDelete, aviso, restauración, purga y recuperación DNS son hechos separados; una respuesta correcta no los demuestra juntos.

Un comando EPP de borrado parece limitado al patrocinador. RFC 9874 muestra el punto ciego: X patrocina un dominio y su host subordinado, pero Y ha asociado ese host a otro dominio. X puede retirar su propia asociación; carece de autoridad para modificar el objeto de Y.

RFC 5731 ya desaconseja borrar un dominio si conserva hosts subordinados asociados. RFC 5732 hace lo mismo con un host ligado a otros objetos. Las restricciones evitan que una operación ordenada cause una caída DNS silenciosa, pero no explican cómo dejar marchar a X sin obligarlo a mantener infraestructura para Y para siempre.

Una salida observada consiste en renombrar el host fuera del dominio eliminado. La asociación persiste; también el peligro. Si el nuevo padre es registrable o cambia de manos, otro titular podría crear el host y recibir consultas destinadas a los dominios dependientes. El renombrado no elimina necesariamente el control: puede entregárselo a un futuro tercero. RFC 9874 prohíbe usar un nombre externo que solo se supone inexistente.

Tampoco sirve apuntar a un gran resolvedor recursivo: no es el servidor autoritativo que exige la delegación. Los nombres de AS112 no forman un servicio sacrificial genérico; su abuso puede facilitar secuestro local y cargar a una infraestructura concebida para otra finalidad.

Publicado como BCP 244, RFC 9874 concentra las vías seguras en tres familias. El cliente puede mantener un host sacrificial autoritativo, conservar el padre, publicar direcciones y operar realmente el DNS. El servidor puede borrar explícitamente hosts y asociaciones con detalle, aviso y restauración. O la comunidad puede crear un dominio sacrificial de uso especial, recomendando sacrificial.invalid si llega a habilitarse. El documento no afirma que las dos últimas prácticas estén desplegadas.

La opción reversible mantiene dominio, hosts subordinados y asociaciones cruzadas durante pendingDelete. El DNS público puede dejar de responder y anticipar el daño, mientras RFC 3915 conserva una ruta de recuperación antes de la purga. Solicitud, estado reversible, ventana de reacción y eliminación final necesitan tiempos distintos.

Un aviso tampoco equivale a reparación. El servidor puede revelar el alcance al cliente que borra y emplear el change poll de RFC 8590 para informar a otros patrocinadores. Crear el mensaje no prueba que se leyó, que llegó al titular, que se arregló la delegación o que volvió el servicio.

Las asociaciones pueden ser innumerables, de modo que desactivar, restaurar o purgar quizá requiera lotes asíncronos. Eso administra carga; no concede autoridad. El fin de una tarea no acredita simultaneidad, entrega de avisos ni convergencia de resolvedores.

Las capas de realidad de Heng Lu separan intención, relaciones conservadas, transición aceptada, zona autoritativa, observación del resolvedor y resultado del usuario. Su especificación inicial mínima combina un contrato estrecho con decisiones locales de aprobación y recuperación. La prioridad del código en funcionamiento exige trazas reproducibles, no fe en un estado satisfactorio.

DNSSEC reduce ciertos fallos, pero no sustituye la prueba. Una automatización que acepte CDS/CDNSKEY controlados por un atacante desde un solo servidor puede transformar la discrepancia en una transferencia más profunda.

SAC125 y la presentación Risky BIZness de IETF 115 aportan contexto sobre la gestión de servidores de nombres. No prueban una vulnerabilidad o conducta actual de un operador concreto. RFC 9874 responde a una clase de riesgo; no narra un incidente.

Fuentes