Resumen
- El cliente que controla un dominio y su host subordinado puede no controlar los dominios de otros clientes que usan ese host como servidor de nombres.
- Cambiar el nombre del host hacia un destino sin custodia puede trasladar el riesgo de resolución o secuestro; RFC 9874 prohíbe dos atajos observados.
- Una supresión recuperable necesita pruebas separadas de alcance, estado DNS, notificación, plazo de redención, restauración y finalización asíncrona.
Dos clientes pueden ver el mismo host desde posiciones incompatibles. Para X, ns1.domain1.example es un objeto subordinado que impide cerrar una cuenta y borrar domain1.example. Para Y, ese mismo host es infraestructura de resolución para domain2.example. X no puede modificar el dominio de Y. Y puede ignorar que X está a punto de retirar el soporte del que depende.
El registro ve ambas relaciones. La gobernanza consiste en decidir qué debe hacer con esa ventaja informativa y cómo demostrarlo después.
La cautela original no era ceremonial
RFC 5731 pide no borrar un dominio con hosts subordinados asociados. RFC 5732 pide no borrar un host que aún esté asociado a otros objetos. El motivo más visible es el DNS: sin el dominio superior, el nombre del host puede dejar de resolverse; sin el host, las delegaciones que lo usan pueden fallar.
También hay una diferencia de estado entre cliente y servidor si el registro elimina asociaciones implícitamente, y puede haber restricciones de integridad en la base relacional. Una sola orden toca así tres superficies: publicación DNS, memoria del cliente y estructura interna del servidor.
El caso entre clientes añade un cuarto problema. La parte que decide no es necesariamente la que sufrirá la interrupción. Una interfaz que enseña solo “delete: success” oculta precisamente esa transferencia.
Los hosts sacrificiales tienen dueño
Renombrar el host lo convierte en externo y permite borrar el dominio original. Pero el nombre nuevo no es un agujero negro neutral. Si se elige un dominio que se supone inexistente, un tercero puede registrarlo, crear el host y captar las consultas de los dominios que aún lo referencian. RFC 9874 dice que esta práctica observada no debe usarse.
Usar direcciones de un servicio recursivo público tampoco crea autoridad. Las consultas pueden terminar en SERVFAIL y provocar reintentos agresivos. También está prohibido como práctica.
El camino admisible obliga al cliente a mantener el dominio padre del host sacrificial y un servidor autoritativo en sus direcciones. Esa solución conserva el control, pero abre una obligación de larga duración: renovar el dominio, protegerlo y operar el servicio mientras existan dependencias. Si la organización se fusiona, cambia de proveedor o cierra la cuenta, alguien debe heredar esa custodia.
Así, renombrar no elimina una responsabilidad. Le pone otra dirección.
La redención separa impacto de irreversibilidad
El segundo camino permite una supresión explícita aun cuando existan asociaciones con dominios de otros clientes. El servidor puede mostrar los objetos afectados antes de ejecutar, exigir una decisión consciente e informar a los patrocinadores mediante EPP Change Poll u otro mecanismo.
RFC 3915 ofrece una pieza decisiva. Durante el periodo de redención, el dominio, sus hosts y las asociaciones pueden permanecer en pendingDelete. La publicación DNS puede reflejar la retirada, pero el grafo todavía puede restaurarse si la orden fue accidental, maliciosa o produjo daños inesperados.
Solo después llega la purga. Y puede llegar por partes: RFC 9874 recuerda que no hay un límite declarado para el número de dominios asociados. Desactivar, volver a activar o purgar miles de relaciones puede ejecutarse de forma asíncrona. El instante de aceptación y el instante de terminación son hechos distintos.
Qué debe conservar el recibo
El recibo comienza con la identidad de la operación: cliente autenticado, objeto, transacción, hora, política efectiva y autoridad para afectar relaciones ajenas. Luego congela el alcance calculado, con hora y método de enumeración, hosts subordinados, recuento de dominios y límites de visibilidad. Cuando la privacidad impida nombrar a titulares, se pueden usar contadores y referencias opacas; no se debe fingir que no hay dependencias.
La siguiente capa es el DNS. Debe mostrar nombres y direcciones autoritativos antes y después, estado de DNSSEC y DS, expectativa de zona y observación real. A continuación registra la decisión: detalles advertidos, aprobación manual, práctica elegida y motivo.
La capa intercliente guarda las notificaciones, su puesta en cola, entrega y acuse. La capa de reversibilidad fija el plazo de redención, quién puede restaurar, qué asociaciones se conservaron y si una prueba de reconstrucción funcionó. La última capa cierra los trabajos asíncronos: identificadores, fallos parciales, reintentos, purga final y comprobación posterior.
No es un nuevo campo definido por el IETF. Es una propuesta editorial para impedir que un resultado de protocolo sustituya a la evidencia operativa.
DNSSEC hereda la coherencia de sus señales
DNSSEC protege contra muchas falsificaciones, pero no absuelve una transición mal gobernada. RFC 9874 describe cómo un atacante que controla un servidor de nombres puede influir en mantenimiento automático de DS mal diseñado si este no compara de forma coherente CDS/CDNSKEY de todos los servidores. CSYNC puede profundizar el cambio.
Por eso el recibo debe conservar qué automatización estaba activa, qué servidores contestaron, si coincidieron y qué autoridad aceptó el material. “Firmado” no significa “custodia comprobada”.
Una orden, varias verdades
RFC 9874 recomienda mantener un host sacrificial autoritativo, usar borrado explícito con información, aviso y restauración, o adoptar un dominio de uso especial adecuado. Los demás atajos desplazan el coste a terceros.
La conclusión no es bloquear todas las supresiones. Es evitar que cinco afirmaciones distintas se escondan bajo una sola: el servidor aceptó; los afectados fueron identificados; el DNS quedó bajo control; la restauración sigue abierta; la purga terminó. Cuando cada una tiene su evidencia, el borrado se vuelve gobernable. Cuando solo queda la primera, el éxito puede ser el comienzo del incidente.
Fuentes
- Registro Datatracker de RFC 9874
- Minimum Initial Specification — Heng Lu
- The Policy Mirror — Heng Lu
- SAC125 — gestión de servidores de nombres de registradores
- Información y estado de RFC 9874
- RFC 3915 — periodo de gracia EPP
- RFC 5730 — protocolo EPP
- RFC 5731 — mapeo de dominios EPP
- RFC 5732 — mapeo de hosts EPP
- RFC 8590 — EPP Change Poll
- RFC 9520 — caché negativa de fallos DNS
- RFC 9874 — borrado de objetos de dominio y host
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
